From kivinen@iki.fi Wed Jun 1 07:58:38 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D97E071F; Wed, 1 Jun 2011 07:58:38 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqU2vE9vjsiD; Wed, 1 Jun 2011 07:58:37 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7097FE0708; Wed, 1 Jun 2011 07:58:36 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p51EwVJL023915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2011 17:58:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p51EwSxn003686; Wed, 1 Jun 2011 17:58:28 +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: <19942.21396.600411.479045@fireball.kivinen.iki.fi> Date: Wed, 1 Jun 2011 17:58:28 +0300 From: Tero Kivinen To: Oscar Novo In-Reply-To: <58E207308662A748A4AC1ECB4E8856140815D35812@ESESSCMS0355.eemea.ericsson.se> References: <19935.37953.301024.987227@fireball.kivinen.iki.fi> <58E207308662A748A4AC1ECB4E8856140815CDED51@ESESSCMS0355.eemea.ericsson.se> <19935.41711.849950.705575@fireball.kivinen.iki.fi> <58E207308662A748A4AC1ECB4E8856140815CDF032@ESESSCMS0355.eemea.ericsson.se> <19940.59154.513573.470137@fireball.kivinen.iki.fi> <58E207308662A748A4AC1ECB4E8856140815D35812@ESESSCMS0355.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 7 min Cc: "draft-ietf-xcon-common-data-model.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-xcon-common-data-model-28.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 14:58:38 -0000 [CC'ing back to original recipient list, as all my issues have been solved]. Oscar Novo writes: > Thanks for your reply. I've created a new version of the draft with > your suggestions. > Do you think the document is more clear now? Yes. > It is RECOMMENDED the database uses encryption mechanisms if the > information is stored in long term storage (e.g., disk). If the > database contains sensitive elements (e.g., passwords) the > confidentiality of the database MUST be protected from unauthorized > users. If no sensitive elements is present then confidentiality is > not needed. I think the above text is clear and solves my issue. > Note that the specification of the privacy policy is outside the > scope of this document. Saying that, a privacy policy will be needed > in the real implementation of the data model and, therefore, is > subject to future policy documents. I think this is the minimal text what is needed. It could provide bit more information about what kind of elements in data model and what kind of issues privacy policy would need to cover, but that would require more work to find that information out. So I think that change will solve my issue. -- kivinen@iki.fi From shanna@juniper.net Wed Jun 1 11:16:08 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA8C130019; Wed, 1 Jun 2011 11:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtzT3GvZjxUu; Wed, 1 Jun 2011 11:16:07 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA9513000B; Wed, 1 Jun 2011 11:15:57 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTeaB3M4VN40gRIuNMaxAOQeXj9LBkRTp@postini.com; Wed, 01 Jun 2011 11:16:02 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 1 Jun 2011 11:15:18 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 1 Jun 2011 14:15:17 -0400 From: Stephen Hanna To: "secdir@ietf.org" , "draft-ietf-dnsext-rfc2672bis-dname@tools.ietf.org" Date: Wed, 1 Jun 2011 14:15:15 -0400 Thread-Topic: secdir review of draft-ietf-dnsext-rfc2672bis-dname-22.txt Thread-Index: Acwgh9s80YeQfWrkRySR5CC9/YhwJg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org" Subject: [secdir] secdir review of draft-ietf-dnsext-rfc2672bis-dname-22.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 18:16:08 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document intends to replace RFC 2672, the definition of DNAME redirection in the DNS. DNAME is a DNS resource record type that (in layman's terms) indicates that all domain names ending in a specified suffix should be redirected to domain names where the suffix is replaced by a specified value. For example, all names that end with example.com should be remapped to example.net. The document is quite thorough, apparently because the DNAME RR has been used for many years and a great deal of real-world experience has been gained. That's definitely a good thing! >From a security perspective, this document includes a more thorough analysis of security considerations than the original RFC 2672. It also includes a more thorough discussion of DNSSEC interactions than the earlier document. I do not see any security issues that are not well covered in this document. While I don't think this document will close any major security issues, it includes some helpful guidance. So I recommend that this document advance to RFC status. Thanks, Steve From lha@kth.se Wed Jun 1 20:01:31 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6105E0793; Wed, 1 Jun 2011 20:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xz7d+I7tuzmn; Wed, 1 Jun 2011 20:01:31 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by ietfa.amsl.com (Postfix) with ESMTP id D2622E06A2; Wed, 1 Jun 2011 20:01:30 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id C5A25156B2D; Thu, 2 Jun 2011 05:00:57 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id EtLTnMjR0r4X; Thu, 2 Jun 2011 05:00:53 +0200 (CEST) Received: from EXHUB1.ug.kth.se (exhub1.ug.kth.se [130.237.32.134]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 3DF201558BF; Thu, 2 Jun 2011 05:00:49 +0200 (CEST) Received: from EXDB1.ug.kth.se ([169.254.1.223]) by EXHUB1.ug.kth.se ([130.237.32.134]) with mapi id 14.01.0289.001; Thu, 2 Jun 2011 05:00:00 +0200 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= To: IESG - , Security-Directorat Directorat , "draft-ietf-pcn-cl-edge-behaviour.all@tools.ietf.org" Thread-Topic: secdir review: draft-ietf-pcn-cl-edge-behaviour Thread-Index: AQHMINEpoosUJxHqnEChhMKfKazHjA== Date: Thu, 2 Jun 2011 03:00:00 +0000 Message-ID: <54F97A19-BB15-43A6-8384-B42E52893B4A@kth.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [99.52.202.108] Content-Type: multipart/signed; boundary="Apple-Mail-3-111400453"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "secdir-secretary@mit.edu" Subject: [secdir] secdir review: draft-ietf-pcn-cl-edge-behaviour X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 03:01:31 -0000 --Apple-Mail-3-111400453 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii All, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I don't se any problems with the draft and find the security consideration, while short, I agree with it. Love --Apple-Mail-3-111400453 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWjCCBWQw ggRMoAMCAQICEF/yv3iUOGg5xP614ejUMEUwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA0MzAwMDAwMDBaFw0x MjA0MjkyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMR8wHQYDVQQDFBZMb3ZlIEj2cm5xdWlzdCDFc3RyYW5kMRkwFwYJKoZIhvcNAQkBFgpsaGFA a3RoLnNlMIIBIDALBgkqhkiG9w0BAQEDggEPADCCAQoCggEBAOVPH/5M22Cw8ABsUHXKgXPKKxtr UJzfEKUW9a8a8dp+CAtIhVe8pqa+CKtu4l87iiXhgOYOwH4RUahmP9XEa1xkXjQnUeZ9O+RMyZQu 1wCXM5lXzfS0Srtzq2rjD4/l5WJhuw7UsCPKUgqRS81eVejHhiXH5s8ODVTvdh7/sRCT4m5lvqxu jok/Hl5esNnYeHELb76t6mXKOGOCl1T6kMGhbvYQltau0C7xB0ew6IwerbH22OSxyao2MXFOmusU cAsDAcU2teE7x+7atyrO8ex3g8R0ACmTtHL5r+Xg14fctKywgPdKS11ppvhbBTd0fDUBB/ePjOFw 1l+KafRU5AUCAwEAAaOB6DCB5TAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEw KjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBQGCmCGSAGG+EUBBgcEBhYETm9uZTBQBgNV HR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQtZzMtY3JsLnZlcmlzaWduLmNvbS9J bmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQADggEBAHD683nJ4SQqs1URlB32Zr62 OggDyFikp74BZj6RZ9uTB+gp/hMhHrN+bkYbW6IgsAOkAXGFFkf48T7LLF2G0r93yBi8ffq6XhzZ 9Ut433u/C/kPbHq4dV+w5cEes3AACO3aNkmSk15bA5NRd1vSorfk4RB+4YaSOq/KdNGpuI0XzIVo iJzyDiVpQkUCwb+DN6ZnkIrpWQaEXWW9bEgOJ7JrHT1gAL6K/q3g8/VbXbNfcTJD4eZtdUTMYu3P vRBfOjmPJcOHU7MZLHxkbsK/GlPnZx+QTxJKVepIkkHELxRRIdgcQ3K5EK1Ff6Ffq0LJMwRqMpbw PaoEzh87HISNvFUwggbuMIIF1qADAgECAhBxFWYFSuSRIU3pvET5rNPcMA0GCSqGSIb3DQEBBQUA MIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9y IGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFBy aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0wOTA1MDEwMDAwMDBaFw0xOTA0 MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtxEffKigdfAZru9chMslsE4/p sY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+P8aRCbtMNJ6NbqGCUWL3aXZYlgev nhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZtKRSXvS3aiUcZiNhLBD3rtjxnHnQA Ew3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrYbKlHwVQpZUM+SsCWH8Gt93evbLEE Xr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJIGnfy1VAnminTlvso9bokdmLjjFnr +27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEAMHAGA1UdIARpMGcwZQYLYIZI AYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL2NwczAqBggr BgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQtMCswKaAnoCWG I2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjBuBggr BgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAfMAcGBSsOAwIaBBRLa7kolgYMu9BS OJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvMS5naWYwLgYDVR0R BCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0OC0xMTgwHQYDVR0OBBYEFHlHYQhB /TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgG A1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFF MEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFAAOCAQEAOU3PQZmB takFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hjWmf+NYUrocNdo0rCOhndMNbMTe/x 0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVyF+X8Kl2H04oNwtFFKvjA9KwqkzrV rhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUkZkxdkR92sxc+fw3GIYkvsze4of9c sm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4xcQaH+mxZUy7X3yvtX2MArBXtA7hV FozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5 BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5 MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEF/yv3iUOGg5xP614ejUMEUwCQYFKw4D AhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwNjAy MDI1OTU4WjAjBgkqhkiG9w0BCQQxFgQUF8ufcW2J49LwscKuGGIEVPWiHe8wggEDBgkrBgEEAYI3 EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMwIQX/K/eJQ4aDnE/rXh6NQwRTCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEF/yv3iUOGg5xP614ejU MEUwDQYJKoZIhvcNAQEBBQAEggEAqjfE78m84pja7vIoVDquZ/+rYQol8QdqxO5PSTz1t/JNBlSy RKjpxaOw1MK7/6mZ9K5VPo9Fo/yCx5t6Z0Mm+NvG8AgI6eaC3/lZAdV7GkBzncxK+1yePv41wPIR h4zC8Mwpc+10bPPFa3iSt87tlaI9w9ah3Cc38dxyC0P40eGzFl9sE66ACopEnMoYGoXIgyiEB9Lv MWpFGLWyN22fHIQg/ohyuoMU8ixRtPK8jKUNdeZvQ4SN0IPxf5l2ywNugfey3hD6BZzm7hGXatw0 VJ+u6qiMeImlNJZqj/mIlORefp3lnVI4aL7d5GKl8SObw8vP5t71Dj4vV8rGfc9L8QAAAAAAAA== --Apple-Mail-3-111400453-- From ondrej.sury@nic.cz Thu Jun 2 05:48:01 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B17E07BA; Thu, 2 Jun 2011 05:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7G5aZbIkRbp; Thu, 2 Jun 2011 05:48:01 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D2E97E07B9; Thu, 2 Jun 2011 05:48:00 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 85C6E2A2C48; Thu, 2 Jun 2011 14:47:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1307018874; bh=Q+v3ZDHZHXCQpqhSpsldN2LOV8sw0yWLNPzQmC2Hh5Q=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=GkZX0E2b1Z+34GKJNO/gPBJEh+tgiN+G4JKWyxnnj90AvlGCqd6j8dChM4lcK5dcn UIguscs3yjSKswABjQiWWBYJDg6NYT0zI+B9c4jpwZuM0kp7+uKr1svtYJWuhdx3R1 7YEyYYDkWKW9JJ1qc0maIOZyEh9Tr1Xy80jSUrTY= Message-ID: <4DE78679.3060308@nic.cz> Date: Thu, 02 Jun 2011 14:47:53 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ccamp-gmpls-vcat-lcas.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [secdir] Review of draft-ietf-ccamp-gmpls-vcat-lcas-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 12:48:02 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document summarizes requirements and use of Generalized Multi-Protocol Label Switching (GMPLS) control plane in support of the Virtual Concatentation and Link Capacity Adjustment Scheme. In addition to this it add a specific use of the Notify message and admin status object for GMPLS signaling. The security consideration is very short stating that the interceptor may see informations about different routes and that these members are of the same VCAT group. I do not see any new security consideration on top of existing RFC5920. You should read this review with one fact in mind: the subject of the draft is far far away from my expertise, however it seems to be well written and ready for publication. Ondrej -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From weiler+secdir@watson.org Fri Jun 3 07:16:50 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4E6E074D for ; Fri, 3 Jun 2011 07:16:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qM9R0kDQ9Nm for ; Fri, 3 Jun 2011 07:16:49 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id DF288E065D for ; Fri, 3 Jun 2011 07:16:48 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p53EGl6o053337 for ; Fri, 3 Jun 2011 10:16:47 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p53EGl9T053334 for ; Fri, 3 Jun 2011 10:16:47 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 3 Jun 2011 10:16:47 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 03 Jun 2011 10:16:47 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 14:16:50 -0000 Matt Lepinski is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2011-06-09 Reviewer LC end Draft Derek Atkins T 2011-06-03 draft-ietf-tcpm-persist-04 Rob Austein T 2011-06-06 draft-faltstrom-5892bis-04 Richard Barnes T 2011-06-09 draft-ietf-dnsext-dnssec-registry-fixes-08 Dave Cridland T 2011-06-06 draft-ietf-sieve-external-lists-09 Sam Weiler T 2011-06-01 draft-ietf-dhc-duid-uuid-03 Brian Weis T 2011-06-01 draft-ietf-dhc-dhcpv6-relay-supplied-options-06 Tom Yu T 2011-05-30 draft-ietf-l3vpn-ibgp-07 Larry Zhu T 2011-05-26 draft-ietf-mpls-mp-ldp-reqs-08 For telechat 2011-06-23 Reviewer LC end Draft Alan DeKok TR2011-06-22 draft-ohba-pana-relay-03 Barry Leiba T 2011-06-16 draft-ietf-v6ops-6to4-advisory-01 Last calls and special requests: Reviewer LC end Draft Uri Blumenthal 2011-06-06 draft-ietf-sipcore-location-conveyance-08 Donald Eastlake 2011-06-03 draft-ietf-behave-ftp64-10 Shawn Emery 2011-06-06 draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-01 Tobias Gondrom 2011-06-03 draft-ietf-dime-ikev2-psk-diameter-07 Phillip Hallam-Baker 2011-06-14 draft-ietf-dime-local-keytran-10 Sam Hartman 2011-06-10 draft-ietf-pcn-sm-edge-behaviour-05 Jeffrey Hutzelman 2011-06-14 draft-ietf-soc-overload-design-06 Charlie Kaufman 2011-06-14 draft-ietf-radext-crypto-agility-requirements-06 Scott Kelly 2011-06-15 draft-ietf-opsawg-mib-floats-01 Stephen Kent 2011-06-15 draft-ietf-mpls-tp-loss-delay-profile-03 Tero Kivinen 2011-06-15 draft-ietf-mpls-loss-delay-03 Warren Kumari 2011-06-15 draft-ietf-ipfix-psamp-mib-03 Julien Laganier 2011-06-15 draft-ietf-ipfix-configuration-model-09 Catherine Meadows R2011-04-13 draft-ietf-speechsc-mrcpv2-24 Tim Polk 2011-05-11 draft-ietf-vrrp-unified-mib-09 Tina TSOU 2011-04-23 draft-shin-augmented-pake-06 Carl Wallace 2011-05-30 draft-ietf-mpls-p2mp-lsp-ping-16 Nico Williams 2011-05-26 draft-ietf-dkim-mailinglists-10 Kurt Zeilenga R2011-06-29 draft-hammer-hostmeta-16 Kurt Zeilenga 2011-05-30 draft-ietf-mpls-lsp-ping-enhanced-dsmap-09 Glen Zorn 2011-06-28 draft-li-pwe3-ms-pw-pon-03 From sra@hactrn.net Fri Jun 3 09:46:46 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD41AE06D5; Fri, 3 Jun 2011 09:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DK5rh1eaG0H; Fri, 3 Jun 2011 09:46:46 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfa.amsl.com (Postfix) with ESMTP id EFE79E0789; Fri, 3 Jun 2011 09:46:45 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id BA7EF2845C; Fri, 3 Jun 2011 16:46:42 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 447AD2282A; Fri, 3 Jun 2011 12:46:42 -0400 (EDT) Date: Fri, 03 Jun 2011 12:46:42 -0400 From: Rob Austein To: iesg@ietf.org, secdir@ietf.org, draft-faltstrom-5892bis.all@tools.ietf.org MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20110603164642.447AD2282A@thrintun.hactrn.net> Subject: [secdir] Review of draft-faltstrom-5892bis-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 16:46:47 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft...is an affirmation that the IETF has reached (rough) consensus that an existing RFC still applies without needing any changes. If this sounds mad, well, welcome to IDN. Specifically, this draft notes that, as expected, the Unicode Consortium has updated their "Unicode Standard" specification, as they are wont to do, and that the IETF's current algorithm (RFC 5892) for incorporating their specification into IDN by reference appears to be working as expected, at least for now. The draft calls out three user-visible changes that this update to the referenced standard will have, other than allocation of formerly unused code points: two Vedic Sanskrit characters (U+0CF1 KANNADA SIGN JIHVAMULIYA and U+0CF2 KANNADA SIGN UPADHMANIYA) which formerly mapped to the DISALLOWED class now map to the PVALID class, while one of the many alternate forms of the digit one (U+19DA NEW TAI LUE THAM DIGIT ONE) which formerly mapped to PVALID now maps to DISALLOWED. Other than the risk of making readers' heads explode and causing permanent brain trauma for anyone who attempts to understand this topic, the only security issue I see here is correctly called out in the Security Considerations section of the draft, which notes that, as the code points in question are not likely to be used in Internationalized Domain Names, the risk of unexpected results or other confusion due to the change in the underlying spec is minor. To the extent that anything involved in IDN is harmless, this draft qualifies, so I have no security concerns about this draft as such. From warren@kumari.net Sat Jun 4 09:00:53 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8CBE0686; Sat, 4 Jun 2011 09:00:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2bl5N68oJLI; Sat, 4 Jun 2011 09:00:53 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB42E0675; Sat, 4 Jun 2011 09:00:50 -0700 (PDT) Received: from wk-air.lan (unknown [96.26.72.99]) by vimes.kumari.net (Postfix) with ESMTPSA id 7A1D31B40425; Sat, 4 Jun 2011 10:42:32 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 4 Jun 2011 10:42:28 -0400 Message-Id: <16FB357D-064E-4251-99F1-F5E7D973AA93@kumari.net> To: secdir@ietf.org, iesg@ietf.org, draft-ietf-ipfix-psamp-mib@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] Secdir review of draft-ietf-ipfix-psamp-mib X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 16:00:54 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments = just like any other last call comments. This document describes an extension to the IPFIX MIB module to support = PSAMP (sampled) implementations. The Security Considerations section is present and well written. There = are no R/W objects and so the primary concern is disclosure of device / = configuration information. The draft provides good suggestions to limit = this (e.g. IPSec, SNMPv3) -- these same concerns (and mitigations) = exist for other MIBs. While the information in this MIB *could* be = valuable to an attacker (to allow him try avoid having *his* packets = sampled) I think that other MIBs would be a much larger target. I did not check the MIB itself for syntax, lint, etc. W From d3e3e3@gmail.com Sun Jun 5 13:44:54 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9DE21F84DF; Sun, 5 Jun 2011 13:44:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7HFXOGk2P6e; Sun, 5 Jun 2011 13:44:54 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C1BE321F84BC; Sun, 5 Jun 2011 13:44:53 -0700 (PDT) Received: by gxk19 with SMTP id 19so1736603gxk.31 for ; Sun, 05 Jun 2011 13:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=PoiRyWpBBu0Ccl7LiEA8LBM2XsIYu9KEOvh8wo2m0a8=; b=KO8M05qAefT4J9j71EZswu7YbS1xcgXosG+veHnq4PzHJ7D7qCY4KjMWpw27MCFRti bOeqWWby51uS5ZMSlTyHg70BW2+AHhufKw7Ja9zYidsfGRzzs+9B4Yb+E3MtvM1DbMDg c+IyNJrb1TAQe8eV4SVVwbWutXOwzVnutDLg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=uJtD6YGBVwjHNzRkArLPIPBTeA64ZfF1LCS8WNu2JrnHs/BxxcB9Q3WE0d1BQTUvR4 emQY/dFlXQHV94EdrFDwo/ZHG1IcoCmjTyp/qgkpS0pPuEKBVILOQK9Gaf4+tA7XioBJ cJvBot/7ogx9z0TuCH1Rbkc+dZaF4dkyo2Tkg= Received: by 10.151.123.20 with SMTP id a20mr3672709ybn.157.1307306693096; Sun, 05 Jun 2011 13:44:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.144.3 with HTTP; Sun, 5 Jun 2011 13:44:33 -0700 (PDT) From: Donald Eastlake Date: Sun, 5 Jun 2011 16:44:33 -0400 Message-ID: To: iesg@ietf.org, secdir@ietf.org, draft-ietf-behave-ftp64.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [secdir] draft-ietf-behave-ftp64 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 20:44:54 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This draft is about trying to secure access to IPv4 FTP servers from IPv6 clients. The results are not terribly encouraging but I find they are quite accurately described in the Security Considerations Section and I don't think you could do much better given a requirement to work with existing FTP servers. I have a bit of a problem with the title ("An FTP ALG for IPv6-to-IPv4 translation") and the slant of some of the wording. It claims to be able to describe, as an Application Level Gateway, various recommendations which are then combined with a separate existing IPv6-to-IPv4 ALG. It talks about multiple ALGs being implemented at a single entity that are handling an single FTP session. This just all seems very odd to me as it isn't very clear what the interface between these different ALGs all somehow cooperating on one session is. I believe, in reality, anyone implementing this will take an existing ALG and modify it as suggested in the draft. The draft would therefore make more sense if written as suggested changes to a single ALG rather than as an additional ALG that is somehow compounded with an existing FTP ALG... Just my opinion. Thanks, Donald =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 =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From paf@cisco.com Sun Jun 5 15:02:39 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B5421F84BE; Sun, 5 Jun 2011 15:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jePwqE4wHRQQ; Sun, 5 Jun 2011 15:02:35 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAAA21F84BC; Sun, 5 Jun 2011 15:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=285; q=dns/txt; s=iport; t=1307311355; x=1308520955; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=QIAlKAyk5frUVzfAOO7ggM1ylB2pPIzPTKQiSLEaW1M=; b=AljA5ipSKBiU5c4bzotzKknHJana7T41TNVe1BJwuK5gF7gYXkmsNm3B MH2WNaj44IfeB+IZ5CFA76CiW7TtNwFh0neA9EaGl92w+oxN72yUkX3nP O8h+N18LzfbEWDB+vLx6srercmIYG/uMPyTSIC2VgyrBgMVu6EzkvLN0I U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIX8602Q/khR/2dsb2JhbABTpjZ3iHGgY5xkhiEEkHmPPA X-IronPort-AV: E=Sophos;i="4.65,324,1304294400"; d="scan'208";a="33755993" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 05 Jun 2011 22:02:17 +0000 Received: from dhcp-10-61-100-145.cisco.com (dhcp-10-61-100-145.cisco.com [10.61.100.145]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p55M2HMM015101; Sun, 5 Jun 2011 22:02:17 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20110603164642.447AD2282A@thrintun.hactrn.net> Date: Mon, 6 Jun 2011 00:02:17 +0200 Content-Transfer-Encoding: 7bit Message-Id: <50D7EEF6-4836-4D50-8833-CC21D82116CC@cisco.com> References: <20110603164642.447AD2282A@thrintun.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.1084) Cc: The IESG , secdir@ietf.org Subject: Re: [secdir] Review of draft-faltstrom-5892bis-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 22:02:39 -0000 On 3 jun 2011, at 18.46, Rob Austein wrote: > Other than the risk of making readers' heads explode and causing > permanent brain trauma for anyone who attempts to understand this > topic, Yeah, I can just confirm the world is that "interesting"... Thanks Rob. Patrik From new-work-bounces@ietf.org Tue May 31 09:43:40 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F74E0802; Tue, 31 May 2011 09:43:40 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id B7E1DE07F7; Tue, 31 May 2011 09:43:38 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110531164338.B7E1DE07F7@ietfa.amsl.com> Date: Tue, 31 May 2011 09:43:38 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 06 Jun 2011 08:11:12 -0700 Subject: [secdir] [new-work] WG Review: Recharter of Open Authentication Protocol (oauth) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 16:43:40 -0000 A modified charter has been submitted for the Open Authentication Protocol (oauth) working group in the Security Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 7, 2011. Web Authorization Protocol Working Group (oauth) ----------------------- Last modified: 2011-05-11 Current Status: Active Working Group Chairs: Barry Leiba Hannes Tschofenig Blaine Cook Area Director: Stephen Farrell Tech Advisor: Peter Saint-Andre Mailing List Address: oauth@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/oauth Archive: http://www.ietf.org/mail-archive/web/oauth/ Description of Working Group The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account. OAuth encompasses * a mechanism for a user to authorize issuance of credentials that a third party can use to access resources on the user's behalf and * a mechanism for using the issued credentials to authenticate HTTP requests. In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). The working group has since been developing OAuth 2.0, a standards-track version that will reflect IETF consensus. Version 2.0 will consider the implementation experience with version 1.0, a discovered security vulnerability (session fixation attack), the use cases and functionality proposed with OAuth WRAP [draft-hardt-oauth-01] and will * improve the terminology used, * consider broader use cases, * embody good security practices, * improve interoperability, and * provide guidelines for extensibility. The working group will develop authentication schemes for peers/servers taking part in OAuth (accessing protected resources). This includes * an HMAC-based authentication mechanism This document aims to provide a general purpose MAC authentication scheme that can be used both with OAuth 2.0 but also with other use cases. The WG will work with the security and applications area directors to ensure that this work gets appropriate review, e.g. via additional last calls in other relevant working groups such as HTTPBIS, * a specification for access protected by Transport Layer Security (bearer tokens), * an extension to OAuth 2.0 to allow access tokens to be requested when a client is in possession of a SAML assertion. A separate informational description will be produced to provide additional security analysis for audiences beyond the community of protocol implementers. Milestones will be added for the later items after the near-term work has been completed. Goals and Milestones May 2011 Submit 'HTTP Authentication: MAC Authentication' as a working group item May 2011 Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item Jul 2011 Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard Jul 2011 Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard Aug 2011 Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard Oct 2011 Submit 'SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0' to the IESG for consideration as a Proposed Standard Oct 2011 Re-chartering working group _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Thu Jun 2 10:56:09 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F95AE082E; Thu, 2 Jun 2011 10:56:09 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id F2A5AE082B; Thu, 2 Jun 2011 10:56:02 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110602175602.F2A5AE082B@ietfa.amsl.com> Date: Thu, 2 Jun 2011 10:56:02 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 06 Jun 2011 08:11:12 -0700 Subject: [secdir] [new-work] WG Review: IPv6 Site Renumbering (6renum) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 17:56:09 -0000 A new IETF working group has been proposed in the Operations and Management Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Thursday, June 9, 2011. IPv6 Site Renumbering (6renum) ------------------------------- Last Modified: 2011-06-02 Current Status: Proposed Working Group Chairs: TBD Area Director: Ron Bonica Mailing list Address: renum@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/renum Archive: http://www.ietf.org/mail-archive/web/renum/ Description of Working Group ----------- As outlined in RFC 5887, renumbering, especially for medium to large sites and networks, is currently viewed as an expensive, painful, and error-prone process, avoided by network managers as much as possible. As IPv6 adoption begins to gather momentum, those managers may turn to PI addressing for IPv6 to attempt to minimise the need for future renumbering. However, such an approach would create very serious BGP4 scaling problems if used by millions of end sites; it is thus desirable to develop tools, techniques and practices that may make renumbering a simpler process, to reduce demand for IPv6 PI space. In addition, as RFC 5887 describes, there are other triggers that mean some cases of renumbering are unavoidable, so it should be considered a given that a site may need partial or complete renumbering at some stage. Strategically it is thus important to implement and deploy techniques that facilitate simpler IPv6 site renumbering, so that as IPv6 becomes universally deployed, renumbering can be viewed as a more routine event. This includes consideration of how the initial assignment and subsequent management of address information is performed, as this will affect future renumbering operations. For renumbering to become more routine, a systematic address management approach will be essential. A large site with a short prefix will be divided into subnets with longer prefixes. In this scenario, renumbering or partial renumbering can be complicated. Aggregation, synchronisation, coordination, etc., need to be carefully managed, and the use of manually inserted address literals minimised. In unmanaged scenarios, consideration may need to be made for 'flag day' renumbering (in contrast to the procedure described in RFC4192). The task of the 6RENUM working group is to document existing renumbering practices for managed (enterprise) and unmanaged (SOHO) networks, to identify specific renumbering problems in the context of site-wide renumbering, and to then recharter with a view to develop point solutions and system solutions to address those problems or to stimulate such development in other working groups if appropriate. The principal target will be solutions for IPv6. RFC 4192, RFC 5887, and draft-jiang-ipv6-site-renum-guideline are starting points for this work. Goals/deliverables ------------------ The goals of the 6RENUM working group are: 1. To undertake scenario descriptions, including documentation of current capability inventories and existing BCPs for managed (enterprise) and unmanaged (SOHO) networks. These texts should contribute towards the gap analysis and provide an agreed basis for subsequent WG rechartering towards development of solutions (potentially in other WGs) and improved practices. Operator input will be of particularly high value for this stage. 2. To examine fully automatic, self-organising networks (manet/autoconf) as a possible third scenario. 3. To perform a gap analysis for renumbering practices, drawing on RFCs 4192 and 5887, to identify generic issues for network design, network management, and renumbering operations. The scenario texts will contribute to the analysis. 4. To document existing IP address management models and practices with a view to proposing (at a high level) an appropriate model to allow simplification of any partial or full site renumbering process (this would likely be applicable to managed rather than unmanaged scenarios). The general methodology for the WG will be to first build managed and unmanaged baseline scenario descriptions, while in parallel undertaking an initial gap analysis from existing work in (at least) RFC4192 and RFC5877. As the scenario texts harden, their contributions will be incorporated into the gap analysis, which can be published once the scenarios are completed. The following topics are out of scope for the working group: 1. Renumbering avoidance; this can perhaps be considered by appropriate IRTF groups. As documented in RFC5887, renumbering cannot be completely avoided. The WG is limited to dealing with how to renumber when it is unavoidable. 2. IPv4 renumbering. While many sites are likely to run dual-stack, IPv6 is the future and, especially given concerns over extensive use of IPv6 PI, the most appropriate place to focus effort. 3. ISP renumbering; this is potentially the most complex renumbering case. More benefit can be achieved by focusing effort on site renumbering. The site analysis should include the ISP's role in its own renumbering event. A recharter of the WG will be possible once the gap analysis and scenario descriptions are completed, and the IP address management ('numbering tool') review and (high level) proposal have been published. The rechartering will identify more specific work items within the 6RENUM WG or appropriate protocol WGs. Milestones ---------- Aug 2011 managed (enterprise) scenario draft ready for WG adoption (partly based on draft-jiang-ipv6-site-renum-guideline) Aug 2011 unmanaged (SOHO) scenario draft ready for WG adoption Oct 2011 gap analysis document ready for WG adoption (already some considerations in RFC5887 and draft-jiang-ipv6-site-renum-guideline) Oct 2011 management model draft ready for WG adoption Jan 2012 managed (enterprise) scenario draft ready for WGLC Jan 2012 unmanaged (SOHO) scenario draft ready for WGLC Feb 2012 management model ready for WGLC Mar 2012 gap analysis document ready for WGLC Apr 2012 recharter WG towards solution space _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Fri Jun 3 08:37:38 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCA4E07A4; Fri, 3 Jun 2011 08:37:38 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id E001CE079F; Fri, 3 Jun 2011 08:37:36 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110603153736.E001CE079F@ietfa.amsl.com> Date: Fri, 3 Jun 2011 08:37:36 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 06 Jun 2011 08:11:12 -0700 Subject: [secdir] [new-work] REVISED WG Review: IPv6 Site Renumbering (6renum) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 15:37:39 -0000 A new IETF working group has been proposed in the Operations and Management Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Friday, June 10, 2011. IPv6 Site Renumbering (6renum) ------------------------------- Last Modified: 2011-06-03 Current Status: Proposed Working Group Chairs: TBD Area Director: Ron Bonica Mailing list Address: renum@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/renum Archive: http://www.ietf.org/mail-archive/web/renum/ Description ----------- As outlined in RFC 5887, renumbering, especially for medium to large sites and networks, is currently viewed as an expensive, painful, and error-prone process, avoided by network managers as much as possible. As that RFC describes, there are triggers that mean some cases of renumbering are unavoidable, so it should be considered a given that a site may need partial or complete renumbering at some stage. It is thus important to implement and deploy techniques that facilitate simpler IPv6 site renumbering, so that as IPv6 becomes universally deployed, renumbering can be viewed as a more routine event. This includes consideration of how the initial assignment and subsequent management of address information is performed, as this will affect future renumbering operations. If IPv6 site renumbering continues to be considered difficult, network managers will turn to PI addressing for IPv6 to attempt to minimise the need for future renumbering. However, widespread use of PI may create very serious BGP4 scaling problems. It is thus desirable to develop tools and practices that may make renumbering a simpler process to reduce demand for IPv6 PI space. Renumbering, or partial renumbering, can be complicated in an enterprise site where a short prefix is divided into subnets with longer prefixes. Aggregation, synchronisation, coordination, etc., need to be carefully managed, and the use of manually inserted address literals minimised. Other factors such as applications binding long-term to low level IP addresses may add constraints to what can be realistically achieved, but identifying and documenting such factors is a useful objective. In some scenarios, consideration may also need to be made for 'flag day' renumbering (in contrast to the procedure described in RFC4192). The task of the 6RENUM working group is to document existing renumbering practices for enterprise site networks and to identify specific renumbering problems or 'gaps' in the context of partial or site-wide renumbering. Completion of these tasks should provide a basis for future work to identify and develop point solutions or system solutions to address those problems or to stimulate such development in other working groups as appropriate. 6RENUM is chartered to perform an analysis of IPv6 site renumbering. If the analysis leads to conclusions that are also applicable to IPv4 that will be an advantage, but it is not an objective of the WG to make its outputs more widely available than IPv6. Similarly the WG is targeting enterprise networks, but the analysis may also be applicable to SOHO or other (e.g. ad-hoc) scenarios. It may be that for site renumbering to become more routine, a systematic address management approach will be required. By documenting current practices and undertaking a gap analysis, we should become better informed of the requirements of such an approach. Post-analysis rechartering may lead to further work in this area. RFC 4192, RFC 5887, and draft-jiang-ipv6-site-renum-guideline are starting points for this work. Goals/deliverables ------------------ The goals of the 6RENUM working group are: 1. To undertake scenario descriptions, including documentation of current capability inventories and existing BCPs, for enterprise networks, including managed and unmanaged elements. These texts should contribute towards a gap analysis and provide an agreed basis for subsequent WG rechartering towards development of solutions (which may be more appropriate for other WGs to undertake) and improved practices. Operator input will be of high value for this text. 2. To perform a gap analysis for renumbering practices, to identify generic issues for network design, network management, address management and renumbering operations. The methodology for the WG will be to begin building the enterprise scenario description while in parallel constructing an initial gap analysis drawing on existing work in (at least) RFC4192 and RFC5887. As the scenario text hardens, its contributions will be incorporated into the more detailed gap analysis, which can be published once the scenario text is completed. The deliverables are thus the scenario and gap analysis texts. The following topics are out of scope for the working group: 1. Renumbering avoidance; this can perhaps be considered by appropriate IRTF groups. As documented in RFC5887, renumbering cannot be completely avoided. The WG is limited to dealing with how to renumber when it is unavoidable. 2. IPv4 renumbering. While many sites are likely to run dual-stack, IPv6 is the future and, especially given concerns over extensive use of IPv6 PI, the most appropriate place to focus effort. 3. ISP renumbering; this is potentially the most complex renumbering case. However, more benefit can be achieved by focusing effort on site renumbering. The enterprise site analysis should include the ISP's role in the site's renumbering events. 4. Neither SOHO nor manet networks are targeted by the WG. However, if outputs from the WG are applicable to those scenarios, that would be an advantage. A recharter of the WG will be possible once the gap analysis and scenario description are completed and published. Such rechartering would identify more specific work items within the 6RENUM WG or appropriate protocol WGs, and may include a proposal for work on a systematic address management approach. Milestones ---------- Oct 2011 IPv6 enterprise site scenario draft ready for WG adoption Nov 2011 Gap analysis document ready for WG adoption Jun 2012 IPv6 enterprise site scenario draft ready for WGLC Jul 2012 Gap analysis document ready for WGLC _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From derek@ihtfp.com Mon Jun 6 08:26:39 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDE721F843D; Mon, 6 Jun 2011 08:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAP4jckDP9Lx; Mon, 6 Jun 2011 08:26:39 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 69C3621F843A; Mon, 6 Jun 2011 08:26:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 68E1D26036E; Mon, 6 Jun 2011 11:26:38 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 31006-01; Mon, 6 Jun 2011 11:26:37 -0400 (EDT) Received: from pgpdev.ihtfp.org (IHTFP-DHCP-100.IHTFP.ORG [192.168.248.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 35EE52602A9; Mon, 6 Jun 2011 11:26:37 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.4/8.14.3/Submit) id p56FQZ5m007524; Mon, 6 Jun 2011 11:26:35 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Mon, 06 Jun 2011 11:26:34 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: tcpm-chairs@tools.ietf.org, ananth@cisco.com, mbashyam@ocarinanetworks.com, mahesh@cisco.com Subject: [secdir] sec-dir review of draft-ietf-tcpm-persist-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 15:26:40 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document clarifies the Zero Window Probes (ZWP) described in Requirements for Internet Hosts [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. The security considerations section should refer to section 4 as a description of the DoS attack, not section 3. Although it should still refer to section 3. Honestly, I find it confusing that the attack is described after some of the mitigation techniques. It would make the document flow better, IMHO, if you describe the attack and then describe how to mitigate the attack. The document also mentions orphaned connections but does not mention how to mitigate an attack against systems that have orphaned connections. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From ananth@cisco.com Mon Jun 6 10:17:04 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAED11E8150; Mon, 6 Jun 2011 10:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.274 X-Spam-Level: X-Spam-Status: No, score=-10.274 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g1sLJ9dlX9l; Mon, 6 Jun 2011 10:17:02 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id DE79811E81B0; Mon, 6 Jun 2011 10:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=18506; q=dns/txt; s=iport; t=1307380619; x=1308590219; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=CC3vRE9v2OodcjCyrfJtxdf2eiUsdri8Q8P0yBGrhzg=; b=EEh2kkPMlTUxxymrzusLuUmWdbEfqRVa1ZAwADJ3cVEu/u7CsKdGCVIZ yGU3sQ4jUIVN7AHodMlDl5/W36oh3GRu+BC0KvrsEksYa0BmvvtvaV2tI PUsH7iwQ8ny5SvlRkdMwTP/bxHSyIy8iiWnTR6/7IcELIv0YMCk5n72hG c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwBAHIK7U2rRDoG/2dsb2JhbABTglKUcI5id6tdnWyGIQSGdI5Wiwk X-IronPort-AV: E=Sophos;i="4.65,327,1304294400"; d="scan'208,217";a="371165872" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 06 Jun 2011 17:16:46 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p56HGkbZ008440; Mon, 6 Jun 2011 17:16:46 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Jun 2011 10:16:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC246D.830875D4" Date: Mon, 6 Jun 2011 10:16:45 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580CE2C5DF@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4DED059E.5000401@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: sec-dir review of draft-ietf-tcpm-persist-04.txt Thread-Index: Acwkagc1oNjbkzBbSn2NwzFTgIOqpAAAXvtA References: <4DED059E.5000401@cisco.com> From: "Anantha Ramaiah (ananth)" To: "Mahesh Jethanandani (mahesh)" , "Derek Atkins" X-OriginalArrivalTime: 06 Jun 2011 17:16:46.0361 (UTC) FILETIME=[83872890:01CC246D] Cc: tcpm-chairs@tools.ietf.org, mbashyam@ocarinanetworks.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] sec-dir review of draft-ietf-tcpm-persist-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 17:17:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC246D.830875D4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 That's right, the document in its current form blessed by TCPM is a simple clarification document of persist condition. =20 -Anantha PS:- =20 FWIW, Linux handles such a scenario. (orphaned connections) =20 Code snippet of the relevant function below :- (tcp_timer.c) =20 /* Do not allow orphaned sockets to eat all our resources. * This is direct violation of TCP specs, but it is required * to prevent DoS attacks. It is called when a retransmission timeout * or zero probe timeout occurs on orphaned socket. * * Criteria is still not confirmed experimentally and may change. * We kill the socket, if: * 1. If number of orphaned sockets exceeds an administratively configured * limit. * 2. If we have strong memory pressure. */ static int tcp_out_of_resources(struct sock *sk, int do_reset) { struct tcp_sock *tp =3D tcp_sk(sk); int orphans =3D atomic_read(&tcp_orphan_count); =20 /* If peer does not open window for long time, or did not transmit * anything for long time, penalize it. */ if ((s32)(tcp_time_stamp - tp->lsndtime) > 2*TCP_RTO_MAX || !do_reset) orphans <<=3D 1; =20 /* If some dubious ICMP arrived, penalize even more. */ if (sk->sk_err_soft) orphans <<=3D 1; =20 if (tcp_too_many_orphans(sk, orphans)) { if (net_ratelimit()) printk(KERN_INFO "Out of socket memory\n"); =20 /* Catch exceptional cases, when connection requires reset. * 1. Last segment was sent recently. */ if ((s32)(tcp_time_stamp - tp->lsndtime) <=3D TCP_TIMEWAIT_LEN || /* 2. Window is closed. */ (!tp->snd_wnd && !tp->packets_out)) do_reset =3D 1;=20 if (do_reset) tcp_send_active_reset(sk, GFP_ATOMIC); tcp_done(sk); NET_INC_STATS_BH(LINUX_MIB_TCPABORTONMEMORY); return 1; } return 0; } =20 =20 From: Mahesh Jethanandani (mahesh)=20 Sent: Monday, June 06, 2011 9:52 AM To: Derek Atkins Cc: iesg@ietf.org; secdir@ietf.org; tcpm-chairs@tools.ietf.org; mbashyam@ocarinanetworks.com; Anantha Ramaiah (ananth) Subject: Re: sec-dir review of draft-ietf-tcpm-persist-04.txt =20 Derek, After lot of discussion regarding the scope of this document, the WG felt that the draft should be limited to clarifying the language in RFC 1122. If you were to look at earlier versions of the draft, we had a section in the draft that talked about possible mitigation techniques and socket level API changes that would be needed to be able to determine which connections were stuck in persist condition. Once the scope was defined as clarifying senders behavior in persist condition, the WG felt that it was not necessary to have a section that talked about possible solution. The section was therefore removed. On 6/6/2011 8:26 AM, Derek Atkins wrote:=20 The document also mentions orphaned connections but does not mention how to mitigate an attack against systems that have orphaned connections. =20 -- mj ------_=_NextPart_001_01CC246D.830875D4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

That’s right, the document in its current form blessed by TCPM = is a simple clarification document of persist = condition.

 

-Anantha

PS:-

 

FWIW, Linux handles such a scenario.  (orphaned = connections)

 

Code snippet of the relevant function below :- = (tcp_timer.c)

 

/* Do not allow orphaned sockets to eat all our = resources.

* This is direct violation of TCP specs, but it is = required

* to prevent DoS attacks. It is called when a retransmission = timeout

* or zero probe timeout occurs on orphaned = socket.

*

* Criteria is still not confirmed experimentally and may = change.

* We kill the socket, if:

* 1. If number of orphaned sockets exceeds an administratively = configured

*    limit.

* 2. If we have strong memory pressure.

*/

static int tcp_out_of_resources(struct sock *sk, int = do_reset)

{

        struct tcp_sock *tp =3D = tcp_sk(sk);

        int orphans =3D = atomic_read(&tcp_orphan_count);

 

        /* If peer does not open = window for long time, or did not transmit

         * anything for long = time, penalize it. */

    if ((s32)(tcp_time_stamp - tp->lsndtime) > = 2*TCP_RTO_MAX || !do_reset)

           &nbs= p;    orphans <<=3D 1;

 

        /* If some dubious ICMP = arrived, penalize even more. */

        if = (sk->sk_err_soft)

           &nbs= p;    orphans <<=3D 1;

 

        if = (tcp_too_many_orphans(sk, orphans)) {

           &nbs= p;    if (net_ratelimit())

           &nbs= p;            = printk(KERN_INFO "Out of socket = memory\n");

 

           &nbs= p;    /* Catch exceptional cases, when connection = requires reset.

           &nbs= p;     *      1. Last = segment was sent recently. */

           &nbs= p;    if ((s32)(tcp_time_stamp - tp->lsndtime) <=3D = TCP_TIMEWAIT_LEN ||

           &nbs= p;        /*  2. Window is = closed. */

           &nbs= p;        (!tp->snd_wnd && = !tp->packets_out))

          =             &= nbsp; do_reset =3D 1;

         &= nbsp;      if (do_reset)

           &nbs= p;           =    tcp_send_active_reset(sk, = GFP_ATOMIC);

         &= nbsp;  tcp_done(sk);

           &nbs= p;    = NET_INC_STATS_BH(LINUX_MIB_TCPABORTONMEMORY);

           &nbs= p;    return 1;

        }

        return = 0;

}

 

 

From: Mahesh Jethanandani (mahesh)
Sent: Monday, June 06, = 2011 9:52 AM
To: Derek Atkins
Cc: iesg@ietf.org; = secdir@ietf.org; tcpm-chairs@tools.ietf.org; = mbashyam@ocarinanetworks.com; Anantha Ramaiah = (ananth)
Subject: Re: sec-dir review of = draft-ietf-tcpm-persist-04.txt

 

Derek,

After lot of discussion regarding the = scope of this document, the WG felt that the draft should be limited to = clarifying the language in RFC 1122. If you were to look at earlier = versions of the draft, we had a section in the draft that talked about = possible mitigation techniques and socket level API changes that would = be needed to be able to determine which connections were stuck in = persist condition.

Once the scope was defined as clarifying = senders behavior in persist condition, the WG felt that it was not = necessary to have a section that talked about possible solution. The = section was therefore removed.

On 6/6/2011 8:26 AM, Derek Atkins = wrote:

The document also mentions orphaned = connections but does not mention
how to mitigate an attack against = systems that have orphaned
connections.

 

-- = mj

------_=_NextPart_001_01CC246D.830875D4-- From mahesh@cisco.com Mon Jun 6 09:51:44 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB7911E818E; Mon, 6 Jun 2011 09:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1SxCe9j2shw; Mon, 6 Jun 2011 09:51:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5E711E8186; Mon, 6 Jun 2011 09:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mahesh@cisco.com; l=2570; q=dns/txt; s=iport; t=1307379103; x=1308588703; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=+Qtm4VXOLHHryWq5M80uW5SYjJOA9yawlZtwNpnXV3g=; b=fxxSoa/d6Lp+mmQ+bODi804PNBkdxYceJWwEUR0Lr6kMoCNLj9L52VHr Amo732b1D8N1eeCsnsrpjfcKes+bK6eRzIJDEfesOrANSA8zKVUIaZC/5 ILNSW5TQW6VyrUZbsi3iJpT2r1+xyInNTsBJHtGXPDS7c8/ddO6hSSdCj o=; X-IronPort-AV: E=Sophos;i="4.65,327,1304294400"; d="scan'208,217";a="708925894" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 06 Jun 2011 16:51:43 +0000 Received: from [10.21.106.173] (sjc-vpnasa-682.cisco.com [10.21.106.173]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p56GpgVT028090; Mon, 6 Jun 2011 16:51:43 GMT Message-ID: <4DED059E.5000401@cisco.com> Date: Mon, 06 Jun 2011 09:51:42 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Derek Atkins References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040703030503010900070709" X-Mailman-Approved-At: Mon, 06 Jun 2011 10:21:21 -0700 Cc: tcpm-chairs@tools.ietf.org, mbashyam@ocarinanetworks.com, "Anantha Ramaiah \(ananth\)" , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] sec-dir review of draft-ietf-tcpm-persist-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 16:51:44 -0000 This is a multi-part message in MIME format. --------------040703030503010900070709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Derek, After lot of discussion regarding the scope of this document, the WG felt that the draft should be limited to clarifying the language in RFC 1122. If you were to look at earlier versions of the draft, we had a section in the draft that talked about possible mitigation techniques and socket level API changes that would be needed to be able to determine which connections were stuck in persist condition. Once the scope was defined as clarifying senders behavior in persist condition, the WG felt that it was not necessary to have a section that talked about possible solution. The section was therefore removed. On 6/6/2011 8:26 AM, Derek Atkins wrote: > The document also mentions orphaned connections but does not mention > how to mitigate an attack against systems that have orphaned > connections. -- mj --------------040703030503010900070709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Derek,

After lot of discussion regarding the scope of this document, the WG felt that the draft should be limited to clarifying the language in RFC 1122. If you were to look at earlier versions of the draft, we had a section in the draft that talked about possible mitigation techniques and socket level API changes that would be needed to be able to determine which connections were stuck in persist condition.

Once the scope was defined as clarifying senders behavior in persist condition, the WG felt that it was not necessary to have a section that talked about possible solution. The section was therefore removed.

On 6/6/2011 8:26 AM, Derek Atkins wrote:
The document also mentions orphaned connections but does not mention
how to mitigate an attack against systems that have orphaned
connections.

-- mj
--------------040703030503010900070709-- From hartmans@mit.edu Tue Jun 7 08:23:55 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4DD11E8112; Tue, 7 Jun 2011 08:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kcqk6fh-uFIy; Tue, 7 Jun 2011 08:23:54 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1733111E80F0; Tue, 7 Jun 2011 08:23:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7F6692034A; Tue, 7 Jun 2011 11:19:25 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C86A14426; Tue, 7 Jun 2011 11:23:49 -0400 (EDT) From: Sam Hartman To: iesg@ietf.org, secdir@ietf.org, draft-ietf-pcn-sm-edge-behaviour@tools.ietf.org Date: Tue, 07 Jun 2011 11:23:49 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [secdir] Secdir review of draft-ietf-pcn-sm-edge-behaviour-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 15:23:55 -0000 I've reviewed this draft for the security directorate. This draft specifies the PCN protocol for the mode in which only a single mark is present. This protocol operates among a set of nodes trusted to enforce PCN behavior and to properly police traffic entering and leaving the network. This document referrs to a previous RFC for security considerations. The considerations documentedseem adequate, and for that reason I have no comments on this document. Had I been assigned the previous RFC, I might have had more comments, but we've already reached consensus on that document and published it, so let's move forward. From mouse008@gmail.com Mon Jun 6 18:41:52 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78CE21F8519; Mon, 6 Jun 2011 18:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvxIzAPapEZ8; Mon, 6 Jun 2011 18:41:52 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E834B21F8518; Mon, 6 Jun 2011 18:41:51 -0700 (PDT) Received: by vxg33 with SMTP id 33so4073244vxg.31 for ; Mon, 06 Jun 2011 18:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:subject:date:message-id:to :mime-version:x-mailer; bh=r9uOR2P1557qv8m4CltOZaSr0Vhe1nwtRskx9kkZFVE=; b=qd03SVaYmklNmgXWB6dC4g+ZurApnsjldRMKomZT4rZ0GNn8hZJiYr9KkqguBWJQtH xnktAsLIOydW1F2/t075pDGvpr7q/48+pth5LycVyosor9OGeF6N5NoFZndwSpGLoe4o zGvMmNTDD/j3cZGRST1/7Gy+35goQ0HbTJDkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer; b=kbEKc5gh7j131mlUv0Zj1DQ0Ns1Sex/gD2OBMEP7XoHoAWtgP65hvccBlhDuGt2qQA jcIXjOxBuxCz0j5ndQktAPQeIJ0b4XPj5up2PeScK8QvysX4YJyGznYmS0lsMyqTtBFl UPax9XjrGWxDN78M09FojcHButwM1Cg7uxXPA= Received: by 10.52.187.164 with SMTP id ft4mr4219302vdc.59.1307410910390; Mon, 06 Jun 2011 18:41:50 -0700 (PDT) Received: from [192.168.1.106] (c-24-63-227-189.hsd1.ma.comcast.net [24.63.227.189]) by mx.google.com with ESMTPS id q1sm1566927vdt.11.2011.06.06.18.41.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2011 18:41:49 -0700 (PDT) From: Uri Blumenthal Content-Type: multipart/signed; boundary=Apple-Mail-7-538388134; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 6 Jun 2011 21:36:19 -0400 Message-Id: <5599350D-46D8-4AD4-B61C-F21DD7408290@ll.mit.edu> To: draft-ietf-sipcore-location-conveyance@tools.ietf.org, secdir@ietf.org, iesg@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 08 Jun 2011 02:04:24 -0700 Subject: [secdir] draft-ietf-sipcore-location-conveyance security review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 01:44:08 -0000 --Apple-Mail-7-538388134 Content-Type: multipart/alternative; boundary=Apple-Mail-6-538381371 --Apple-Mail-6-538381371 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I reviewed (browsed) the draft-ietf-sipcore-location-conveyance-08, and = found it well-written. Its Security Considerations section describes = potential impacts of this draft (privacy is a big one) and how they can = be mitigated. I am OK with this draft. -- _______________________________________________ Uri Blumenthal Voice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 MIT Lincoln Laboratory Cell: (339) 223-5363 244 Wood Street Email: Lexington, MA 02420-9185 =20 Web: http://www.ll.mit.edu/CST/ MIT LL Root CA:=20 https://www.ll.mit.edu/labcertificateauthority.html --Apple-Mail-6-538381371 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = reviewed (browsed) the draft-ietf-sipcore-location-conveyance-08, and = found it well-written. Its Security Considerations section describes = potential impacts of this draft (privacy is a big one) and how they can = be mitigated.

I am OK with this draft.
--uri@ll.mit.edu>
Lexington, MA =  02420-9185       

Web:  http://www.ll.mit.edu/CST/<= /font>
MIT LL Root = CA: 

= --Apple-Mail-6-538381371-- --Apple-Mail-7-538388134 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIZDCCBC4w ggOXoAMCAQICAgUtMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1B SUwgQ0EtMTgwHhcNMDgxMDA3MTM0NjExWhcNMTExMDA4MTM0MzE0WjB8MQswCQYDVQQGEwJVUzEY MBYGA1UEChMPVS5TLiBHT1ZFUk5NRU5UMQwwCgYDVQQLEwNET0QxDDAKBgNVBAsTA1BLSTETMBEG A1UECxMKQ09OVFJBQ1RPUjEiMCAGA1UEAxMZQkxVTUVOVEhBTC5VUkkuOTAwMDAwMTE4ODCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA5HoNOuGFBqxTQYLhZhz9XCSxgKLl4ZtFrfNQ+0hAAuwe IvkDP+PMtBtCcELmqMFdDvkEnLy2H8flvk0kKjf/xB4jNAR60S02OT9ASXKgnYrBduyn6kksH1jP lpgtse+D5ir0U3e/2nlhz3l5JkjTXjWNPgYklkh+s+N9s01332cCAwEAAaOCAdwwggHYMB8GA1Ud IwQYMBaAFMVN9mZVWkld1z31PIiCzwaayRCkMIHdBgNVHR8EgdUwgdIwOqA4oDaGNGh0dHA6Ly9j cmwuY2hhbWIuZGlzYS5taWwvZ2V0Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMTgwgZOggZCggY2GgYps ZGFwOi8vY3JsLmNoYW1iLmRpc2EubWlsL2NuJTNkRG9EJTIwRU1BSUwlMjBDQS0xOCUyY291JTNk UEtJJTJjb3UlM2REb0QlMmNvJTNkVS5TLiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y2VydGlmaWNh dGVSZXZvY2F0aW9uTGlzdDtiaW5hcnkwDgYDVR0PAQH/BAQDAgbAMBYGA1UdIAQPMA0wCwYJYIZI AWUCAQsFMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MHMGCCsGAQUFBwEBBGcwZTBBBggrBgEF BQcwAoY1aHR0cDovL2NybC5jaGFtYi5kaXNhLm1pbC9nZXRzaWduP0RPRCUyMEVNQUlMJTIwQ0Et MTgwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMB0GA1UdDgQWBBQxskFNKUGAUWuA Apog2vgQ4r4GxTANBgkqhkiG9w0BAQUFAAOBgQBvqHoTli+JBiCjyHR0ZEzvE2hmZSpcwIGqLM/X FjXoWg9iKKnc2d6lusaIBc4umKWr12pTKjirEEvceRYrkf2rptpg6Pi0MpJ8yc7bkU/ZtD0ocBDC x4SwjD0BfA+DCJRqxgUzCNj25cyXvLqyGhzVqraIjmJ/tYRrhSBZkfB5bTCCBC4wggOXoAMCAQIC AgUuMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1l bnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMTgw HhcNMDgxMDA3MTM0NjExWhcNMTExMDA4MTM0MzE0WjB8MQswCQYDVQQGEwJVUzEYMBYGA1UEChMP VS5TLiBHT1ZFUk5NRU5UMQwwCgYDVQQLEwNET0QxDDAKBgNVBAsTA1BLSTETMBEGA1UECxMKQ09O VFJBQ1RPUjEiMCAGA1UEAxMZQkxVTUVOVEhBTC5VUkkuOTAwMDAwMTE4ODCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEAwv5rDLp9l4tGnQHedNA0KSksSPghXPgvuVajsarFUREXD9ErhjZEBPcK XM4lEHApK84M1KW00lQyg0Dbc1NZ919Oxpua4twHyE+BwwpH746BBgz2nuIzrb+NkIdjwDiEvbsW uj/9ZVvpoFPaDid5wSjImIsjvv2xz78XOQW/SksCAwEAAaOCAdwwggHYMB8GA1UdIwQYMBaAFMVN 9mZVWkld1z31PIiCzwaayRCkMIHdBgNVHR8EgdUwgdIwOqA4oDaGNGh0dHA6Ly9jcmwuY2hhbWIu ZGlzYS5taWwvZ2V0Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMTgwgZOggZCggY2GgYpsZGFwOi8vY3Js LmNoYW1iLmRpc2EubWlsL2NuJTNkRG9EJTIwRU1BSUwlMjBDQS0xOCUyY291JTNkUEtJJTJjb3Ul M2REb0QlMmNvJTNkVS5TLiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y2VydGlmaWNhdGVSZXZvY2F0 aW9uTGlzdDtiaW5hcnkwDgYDVR0PAQH/BAQDAgUgMBYGA1UdIAQPMA0wCwYJYIZIAWUCAQsFMBkG A1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MHMGCCsGAQUFBwEBBGcwZTBBBggrBgEFBQcwAoY1aHR0 cDovL2NybC5jaGFtYi5kaXNhLm1pbC9nZXRzaWduP0RPRCUyMEVNQUlMJTIwQ0EtMTgwIAYIKwYB BQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMB0GA1UdDgQWBBSW9Z4NeIXES/JdztNAM3FqE0zm nTANBgkqhkiG9w0BAQUFAAOBgQCsc24CRgr+FkNaILXJ17nOYQPCDNeTADa3vO2U0wR3fwg5fQsd mOGQlz07pxFP68rKrfzc6WOLsuNgNVKOBy5dP1+4mGpowxJ9nJ+IurUK49qmmeGh1+VfKSU6CkRM FFuVA2hhM9lAJuDARn2CNNxgrhkbsKy5TuKBqNDj1UpG7DGCAlQwggJQAgEBMGMwXTELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQ S0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0xOAICBS0wCQYFKw4DAhoFAKCCAUcwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwNjA3MDEzNjE5WjAjBgkqhkiG9w0B CQQxFgQUkR8lpHxS6O4KvqCM273CuvIBy+8wcgYJKwYBBAGCNxAEMWUwYzBdMQswCQYDVQQGEwJV UzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPRE9EIEVNQUlMIENBLTE4AgIFLjB0BgsqhkiG9w0BCRACCzFloGMwXTELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQ S0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0xOAICBS4wDQYJKoZIhvcNAQEBBQAEgYAwnKwRQLFe YJPtJqPrBSJRB20xHwC6d1urBkY10xoAEG3OqEkPvSXlGmbzy5wXRNX/ie1i0QRd+fr7JK3gWrQf 3PBxd2CtJCWJTZOQkTlJLynhhlPTwfNFVIwjogpO8H/fCvcWX92p47U3M1oirFqC3Ef6ABbEubqy t2o9PaWpSQAAAAAAAA== --Apple-Mail-7-538388134-- From new-work-bounces@ietf.org Tue Jun 7 08:47:57 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB02D228006; Tue, 7 Jun 2011 08:47:57 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 32F6AE07D0; Fri, 3 Jun 2011 14:07:52 -0700 (PDT) From: The IESG To: iab@iab.org, new-work@ietf.org, rhaines@ntia.doc.gov, raphael@anatel.gov.br, sup@niir.ru, philippe.aubineau@itu.int Mime-Version: 1.0 Message-Id: <20110603210752.32F6AE07D0@ietfa.amsl.com> Date: Fri, 3 Jun 2011 14:07:52 -0700 (PDT) X-Mailman-Approved-At: Tue, 07 Jun 2011 08:47:56 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 08 Jun 2011 02:04:24 -0700 Subject: [secdir] [new-work] WG Review: Protocol to Access White Space database (paws) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 15:47:57 -0000 In mid-April, the IESG requested external review of the draft charter for a proposed working group to focus on development of a "Protocol to Access White Space Databases" (paws). Based on discussions within the IESG, the draft charter has undergone significant revision. As a courtesy, the revised charter is being provided for informational purposes. Please send any comments on this revised charter to the IESG mailing list (iesg@ietf.org) by Wednesday, June 8, 2011. Protocol to Access White Space database (paws) ------------------------------------------------ Current Status: Proposed Working Group Last updated: 2011-06-02 Chairs: TBD Applications Area Directors: Pete Resnick Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Mailing lists: General Discussion: paws@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/paws Archive: http://www.ietf.org/mail-archive/web/paws/ Description of Working Group: Background Radio spectrum is a limited resource. National and international bodies assign different frequencies for specific uses, and in most cases license the rights to use these frequencies. Locally unused spectrum is commonly called "white space" and may be made available to other services on a basis of non-interference with the primary user of the frequencies concerned (if any). This technique can help "unlock" existing spectrum, for example to enable the wireless communications industry to provide more services over frequencies associated with unused television channels. An obvious requirement is that white space uses must not interfere with the primary use of the spectrum. This is achieved through spatial and/or temporal separation of the primary user and whitespace user with due consideration made to the radio characteristics of the two uses. Problem Statement The fundamental problem is enabling a radio device to determine, in a specific location and at specific time, if any white space is available for secondary use. There are two parties to such an interaction: 1. A database containing records about the protected contours (in space and time) of primary spectrum users. Typically, such databases will be populated and operated by the appropriate spectrum regulation bodies in a given locale. 2. A radio device that wishes to query such a database. Typically, the the nature of the query will depend on the needs of the device. The contents of white space databases, and the needs of radio devices, are being defined elsewhere. However, these parties need a protocol for communication that will enable radio devices to find out what white space is available at a given time in a given location. It is expected that white space databases will be reachable via the Internet, and that radio devices too will have some form of Internet connectivity, directly or indirectly. Therefore, it is appropriate to define an Internet-based protocol for querying white space databases and receiving responses from such databases. In rough outline, such a protocol would enable a radio device that knows its location to complete the following tasks: 1. Determine the relevant white space database to query. 2. Connect to the database using a well-defined access method. 3. Provide its geolocation and perhaps other data to the database using a well-defined wire format for querying the database. 4. Receive in return a list of currently available white space using a well-defined wire format for returning information. Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. Objectives The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database. 2. Standardize a method for accessing a white space database. 3. Standardize wire formats to be carried over the database access method (i.e., formats for queries and responses). 4. Ensure that the discovery mechanism, database access method, and wire formats have appropriate security levels in place. By "standardize" is not meant that the working group will necessarily develop new technologies. In completing its work, the group will: - Evaluate existing discovery mechanisms to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for discovering a white space database. Examples might include DNS. - Evaluate existing application-layer transport protocols to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for use as a building block for communication between location- aware devices and white space databases. If such a method exists, the group will reuse it; if not, the group will develop one. Examples might include HTTP. - Develop a method for querying a white space database. Such a method will utilize, so far as possible, the features of the application-layer transport protocol and not re-implement them in the new protocol. It will include mechanisms to verify that the requests and responses come from authorized sources, and that they have not been modified in transit. Examples might include LDAP. - Define extensible wire formats for both location-specific queries and location-specific responses for interaction with radio white space databases. The group will consider whether existing data formats can be reused. The protocol must protect both the channel enablement process and the privacy of users. Robust privacy and security mechanisms are needed to prevent: device identity spoofing, modification of device requests, modification of channel enablement information, impersonation of registered database services, and unauthorized disclosure of a device's location. The group will consider whether existing privacy and security mechanisms can be reused. The task of defining the structure and contents of the databases themselves is out of scope. The group will standardize wire formats for communication between devices and databases, but not the information models for the databases, since those models are likely to be country-specific or application-specific. In addition, the particular data exchanged between a device and a database might depend on the ranges of radio spectrum that are to be used, the requirements of the database operators and their governing regulations, and other factors. Therefore, the database access method and the query/response data formats that are exchanged using that method need to be designed for extensibility rather than being tied to any specific spectrum, country, or phy/mac/air interface. For example, the working group should define extension points for the database access method and the wire formats that are used to query a database and respond to queries, so that use cases other than those currently envisioned can be addressed in the future if a community of interest wishes to do so. However, the access method and wire formats will incorporate relevant aspects of the parameters needed for the currently envisioned use cases to ensure proper operation. In accordance with existing IETF processes, the group will communicate and invite participation with other relevant standards bodies and groups, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships, including but not limited to IEEE 802.11af and IEEE 802.22. In order to ensure that it takes into account a broad range of possible use cases and requirements, the group should also reach out to other potential "customers" for a white space database access method and consider input from regulatory entities that are involved in the specification of the rules for secondary use of spectrum in specific radio bands. Deliverables 1. A description of the relevant use cases and requirements. This document shall be Informational. Subject to working group consensus, draft-probasco-paws-overview-usecases and draft-patil-paws-problem-stmt might be used as a starting point. 2. A specification of the mechanism for discovering a white space database, the method for accessing a white space database, and the wire format for querying and receiving responses from a white space database. This document shall be Standards Track. Milestones Oct 2011 Submit 'Use Cases and Requirements for Accessing a Radio White Space Database' to the IESG for publication as Informational Apr 2012 Submit 'Accessing a Radio White Space Database' to the IESG for publication as Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From derek@ihtfp.com Wed Jun 8 06:21:41 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C29F11E80D5; Wed, 8 Jun 2011 06:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubfa30z5BJai; Wed, 8 Jun 2011 06:21:40 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id AA6E911E80D2; Wed, 8 Jun 2011 06:21:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 9635526036E; Wed, 8 Jun 2011 09:21:37 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 22960-04; Wed, 8 Jun 2011 09:21:33 -0400 (EDT) Received: from pgpdev.ihtfp.org (IHTFP-DHCP-100.IHTFP.ORG [192.168.248.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 037B3260326; Wed, 8 Jun 2011 09:21:33 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.4/8.14.3/Submit) id p58DLWkd017519; Wed, 8 Jun 2011 09:21:32 -0400 From: Derek Atkins To: "Anantha Ramaiah \(ananth\)" References: <4DED059E.5000401@cisco.com> <0C53DCFB700D144284A584F54711EC580CE2C5DF@xmb-sjc-21c.amer.cisco.com> Date: Wed, 08 Jun 2011 09:21:32 -0400 In-Reply-To: <0C53DCFB700D144284A584F54711EC580CE2C5DF@xmb-sjc-21c.amer.cisco.com> (Anantha Ramaiah's message of "Mon, 6 Jun 2011 10:16:45 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: tcpm-chairs@tools.ietf.org, "Mahesh Jethanandani \(mahesh\)" , secdir@ietf.org, mbashyam@ocarinanetworks.com, iesg@ietf.org Subject: Re: [secdir] sec-dir review of draft-ietf-tcpm-persist-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 13:21:41 -0000 Hi, If this is the working group concensus then I would ask that you please add a paragraph or two to the Security Considerations section and explain that in more detail, please? Maybe base it on Mahesh's text below? Thanks! -derek "Anantha Ramaiah (ananth)" writes: > That=E2=80=99s right, the document in its current form blessed by TCPM is= a simple > clarification document of persist condition. > > -Anantha > > PS:- > > FWIW, Linux handles such a scenario. (orphaned connections) > > Code snippet of the relevant function below :- (tcp_timer.c) > > /* Do not allow orphaned sockets to eat all our resources. > > * This is direct violation of TCP specs, but it is required > > * to prevent DoS attacks. It is called when a retransmission timeout > > * or zero probe timeout occurs on orphaned socket. > > * > > * Criteria is still not confirmed experimentally and may change. > > * We kill the socket, if: > > * 1. If number of orphaned sockets exceeds an administratively configured > > * limit. > > * 2. If we have strong memory pressure. > > */ > > static int tcp_out_of_resources(struct sock *sk, int do_reset) > > { > > struct tcp_sock *tp =3D tcp_sk(sk); > > int orphans =3D atomic_read(&tcp_orphan_count); > > /* If peer does not open window for long time, or did not transmit > > * anything for long time, penalize it. */ > > if ((s32)(tcp_time_stamp - tp->lsndtime) > 2*TCP_RTO_MAX || !do_reset) > > orphans <<=3D 1; > > /* If some dubious ICMP arrived, penalize even more. */ > > if (sk->sk_err_soft) > > orphans <<=3D 1; > > if (tcp_too_many_orphans(sk, orphans)) { > > if (net_ratelimit()) > > printk(KERN_INFO "Out of socket memory\n"); > > /* Catch exceptional cases, when connection requires rese= t. > > * 1. Last segment was sent recently. */ > > if ((s32)(tcp_time_stamp - tp->lsndtime) <=3D TCP_TIMEWAI= T_LEN | > | > > /* 2. Window is closed. */ > > (!tp->snd_wnd && !tp->packets_out)) > > do_reset =3D 1; > > if (do_reset) > > tcp_send_active_reset(sk, GFP_ATOMIC); > > tcp_done(sk); > > NET_INC_STATS_BH(LINUX_MIB_TCPABORTONMEMORY); > > return 1; > > } > > return 0; > > } > > From: Mahesh Jethanandani (mahesh) > Sent: Monday, June 06, 2011 9:52 AM > To: Derek Atkins > Cc: iesg@ietf.org; secdir@ietf.org; tcpm-chairs@tools.ietf.org; > mbashyam@ocarinanetworks.com; Anantha Ramaiah (ananth) > Subject: Re: sec-dir review of draft-ietf-tcpm-persist-04.txt > > Derek, > > After lot of discussion regarding the scope of this document, the WG felt= that > the draft should be limited to clarifying the language in RFC 1122. If you > were to look at earlier versions of the draft, we had a section in the dr= aft > that talked about possible mitigation techniques and socket level API cha= nges > that would be needed to be able to determine which connections were stuck= in > persist condition. > > Once the scope was defined as clarifying senders behavior in persist > condition, the WG felt that it was not necessary to have a section that t= alked > about possible solution. The section was therefore removed. > > On 6/6/2011 8:26 AM, Derek Atkins wrote: > > The document also mentions orphaned connections but does not mention > how to mitigate an attack against systems that have orphaned > connections. > > -- mj > --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From barryleiba@gmail.com Thu Jun 9 23:13:48 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22ECC21F8523; Thu, 9 Jun 2011 23:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0H5rHIi6Oz1; Thu, 9 Jun 2011 23:13:47 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7AA21F8522; Thu, 9 Jun 2011 23:13:47 -0700 (PDT) Received: by gxk19 with SMTP id 19so1903825gxk.31 for ; Thu, 09 Jun 2011 23:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=OXEE5ysUzNHy5wWINUBDi773Y8icR6W2fW01bvszjAI=; b=irr3MiVqUDETdG73xfGxXc9e8f8XAEigRahxwoyX8nOqMAJ5wmNfKR1GJiAtplwZ5J +rDeAoYyLLh8ADIdbnZTikXvErAndwuPIDd9L/xEbstck2dIdpQB0jkHgVJmLTv2oKa6 9U1dBvEjeOQcQUVXn8VML7MSnpH/07+qAm0pE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=cxc9nV+Z2sgYzsV59X6qc3b+amIQpySIDASFXUtwjlLdnarPGJ1criHNRexuy46B+b YbXwgsdxUtNVrypsDQciqm7c1AqJYtETgrlnLIbLDpUCoQr+AGXQDWSbwrSb53GC2qQu +5KEOjgGF7zWkct4oXxXgIp2fOpGeqFrZ1Wd4= MIME-Version: 1.0 Received: by 10.236.192.201 with SMTP id i49mr2123182yhn.525.1307686426570; Thu, 09 Jun 2011 23:13:46 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.42.200 with HTTP; Thu, 9 Jun 2011 23:13:46 -0700 (PDT) Date: Fri, 10 Jun 2011 02:13:46 -0400 X-Google-Sender-Auth: 8N0VB5pJC2jDpq7EWfGkWw6rNg4 Message-ID: From: Barry Leiba To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-v6ops-6to4-advisory.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] secdir review of draft-ietf-v6ops-6to4-advisory-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 06:13:48 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is an informational document that gives an overview of the "6to4" tunneling mechanism, along with extensive operational advice for it. The document is well written and clear, and the Security Considerations section seems correct and adequate. I see no issues with this document. Barry From kent@bbn.com Sun Jun 12 17:03:21 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D3111E813A for ; Sun, 12 Jun 2011 17:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKnw61DIxYkp for ; Sun, 12 Jun 2011 17:03:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1160011E807C for ; Sun, 12 Jun 2011 17:03:20 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37491 helo=[198.18.54.182]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QVuch-000K5B-Of; Sun, 12 Jun 2011 20:03:20 -0400 Mime-Version: 1.0 Message-Id: Date: Sun, 12 Jun 2011 19:20:22 -0400 To: secdir@ietf.org From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-904199097==_ma============" Cc: swallow@cisco.com, loa@pi.nu, rcallon@juniper.net, danfrost@cisco.com, stbryant@cisco.com Subject: [secdir] review of draft-ietf-mpls-loss-delay-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 00:03:22 -0000 --============_-904199097==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The abstract for draft-ietf-mpls-tp-loss-delay-profile-03 describes it as "a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices [sic] to meet the specific requirements of MLS-TP." It is a very brief (5 pages, including boilerplate) document intended as an informational RFC. The document that forms the basis for this profile, draft-ietf-mpls-loss-delay-01, is also in progress. The security considerations section of this document refers to the base document cited above. Since this document is a profile of that one, this is a reasonable indirection. (I note that the document under review cites version 1 of that base document, and that version 2 is now current, something that can be addressed later.) I looked at the security considerations section of the base specification. It is two paragraph in length. The first paragraph does a reasonable job of describing the top level security concerns associated with the exchange of performance monitoring messages in a context such as this. (The text would be better if the third concern were identified as "confidentiality.") The second paragraph, however, states: If reception or alteration of performance-related data by unauthorized devices is an operational concern, authentication and/or encryption procedures should be used to ensure message integrity and confidentiality. Such procedures are outside the scope of this document, but have general applicability to OAM protocols in MPLS networks. First, this paragraph is poorly worded (e.g., the mixed uses of "authentication," "encryption," "integrity," and "confidentiality"). Second, there is concrete reference to any candidate security mechanisms that can provide such services. I am not aware of any IETF standards that might offer such services for MPLS traffic. If there are none, this second paragraph is not adequate; if there are, they should be cited here. --============_-904199097==_ma============ Content-Type: text/html; charset="us-ascii" review of draft-ietf-mpls-loss-delay-03
I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

The abstract for draft-ietf-mpls-tp-loss-delay-profile-03 describes it as "a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices [sic] to meet the specific requirements of MLS-TP." It is a very brief (5 pages, including boilerplate) document intended as an informational RFC. The document that forms the basis for this profile, draft-ietf-mpls-loss-delay-01, is also in progress.

The security considerations section of this document refers to the base document cited above. Since this document is a profile of that one, this is a reasonable indirection. (I note that the document under review cites version 1 of that base document, and that version 2 is now current, something that can be addressed later.) I looked at the security considerations section of the base specification. It is two paragraph in length. The first paragraph does a reasonable job of describing the top level security concerns associated with the exchange of performance monitoring messages in a context such as this. (The text would be better if the third concern were identified as "confidentiality.") The second paragraph, however, states:

   If reception or alteration of performance-related data by
   unauthorized devices is an operational concern, authentication
   and/or encryption procedures should be used to ensure message
   integrity and confidentiality.  Such procedures are outside the
   scope of this document, but have general applicability to OAM
   protocols in MPLS networks.

First, this paragraph is poorly worded (e.g., the mixed uses of "authentication," "encryption," "integrity," and "confidentiality"). Second, there is concrete reference to any candidate security mechanisms that can provide such services. I am not aware of any IETF standards that might offer such services for MPLS traffic. If there are none, this second paragraph is not adequate; if there are, they should be cited here.
--============_-904199097==_ma============-- From danfrost@cisco.com Mon Jun 13 03:15:30 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D164911E80B0 for ; Mon, 13 Jun 2011 03:15:30 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bUMr022TA-c for ; Mon, 13 Jun 2011 03:15:29 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by ietfa.amsl.com (Postfix) with ESMTP id C091311E808B for ; Mon, 13 Jun 2011 03:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=danfrost@cisco.com; l=2836; q=dns/txt; s=iport; t=1307960129; x=1309169729; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=pswqAgheDmIG80h2UL6TJ7Go9Syc0GIvJdw8RRbirbQ=; b=l2e2xzCt72sqE/izsoVpXtnPi05KP2G/cL0HQKzz/iR2wHbrR3IVJDch 1n0rvbeDR0M8U68j0BJV12HHEIoiMMLWXGLwS1IdgD6TRhthPPovjlMJi jZcBv1Yr5TLpzv2sXowuAT5BFUjxaBdFWOxPsA6l3U5Ae54A0aQEKktNp o=; X-IronPort-AV: E=Sophos;i="4.65,357,1304294400"; d="scan'208";a="236620790" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-2.cisco.com with ESMTP; 13 Jun 2011 10:15:25 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [10.83.106.70]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p5DAFPZR011638; Mon, 13 Jun 2011 10:15:25 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id p5DAFOtQ026692; Mon, 13 Jun 2011 06:15:24 -0400 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id p5DAFOqR026691; Mon, 13 Jun 2011 11:15:24 +0100 Date: Mon, 13 Jun 2011 11:15:24 +0100 From: Dan Frost To: Stephen Kent Message-ID: <20110613101524.GA26345@cisco.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Mon, 13 Jun 2011 05:41:38 -0700 Cc: swallow@cisco.com, loa@pi.nu, rcallon@juniper.net, stbryant@cisco.com, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-mpls-loss-delay-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 10:15:31 -0000 Hi Stephen, Thanks for your review! However, it looks like you reviewed an out-of-date version of draft-ietf-mpls-loss-delay. The current version is -03 and this version includes a rewrite of the security considerations. (The reference pointers between the two drafts often don't show the latest versions of the targets so this may have caused some confusion.) Cheers, -d On Sun, Jun 12, 2011 at 07:20:22PM -0400, Stephen Kent wrote: > I reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should > treat these comments just like any other last call comments. > > The abstract for draft-ietf-mpls-tp-loss-delay-profile-03 describes > it as "a profile of the general MPLS loss, delay, and throughput > measurement techniques that suffices [sic] to meet the specific > requirements of MLS-TP." It is a very brief (5 pages, including > boilerplate) document intended as an informational RFC. The document > that forms the basis for this profile, > draft-ietf-mpls-loss-delay-01, is also in progress. > > The security considerations section of this document refers to the > base document cited above. Since this document is a profile of that > one, this is a reasonable indirection. (I note that the document > under review cites version 1 of that base document, and that version > 2 is now current, something that can be addressed later.) I looked > at the security considerations section of the base specification. It > is two paragraph in length. The first paragraph does a reasonable > job of describing the top level security concerns associated with > the exchange of performance monitoring messages in a context such as > this. (The text would be better if the third concern were identified > as "confidentiality.") The second paragraph, however, states: > > If reception or alteration of performance-related data by > unauthorized devices is an operational concern, authentication > and/or encryption procedures should be used to ensure message > integrity and confidentiality. Such procedures are outside the > scope of this document, but have general applicability to OAM > protocols in MPLS networks. > > First, this paragraph is poorly worded (e.g., the mixed uses of > "authentication," "encryption," "integrity," and "confidentiality"). > Second, there is concrete reference to any candidate security > mechanisms that can provide such services. I am not aware of any > IETF standards that might offer such services for MPLS traffic. If > there are none, this second paragraph is not adequate; if there are, > they should be cited here. From kent@bbn.com Tue Jun 14 11:07:33 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AA921F8503 for ; Tue, 14 Jun 2011 11:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOWe3p4+vngD for ; Tue, 14 Jun 2011 11:07:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 22C6621F84F9 for ; Tue, 14 Jun 2011 11:07:33 -0700 (PDT) Received: from dhcp89-089-178.bbn.com ([128.89.89.178]:49225) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QWY1U-0009Ll-4k; Tue, 14 Jun 2011 14:07:32 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110613101524.GA26345@cisco.com> References: <20110613101524.GA26345@cisco.com> Date: Tue, 14 Jun 2011 13:47:05 -0400 To: Dan Frost From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: swallow@cisco.com, loa@pi.nu, rcallon@juniper.net, stbryant@cisco.com, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-mpls-loss-delay-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 18:07:33 -0000 At 11:15 AM +0100 6/13/11, Dan Frost wrote: >Hi Stephen, > >Thanks for your review! However, it looks like you reviewed an >out-of-date version of draft-ietf-mpls-loss-delay. The current version >is -03 and this version includes a rewrite of the security >considerations. (The reference pointers between the two drafts often >don't show the latest versions of the targets so this may have caused >some confusion.) > >Cheers, >-d Dan, Thanks for pointing me to the most recent version of the base spec. As you noted, the profile reference didn't list a version number so ... In looking at the new version, I see that the intro text is much improved. It cites use of BFD as an authentication mechanism, and refers the reader to 5920, presumably for integrity and authentication mechanisms. I looked quickly at 5920, and it appears that it does not specify any crypto-based mechanisms for a generic pseudowire link (where the traffic being carried is not IP). Is that accurate? Also, 5920 cites 4447, for LDP-based links, but that RFC seems to cite only TCP-MD5 as a crypto-based option, which is now obsoleted by TCP-AO. So It is not clear that there are any IETF crypto-based security standards available for protecting these messages. I'm not saying that this is a show stopper, but rather that this should be more clearly stated somewhere. Finally, the cite of IPsec in the next text (in the base document) provides te sort of concrete, crypto-based security mechanism I had in mind when I raised this question. However, I have a question: are the loss and delay measurement messages sent via the MPLS G-ACh always encapsulated in IP? I could not determine this from looking at the base doc, and RFC 5586 seems to indicate that IP is only one option for carriage of MPLS OAM packets. Steve From charliek@microsoft.com Tue Jun 14 23:04:09 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F04F11E80D6; Tue, 14 Jun 2011 23:04:09 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WY6rqBCcb-9h; Tue, 14 Jun 2011 23:04:08 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 857F911E80A1; Tue, 14 Jun 2011 23:04:08 -0700 (PDT) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 14 Jun 2011 23:04:08 -0700 Received: from TK5EX14MBXC110.redmond.corp.microsoft.com ([169.254.1.209]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.01.0289.008; Tue, 14 Jun 2011 23:04:07 -0700 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-radext-crypto-agility-requirements.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-radext-crypto-agility-requirements-06 Thread-Index: AcwrEhaCu4VKSJ6LSL6yByy0oqg7zQ== Date: Wed, 15 Jun 2011 06:04:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-radext-crypto-agility-requirements-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 06:04:09 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG.=A0 These = comments were written primarily for the benefit of the security area direct= ors.=A0 Document editors and WG chairs should treat these comments just lik= e any other last call comments. This document was written based on a request/demand from the security area,= so it would seem only fair that we review it fairly carefully. RADIUS was = developed in simpler times and uses a na=EFve approach to encryption and au= thentication of messages. Among the least of its problems, it has a hard-wi= red dependency on MD5. Russ Housley - Security Area Director at the time - = asked the RADEXT WG to propose remediations to the protocol (perhaps as the= price of withdrawing a 'discuss' on some other work they were doing). This= was in 2006. This document does not propose remediations to RADIUS, but rather proposes = requirements that any such remediations must satisfy. I've always hated IET= F 'requirements' documents, because they tend to be a form of shadow boxing= where people have solutions in mind and are trying not to admit it as that= argue for requirements that would favor their solution when solutions are = judged against requirements. That makes it especially hard for people who a= re not deeply involved to understand the implications of what is being said= . I couldn't figure out what solutions people might have in mind motivating t= hese requirements. In fact, these requirements appeared to me to rule out a= ny possible solution. In particular, page 5 para 3 line 1 says "Proposals M= UST NOT introduce new capabilities negotiation features into the RADIUS pro= tocol and crypto-agility solutions SHOULD NOT require changes to the RADIUS= operational model.", where the model says that RADIUS is a stateless reque= st/response protocol. That makes most cryptographic algorithm negotiation p= rotocols impossible. Actually, crypto agility for RADIUS would be pretty trivial. RADIUS uses pa= ir-wise configured secret keys. Cryptographic algorithms could be associate= d with those keys, and therefore configured in the same manner as the keys.= You couldn't assign the new kinds of keys unless both ends understood the = new algorithms. Everything would work with no cryptographic negotiation at = all. The apparent reason that doesn't address the problem is that they are = trying to do much more than algorithm agility. They are also trying to impr= ove the protocol to include features like Perfect Forward Secrecy, Automate= d Key Management, and authentication using X.509 certificates. Some text in the document seems to imply that running the whole thing over = DTLS might be acceptable (because DTLS would be considered a transport so i= t's algorithm negotiation mechanisms would not be considered new capabiliti= es negotiation features in RADIUS). If that were acceptable, it would solve= all of their other problems, though it would add a lot of heft to implemen= tations on small devices. The bottom line is that they are working really hard to do the right thing,= but there is a danger they will be wasting their time unless someone from = the security community is working with them to find a reasonable solution t= hat works for both the RADIUS community and the security community. I have = my doubts as to whether this document brings them closer to a solution, but= it is certainly an opportunity for someone to volunteer to step up. --Charlie p.s. One protocol nit to worry about. In section 4.3, paragraph 4, the spec= suggests to one way to mitigate downgrade attacks is for initiators to rem= ember that responders once accepted the newer (stronger) protocol, and on t= hat basis refuse to accept the older (weaker) protocol in subsequent negoti= ations. While it sounds logical, it can lead to deployment problems where s= omeone rolls out a newer responder but then finds due to some problem that = they must back it out. For that case, there must be some (likely out of ban= d) way to tell the initiator to go back to accepting the old protocol. From new-work-bounces@ietf.org Tue Jun 14 09:20:26 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2D21F0C54; Tue, 14 Jun 2011 09:20:26 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id B9FE31F0C4F; Tue, 14 Jun 2011 09:20:24 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110614162024.B9FE31F0C4F@ietfa.amsl.com> Date: Tue, 14 Jun 2011 09:20:24 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 15 Jun 2011 08:04:40 -0700 Subject: [secdir] [new-work] WG Review: Content Delivery Networks Interconnection (cdni) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 16:20:26 -0000 A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 21, 2011. Content Delivery Networks Interconnection (cdni) ------------------------------------------------ Current Status: Proposed Working Group Last updated: 2011-05-27 Chairs: TBD Transport Area Directors: Wesley Eddy David Harrington Transport Area Advisor: David Harrington Mailing lists: Address: cdni@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cdni Archive: http://www.ietf.org/mail-archive/web/cdni/ Description of Working Group: A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs). CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure and many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a need for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure. The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (via their respective User Agents). The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe (18-24 months) as needed by the industry. It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter. The working group will focus on the following items: - A "problem statement" document providing a description of the problem and a common terminology. - A "use case" document describing scenarios for usage and applications of the CDNI solution and protocols. - A "framework" document providing a description of the different components of the CDNI architecture and how they interact with one another. This document will also include a "threat analysis" discussing the security concerns and threats, the trust model and privacy issues specific to CDNI. - A "requirements" document. This document lists the requirements for the CDNI architecture and the CDNI interfaces. In particular, this document will focus on identifying a reasonable set of more urgent and important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group. This document will list the requirements stemming from the threat analysis and to be met by each of the CDNI interfaces. - A specification of the "CDNI request-routing interface". This interface will allow an upstream CDN request routing system to obtain from the downstream CDN the information necessary to perform request redirection. - A specification of the "CDNI metadata interface". This interface will allow the CDNs to exchange content distribution metadata of inter-CDN scope. Content distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore is to be processed by CDNs (for example, this may include information enabling: content acquisition, geo-blocking, enforcement of availability windows or access control). - A specification of the "CDNI logging interface". This interface will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc. - A specification of the "CDNI control interface". In particular, this interface will allow an upstream CDN to remove or invalidate content in a downstream CDN. The WG will discuss and address the security, management and operational issues specific to CDNI, inside the above documents and specifications. The working group will only define solutions for aspects of the CDN Interconnection problem space that require direct communication or interoperation between CDNs. In particular, the WG will not define: - New session, transport or network protocols. - New protocols for delivering content from a CDN to an End User/User Agent. - New protocols for ingestion of content or metadata between a CSP and a CDN. - New protocols for acquiring content across CDNs. - Protocols and algorithms for intra-CDN operations. - Support for Transparent Caching across CDNs. - New applications consuming CDNI logs. - Digital Right Management (DRM) mechanisms. The CDNI WG will work with other IETF WGs to assess, and where appropriate, leverage protocols developed by those WGs, in order to realize the CDNI requirements and CDNI interfaces. For example, the WG may assess the suitability of the ALTO protocol as a protocol to enable downstream CDNs to exchange information which may aid an upstream CDN with making CDNI request routing decisions. The CDNI WG will also coordinate with relevant groups outside the IETF such as UltraViolet. Goals and Milestones WG Creation + 6 months: Submit CDNI problem statement to IESG as Informational WG Creation + 9 months: Submit CDNI use cases to IESG as Informational WG Creation + 12 months: Submit CDNI framework to IESG as Informational WG Creation + 12 months: Submit CDNI requirements to IESG as Informational WG Creation + 18 months: Submit specification of the CDNI Request Routing interface to IESG as Proposed Standard WG Creation + 18 months: Submit specification of the CDNI Logging interface to IESG as Proposed Standard WG Creation + 18 months: Submit specification of the CDNI Control interface to IESG as proposed Standard WG Creation + 24 months: Submit specification of the CDNI Metadata Distribution interface to IESG as Proposed Standard WG Creation + 24 months: Recharter or dissolve _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From kanno.satoru@po.ntts.co.jp Wed Jun 15 06:01:27 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A57A11E810E; Wed, 15 Jun 2011 06:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fegnEiZp4fst; Wed, 15 Jun 2011 06:01:26 -0700 (PDT) Received: from mail12.ics.ntts.co.jp (mail12.ics.ntts.co.jp [210.232.35.65]) by ietfa.amsl.com (Postfix) with ESMTP id A613611E80F0; Wed, 15 Jun 2011 06:01:17 -0700 (PDT) Received: from sadoku33.silk.ntts.co.jp (sadoku33 [10.7.18.33]) by mail12.ics.ntts.co.jp (8.14.4/8.13.4/NTTSOFT) with ESMTP id p5FD18PO028041; Wed, 15 Jun 2011 22:01:08 +0900 (JST) Received: (from root@localhost) by sadoku33.silk.ntts.co.jp (8.13.8/NTTSOFT) id p5FD183m017038; Wed, 15 Jun 2011 22:01:08 +0900 (JST) Received: from ccmds32.silk.ntts.co.jp [10.107.0.32] by sadoku33.silk.ntts.co.jp with SMTP id YAA17037; Wed, 15 Jun 2011 22:01:08 +0900 Received: from mail136.silk.ntts.co.jp (ccmds32.silk.ntts.co.jp [127.0.0.1]) by ccmds32.silk.ntts.co.jp (8.14.3/8.14.3) with ESMTP id p5FD17Nm021847; Wed, 15 Jun 2011 22:01:07 +0900 Received: from mail136.silk.ntts.co.jp (localhost [127.0.0.1]) by mail136.silk.ntts.co.jp (8.14.4/NTTSOFT) with ESMTP id p5FD17Li025093; Wed, 15 Jun 2011 22:01:07 +0900 (JST) Received: from ccmds32 (ccmds32.silk.ntts.co.jp [10.107.0.32]) by mail136.silk.ntts.co.jp (8.14.4/NTTSOFT) with SMTP id p5FD17Fh025090; Wed, 15 Jun 2011 22:01:07 +0900 (JST) Message-ID: <4DF8AD07.3060205@po.ntts.co.jp> Date: Wed, 15 Jun 2011 22:00:55 +0900 From: Satoru Kanno User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Sandra Murphy References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: CC-Mail-V4.3-Client X-CC-Mail-RelayStamp: CC-Mail-V4.3-Server X-Mailman-Approved-At: Wed, 15 Jun 2011 08:04:40 -0700 Cc: draft-kanno-tls-camellia@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-kanno-tls-camellia X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:01:27 -0000 Hi Sandra, Thank you for your comments. And I'm sorry for delayed response. Because I was missing your email. At First, this draft is almost same document structure on RFC6209 (i.e., ARIA for TLS). We reconsidered and revised three parts (3.2 Cipher, 3.4 PSK cipher suites, and 4. Security Considerations). The details are follows; o 3.2 Cipher I wrote additional information to supplement in this section. Because this section is not clear on kinds of modes, I wrote additional paragraph as follows; ======================================================================= This document describes cipher suites based on Camellia cipher using CBC mode and GCM. The details are follows; ======================================================================= o 3.4 PSK cipher suites I mainly reviewed references and mapping between RFC and cipher suite. For references, I removed RFC4279 (only cipher suites based on SHA-1) and RFC4785 (only NULL encryption) from this section, because we did not define these cipher suites in our draft. For mapping between RFC and cipher suite I wrote additional information to supplement for RFCs. ======================================================================= PSK cipher suites for TLS are described in RFC5487 [11] as to SHA- 256/384 and RFC5489 [12] as to ECDHE_PSK. ======================================================================= o 4. Security Considerations I reviewed and reconsidered on references of section. I removed RFC4279 (including RFC5487), RFC4785 (not defined in NULL encryption), RFC5288 (including RFC5487), and GCM (including RFC5116) from this section. ======================================================================= The security considerations in previous RFCs (RFC5116 [7], RFC5289 [10], and RFC5487 [11]) apply to this document as well. ======================================================================= I updated next draft (-03) including some editorial corrections. Please check this draft. https://datatracker.ietf.org/doc/draft-kanno-tls-camellia/ Regards, Satoru (2011/04/13 1:42), Sandra Murphy wrote: > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > > This document adds new cipher suites to TLS that include the use of the > Camilla algorithm. > > The document follows the format of other documents that have defined > cipher suites to TLS. In most cases the text just points to those other > documents. > > It is entirely possible that with sufficient time to study the 9 or 10 > references that point to the definition of other cipher suites being > cited as models for these cipher suites, I'd be able to view the > document as obvious. Unfortunately I had neither the experience nor the > time for sufficient study. So I found the text not clear about what > other cipher suites were being invoked as models for the suites here. > > The security consideration section points to the sections in seven other > similar documents. I have not been able to review that list of security > considerations sections to see that they adequately cover the concers > for this algorithm. But as this document is not proposing any novel new > combinations of security features and (according to the document, not > me) Camilla is very similar to AES, I presume that security > considerations are adequately covered. I know of no security concerns > specific to Camilla. > > The language in section 3 (cipher suite definitions) makes frequent > mention of the way similar suites are defined elsewhere. As a person who > is not au courant on cipher suites, I did not find the language obvious. > > Advanced Encryption Standard (AES) [20] authenticated encryption with > additional data algorithms, AEAD_AES_128_GCM and AEAD_AES_256_GCM are > described in RFC5116 [8]. And AES GCM cipher suites for TLS are > described in RFC5288 [10]. AES and Camellia share common > characteristics including key sizes and block length. > CAMELLIA_128_GCM and CAMELLIA_256_GCM are defined according as those > of AES. > > I believe that the authors mean that the definitions of the Cammilla > suites are the same as in section 5.1 and 5.2 of 5116 and section 3 of > 5288, with appropriate substitution of "Camilla" for "AES", but I am not > sure which of the cipher suites in 2.1, 2.2 and 2.3 of this document are > included. Particularly as the PSK suites listed in 2.3 would seem to be > described in section 3.4 with reference to entirely other documents. > Perhaps someone more experienced with cipher suites would think this was > obvious, but I could have used a more explicit mapping between the > suites defined here and the suites from which the descriptions are being > borrowed. > > Section 3.4 is particularly opaque to my inexperienced eyes as to the > mapping between these cipher suites and the similar cipher suites whose > descriptiosn are being borrowed: > > PSK cipher suites for TLS are described in RFC4279 [5], RFC4785 [7], > RFC5487 [12], and RFC5489 [13]. > > That is the complete description of the suites. > > Which ref applies to which suite in this document? > > --Sandy > > -- Satoru Kanno Security Business Unit Mobile and Security Solution Business Group NTT Software Corporation TEL: +81 45 212 9803 FAX: +81 45 212 9800 e-mail: kanno.satoru@po.ntts.co.jp From danfrost@cisco.com Thu Jun 16 02:47:02 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7508511E8102 for ; Thu, 16 Jun 2011 02:47:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm9RKDIbWhnu for ; Thu, 16 Jun 2011 02:47:01 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id CAAEB11E80F4 for ; Thu, 16 Jun 2011 02:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=danfrost@cisco.com; l=2507; q=dns/txt; s=iport; t=1308217621; x=1309427221; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=+KYs5Wq+nF/EyNakAlzOj18sEk2A0bwpHMmjyTQMRlE=; b=ApWZH7wJETlHrw+yZu8wxReJGJOAo33GzHm+hMl1/DSR1PSHxg1+Wn8n aNBKBU/mAsP3cUtAVKMcJUtqjjKRYnGg7W98ivfU/b/aWJPkn2ZqjlnSh HQAW6AVuzSqJRIlvGZUVy3defcu1F58Ti7ABAakl81XmgFa119pKYrFUE E=; X-IronPort-AV: E=Sophos;i="4.65,374,1304294400"; d="scan'208";a="377793073" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-2.cisco.com with ESMTP; 16 Jun 2011 09:46:40 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [10.83.106.70]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5G9keFl030974; Thu, 16 Jun 2011 09:46:40 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id p5G9kdvr013747; Thu, 16 Jun 2011 05:46:39 -0400 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id p5G9kdwO013746; Thu, 16 Jun 2011 10:46:39 +0100 Date: Thu, 16 Jun 2011 10:46:39 +0100 From: Dan Frost To: Stephen Kent Message-ID: <20110616094639.GB12211@cisco.com> References: <20110613101524.GA26345@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Thu, 16 Jun 2011 03:48:03 -0700 Cc: swallow@cisco.com, loa@pi.nu, rcallon@juniper.net, stbryant@cisco.com, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-mpls-loss-delay-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 09:47:02 -0000 Hi Steve, On Tue, Jun 14, 2011 at 01:47:05PM -0400, Stephen Kent wrote: > Thanks for pointing me to the most recent version of the base spec. As > you noted, the profile reference didn't list a version number so ... > > In looking at the new version, I see that the intro text is much > improved. It cites use of BFD as an authentication mechanism, and > refers the reader to 5920, presumably for integrity and authentication > mechanisms. > > I looked quickly at 5920, and it appears that it does not specify any > crypto-based mechanisms for a generic pseudowire link (where the > traffic being carried is not IP). Is that accurate? Also, 5920 cites > 4447, for LDP-based links, but that RFC seems to cite only TCP-MD5 as > a crypto-based option, which is now obsoleted by TCP-AO. So It is not > clear that there are any IETF crypto-based security standards > available for protecting these messages. I'm not saying that this is a > show stopper, but rather that this should be more clearly stated > somewhere. Yes, that's true; the MPLS data plane is generally implemented and highly optimized in hardware, so heavyweight security mechanisms like encryption are left to other layers. Similarly trying to encrypt these hardware-assisted loss/delay measurement messages is likely to cause more problems than it solves; the information they contain is unlikely to be sensitive enough to justify a complex and costly encryption layer (which would at best require very specialized hardware support in order not to interfere with the measurements themselves). We can add a note about this in the text if that will help. > Finally, the cite of IPsec in the next text (in the base document) > provides te sort of concrete, crypto-based security mechanism I had in > mind when I raised this question. However, I have a question: are the > loss and delay measurement messages sent via the MPLS G-ACh always > encapsulated in IP? I could not determine this from looking at the > base doc, and RFC 5586 seems to indicate that IP is only one option > for carriage of MPLS OAM packets. Right, the G-ACh is independent of IP and was designed, among other things, to meet requirements for MPLS-TP (RFC 5654) that include being able to function in networks that lack an IP data plane. The reference to IPsec in this document pertains to the special case of out-of-band measurement message responses over IP networks. Thanks again for the review! -d > Steve From kent@bbn.com Thu Jun 16 06:54:00 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2A911E8106 for ; Thu, 16 Jun 2011 06:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CFDQnvLVv-u for ; Thu, 16 Jun 2011 06:54:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2C48111E80E3 for ; Thu, 16 Jun 2011 06:54:00 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:47675 helo=[192.168.1.10]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QXD1C-00070d-4a; Thu, 16 Jun 2011 09:53:58 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110616094639.GB12211@cisco.com> References: <20110613101524.GA26345@cisco.com> <20110616094639.GB12211@cisco.com> Date: Thu, 16 Jun 2011 09:52:58 -0400 To: Dan Frost From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: swallow@cisco.com, secdir@ietf.org, rcallon@juniper.net, stbryant@cisco.com, loa@pi.nu Subject: Re: [secdir] review of draft-ietf-mpls-loss-delay-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 13:54:00 -0000 At 10:46 AM +0100 6/16/11, Dan Frost wrote: >Hi Steve, >... > >Yes, that's true; the MPLS data plane is generally implemented and >highly optimized in hardware, so heavyweight security mechanisms like >encryption are left to other layers. Similarly trying to encrypt these >hardware-assisted loss/delay measurement messages is likely to cause >more problems than it solves; the information they contain is unlikely >to be sensitive enough to justify a complex and costly encryption layer >(which would at best require very specialized hardware support in order >not to interfere with the measurements themselves). If you are looking to provide integrity and authentication, then you would not be performing encryption, per se, although use of cryptographic mechanisms was the question I was asking. >We can add a note about this in the text if that will help. If there is a way to use crypto to protect payloads, then saying how to do that would be fine. If not, then it should be stated clearly. It took a lot of digging to discover that, for the measurement messages, there appears to be no crypto option :-). > >> Finally, the cite of IPsec in the next text (in the base document) >> provides te sort of concrete, crypto-based security mechanism I had in >> mind when I raised this question. However, I have a question: are the >> loss and delay measurement messages sent via the MPLS G-ACh always >> encapsulated in IP? I could not determine this from looking at the >> base doc, and RFC 5586 seems to indicate that IP is only one option >> for carriage of MPLS OAM packets. > >Right, the G-ACh is independent of IP and was designed, among other >things, to meet requirements for MPLS-TP (RFC 5654) that include being >able to function in networks that lack an IP data plane. The reference >to IPsec in this document pertains to the special case of out-of-band >measurement message responses over IP networks. Thanks for the clarification. Steve From weiler+secdir@watson.org Fri Jun 17 09:33:34 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE75D11E807F for ; Fri, 17 Jun 2011 09:33:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5Sc9WbKDJrq for ; Fri, 17 Jun 2011 09:33:34 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id F3C2B21F8445 for ; Fri, 17 Jun 2011 09:33:33 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p5HGXXsV011496 for ; Fri, 17 Jun 2011 12:33:33 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p5HGXX4T011493 for ; Fri, 17 Jun 2011 12:33:33 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 17 Jun 2011 12:33:32 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 17 Jun 2011 12:33:33 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 16:33:35 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Carl Wallace is next in the rotation. For telechat 2011-06-23 Reviewer LC end Draft Richard Barnes T 2011-06-09 draft-ietf-dnsext-dnssec-registry-fixes-08 Alan DeKok TR2011-06-22 draft-ohba-pana-relay-03 Tobias Gondrom T 2011-06-03 draft-ietf-dime-ikev2-psk-diameter-08 Scott Kelly T 2011-06-15 draft-ietf-opsawg-mib-floats-02 Tero Kivinen T 2011-06-15 draft-ietf-mpls-tp-loss-delay-profile-03 Alexey Melnikov T 2011-06-22 draft-ietf-dhc-subnet-alloc-12 Hilarie Orman T 2011-06-21 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-00 Vincent Roca T - draft-ietf-mboned-ssmping-08 Juergen Schoenwaelder T 2011-05-18 draft-ietf-sidr-keyroll-07 Tina TSOU T 2011-06-20 draft-ietf-v6ops-6to4-to-historic-04 Nico Williams T 2011-05-26 draft-ietf-dkim-mailinglists-11 For telechat 2011-06-30 Reviewer LC end Draft Catherine Meadows T 2011-06-30 draft-ietf-appsawg-rfc3536bis-02 Kathleen Moriarty T 2011-06-30 draft-ietf-ftpext2-hosts-02 For telechat 2011-07-14 Reviewer LC end Draft Chris Lonvick T 2011-07-14 draft-gellens-mime-bucket-bis-05 David McGrew T 2011-07-08 draft-iesg-rfc1150bis-01 Eric Rescorla T 2011-06-29 draft-ietf-dkim-rfc4871bis-12 Yaron Sheffer T 2011-05-18 draft-ietf-sidr-repos-struct-08 Last calls and special requests: Reviewer LC end Draft Shawn Emery 2011-06-06 draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-01 Phillip Hallam-Baker 2011-06-14 draft-ietf-dime-local-keytran-11 Jeffrey Hutzelman 2011-06-14 draft-ietf-soc-overload-design-06 Julien Laganier 2011-06-15 draft-ietf-ipfix-configuration-model-09 Matt Lepinski 2011-07-13 draft-burgin-ipsec-suiteb-profile-00 Catherine Meadows R2011-04-13 draft-ietf-speechsc-mrcpv2-24 Russ Mundy 2011-06-30 draft-ietf-karp-design-guide-02 Sandy Murphy 2011-06-22 draft-ietf-payload-rfc3016bis-01 Magnus Nystrom 2011-07-13 draft-polk-local-emergency-rph-namespace-01 Radia Perlman 2011-07-13 draft-law-rfc4869bis-01 Tim Polk 2011-05-11 draft-ietf-vrrp-unified-mib-09 Tim Polk 2011-06-30 draft-ietf-codec-requirements-04 Joe Salowey 2011-05-30 draft-ietf-mpls-lsp-ping-enhanced-dsmap-09 Stefan Santesson 2011-06-27 draft-ietf-pim-mtid-08 Ondrej Sury 2011-06-30 draft-ietf-sidr-rescerts-provisioning-10 Tina TSOU 2011-04-23 draft-shin-augmented-pake-06 Carl Wallace 2011-05-30 draft-ietf-mpls-p2mp-lsp-ping-16 Glen Zorn 2011-06-28 draft-li-pwe3-ms-pw-pon-03 From j.schoenwaelder@jacobs-university.de Sat Jun 18 11:38:23 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A6111E810B; Sat, 18 Jun 2011 11:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.181 X-Spam-Level: X-Spam-Status: No, score=-103.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hDDa0MDEHH6; Sat, 18 Jun 2011 11:38:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0B30111E8084; Sat, 18 Jun 2011 11:38:23 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23D4A20BF3; Sat, 18 Jun 2011 20:38:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dJq+6jI-q82j; Sat, 18 Jun 2011 20:38:20 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 93C5020BEF; Sat, 18 Jun 2011 20:38:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 260FD191E9BE; Sat, 18 Jun 2011 20:38:20 +0200 (CEST) Date: Sat, 18 Jun 2011 20:38:20 +0200 From: Juergen Schoenwaelder To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sidr-keyroll.all@tools.ietf.org Message-ID: <20110618183820.GA49110@elstar.local> Mail-Followup-To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sidr-keyroll.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [secdir] secdir review of draft-ietf-sidr-keyroll-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 18:38:23 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This I-D details how a CA should perform a planned key rollover in the Resource Public Key Infrastructure. As such, the content of the whole I-D is security related. The discussion of key lifetimes in the Security Considerations section seems appropriate. I could not find any issues with this document. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From radiaperlman@gmail.com Sun Jun 19 21:36:37 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FD621F8504; Sun, 19 Jun 2011 21:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxn+IXba2ulV; Sun, 19 Jun 2011 21:36:37 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C91FA21F8503; Sun, 19 Jun 2011 21:36:36 -0700 (PDT) Received: by ewy19 with SMTP id 19so912677ewy.31 for ; Sun, 19 Jun 2011 21:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=E/dG3auM+u7y3X7Rkx9PojXSuVNYx4ICWujdQB1X8w8=; b=SsUc8Ab7jW3PsCeoqE63XR0S2a4K22KEZKRHV4lYDUWxwaHZmiIKrX5lgy9N8EGgLM o/Bb4rT3Qiyon3VJ6lhaO4feERyxSWrob4nSPYbnqWgngK+CIwPTdqYuSlUSBfFDOkFw DTQexUGPkBfUi/Qc/6vHfVz6gWas7I8Yc0cZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=BFeT3ucNuTRwimMOuGbXSWqduXIjmnOnUf8w8Pxl0WsnvferB/ITjpCc1RXA5d4O5i AtVe/vDtjDCrxb6oKzUv+hEoxP/L4k35tJTJDal4cP3N6jPgq2KfxHDXINT613VCZfXR nZbcgktU8ihG/6aQsbuT6+ZqUxIr+dwLHitR0= MIME-Version: 1.0 Received: by 10.14.9.228 with SMTP id 76mr1344613eet.206.1308544595593; Sun, 19 Jun 2011 21:36:35 -0700 (PDT) Received: by 10.14.29.10 with HTTP; Sun, 19 Jun 2011 21:36:35 -0700 (PDT) Date: Sun, 19 Jun 2011 21:36:35 -0700 Message-ID: From: Radia Perlman To: iesg@ietf.org, secdir@ietf.org, draft-law-rfc4869bis.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] secdir review of draft-law-rfc4869bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 04:36:37 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: No problems with this document. This document updates (and obsoletes) RFC 4869, and specifies four US suites for IPsec, compatible with NSA Suite B specifications. Radia From rbarnes@bbn.com Mon Jun 20 08:20:08 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53B421F85F0; Mon, 20 Jun 2011 08:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.274 X-Spam-Level: X-Spam-Status: No, score=-106.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nh9bSqzITolO; Mon, 20 Jun 2011 08:20:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC2521F85EE; Mon, 20 Jun 2011 08:20:07 -0700 (PDT) Received: from [128.89.253.103] (port=58697 helo=[172.27.17.202]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QYgGf-000AdT-Ht; Mon, 20 Jun 2011 11:20:01 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2011 11:19:54 -0400 Message-Id: To: secdir@ietf.org, The IESG , draft-ietf-dnsext-dnssec-registry-fixes@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [secdir] secdir review of draft-ietf-dnsext-dnssec-registry-fixes-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:20:09 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes some minor fixes to the DNSSEC registry of = cryptographic algorithms. I have some minor questions / nits below, but = overall the document seems in fine shape. --Richard 1. Why is there a date on the reserved numbers, rather than simply = setting the status to "reserved"? Is there a desire to provide some = guarantee to implementors? 2. "Registry entries 13-251 remains Unassigned" -> "Registry entries = 13-251 remain Unassigned" 3. It might be helpful to say explicitly that the table in the IANA = Considerations replaces the current registry. From hilarie@purplestreak.com Mon Jun 20 12:14:21 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6A911E81E2; Mon, 20 Jun 2011 12:14:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfRfZag7sU-Q; Mon, 20 Jun 2011 12:14:15 -0700 (PDT) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by ietfa.amsl.com (Postfix) with ESMTP id 8F46711E80FC; Mon, 20 Jun 2011 12:14:15 -0700 (PDT) Received: from mx03.mta.xmission.com ([166.70.13.213]) by out02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QYjvG-0005wx-Qk; Mon, 20 Jun 2011 13:14:11 -0600 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=sylvester.rhmr.com) by mx03.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QYjvE-0004yd-Uf; Mon, 20 Jun 2011 13:14:10 -0600 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.3/Debian-9.1ubuntu1) with ESMTP id p5KJDrkI018020; Mon, 20 Jun 2011 13:13:54 -0600 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id p5KJDpAW018018; Mon, 20 Jun 2011 13:13:51 -0600 Date: Mon, 20 Jun 2011 13:13:51 -0600 Message-Id: <201106201913.p5KJDpAW018018@sylvester.rhmr.com> From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx03.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=error X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600) X-SA-Exim-Scanned: Yes (on mx03.mta.xmission.com) Cc: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat@ietf.org Subject: [secdir] Security review of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 19:14:21 -0000 Security review of IPv6 Multihoming without Network Address Translation draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-00 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. >From the abstract: In this document, we analyze the use cases of multihoming. We also describe functional requirements for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6 allocation criteria. The underlying problem is that if a host has more than one one network provider and has been assigned different IPv6 addresses for each provider, then it becomes important to construct packets using the right combination of {source address, destination address based on a lookup to an appropriate DNS server, next-hop address}. What is the right combination, though? The answer depends on the properties of the different networks, and in general, hosts or gateway routers in small networks may not have enough information to make a good choice. The authors propose a solution based on policy information, to be distributed by network administrators to network elements that are multihomed. The policy would list destination network prefixes and the appropriate triples to use for each. The security considerations are brief, simply noting that a policy might be "evil" or the participants might ignore the policy. I think it is more complicated (of course). There is a fundamental question of who should be trusted to distribute policy. How is the trust established, and how can the network element be assured that it can established that trust before the network is fully configured? This might be quite difficult, because there could be more than one policy distributor, each with a slightly different view of the network (imagine P1 that can see external networks A and B, and P2 that can see networks B and C). It seems inevitable that a host will have to be able to merge policies and deal with updates. Further, a host might have its own policies to merge into the mix. For example, it might require a DNSSEC capable server for queries about network A, but the policy might specify a non-DNSSEC server for that network. Thus, I can see a need for hosts to communicate their security requirements to the policy server. There are issues about the privacy of the policy itself. Perhaps particular network prefixes reveal business relationships that are confidential. Thus, some policy information might be sent on encrypted channels. What kind of policy enforcement is necessary? If a host violates the multihoming policy and sends a packet with a source address that is appropriate to network A over the path to network B, should the packet be blocked, redirected, or allowed? What about DNS queries that are sent to a server that is not recommended for the target? Quash, redirect, or allow? What information should go back to the host? I think that most of these comments apply to any policy server, and I believe that various IETF documents in the past have attempted to define generic security considerations for them. Trivial editorial comments: "uRPF" is used three times without a definition. "RA" is used before it is defined. Typo: 7.2. Co-exisitence consideration From alexey.melnikov@isode.com Mon Jun 20 14:38:49 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481AF11E8207; Mon, 20 Jun 2011 14:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggXvugGTd7qN; Mon, 20 Jun 2011 14:38:48 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 604AD11E80C5; Mon, 20 Jun 2011 14:38:48 -0700 (PDT) Received: from [188.28.254.65] (188.28.254.65.threembb.co.uk [188.28.254.65]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 20 Jun 2011 22:38:46 +0100 Message-ID: <4DFFBD93.3090709@isode.com> Date: Mon, 20 Jun 2011 22:37:23 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dhc-subnet-alloc.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-dhc-subnet-alloc-12.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 21:38:49 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This I-D details a new DHCP option to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report allocation usage statistics. The Security reference points to RFC 2131 and RFC 3118. I think this adequately describes denial of service due to a rogue delegating router advertising bogus prefixes, as well as denial of service due to a malicious DHCP client masquerade as a legitimate client and claiming all resources to itself. RFC 3118 says that it can be used in combination with this option to provide some level of mutual DHCP server and client authentication and thus addresses threats mentioned above, although it has its limitations. (However I am not a DHCP expert and haven't studied RFC 3118 in details.) I can't think of any other threats not described in the Security Considerations section. Other issues I found in the document: Major: 3.3. Subnet-Name Suboption format The Subnet-Name suboption may be used in order to pass a subnet name to the server for use during allocation. This name may be used for any purpose but is intended to tell the server something extra about the needed subnet; for example, "sales department", "customer 1002", "address pool FOO", or some such. The "name" should NOT be NULL terminated since the "len" field already specifies the length of the name. The "Name" in this suboption is simply a number of octets and need not be ASCII text. The last sentence: if it doesn't need to be ASCII you need to specify whether it is a textual string or a binary string. In the former case you also need to specify which character set is used in this field. Ideally it should be UTF-8 [RFC3629]. Minor: It would be good to describe upfront that this option is only specified for IPv4 and not for IPv6. 3.2. Subnet-Information Suboption format 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | 2 | Len | Flags :c:s| SP1, SP2, ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Len = Length of the sub-option (min. length of 8) (1 octet) Flags = Various flags which apply to ALL Subnet Prefix Information fields specified in this suboption. Unused flags must be zero. Are unused flags ignored by a recipient if non zero? (Similar question regarding Section 3.1) 3.2.1. Subnet Prefix Information block format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | Flags |h|d| Stat-len | Optional stats... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Addr = IPv4 network number (4 octets) Did you mean "Network"? There is no "Addr" in the table above. 3.2.1.1. Subnet Usage Statistics Fewer fields may be included than what is specified in any current RFC, but all fields which are included MUST remain in order specifed here. Can you elaborate on what this mean? Does it mean only including 1 or 2 of the specified fields? From tena@huawei.com Mon Jun 20 14:43:03 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9625B11E80C5; Mon, 20 Jun 2011 14:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upUYEdgl4Wa9; Mon, 20 Jun 2011 14:43:02 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id D3D6611E808E; Mon, 20 Jun 2011 14:43:02 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN300BMIYZPUA@usaga04-in.huawei.com>; Mon, 20 Jun 2011 16:43:01 -0500 (CDT) Received: from TingZousc1 ([10.193.34.147]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN300LG1YZOEC@usaga04-in.huawei.com>; Mon, 20 Jun 2011 16:43:01 -0500 (CDT) Date: Mon, 20 Jun 2011 14:43:00 -0700 From: Tina Tsou In-reply-to: To: secdir-secretary@mit.edu, secdir@ietf.org Message-id: <008901cc2f93$0796e7d0$16c4b770$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcwtDFGsXC3d3P44T5at7uPQ49mLbACgoNfw x-cr-hashedpuzzle: H5Hw H/OP Jcky Jqg4 NuzK Pfzl Uv50 U4oQ U+GS XF8w bqMQ ckeZ em4l hr5q lTz7 rV23; 4; ZAByAGEAZgB0AC0AaQBlAHQAZgAtAHYANgBvAHAAcwAtADYAdABvADQALQB0AG8ALQBoAGkAcwB0AG8AcgBpAGMAQAB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwByAGcAOwBpAGUAcwBnAEAAaQBlAHQAZgAuAG8AcgBnADsAcwBlAGMAZABpAHIALQBzAGUAYwByAGUAdABhAHIAeQBAAG0AaQB0AC4AZQBkAHUAOwBzAGUAYwBkAGkAcgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {64D14EA9-10AA-4AAF-AB23-ED6F55E78AEA}; dABlAG4AYQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Mon, 20 Jun 2011 21:42:52 GMT; cwBlAGMAZABpAHIAIAByAGUAdgBpAGUAdwAgAG8AZgAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQB2ADYAbwBwAHMALQA2AHQAbwA0AC0AdABvAC0AaABpAHMAdABvAHIAaQBjAC0AMAA0AA== x-cr-puzzleid: {64D14EA9-10AA-4AAF-AB23-ED6F55E78AEA} References: Cc: draft-ietf-v6ops-6to4-to-historic@tools.ietf.org, 'IESG' Subject: [secdir] secdir review of draft-ietf-v6ops-6to4-to-historic-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 21:43:03 -0000 Hi Sam et al, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document requests that RFC3056 and the companion document "An Anycast Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status. I have some minor nits below, but overall the document seems in fine shape. 3. 6to4 operational problems "In any case this model has the same operational burden has manually configured tunnels and has seen no deployment in the public Internet." Should be "In any case this model has the same operational burden as manually configured tunnels and has seen no deployment in the public Internet." As the author said, There are no new security considerations pertaining to this document. General security issues with tunnels are listed in [I-D.ietf-v6ops-tunnel-security-concerns] and more specifically to 6to4 in [RFC3964] and [I-D.ietf-v6ops-tunnel-loops]. By the way, it is proposed to use 6rd replacing 6to4. 6rd is a good technology, but cannot involve to IPv6. There are experiments on IPoE based 6rd, a little on PPPoE based 6rd. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From scott@hyperthought.com Mon Jun 20 17:59:31 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE6111E8242 for ; Mon, 20 Jun 2011 17:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXCBlM1F1PeS for ; Mon, 20 Jun 2011 17:59:31 -0700 (PDT) Received: from smtp142.iad.emailsrvr.com (smtp142.iad.emailsrvr.com [207.97.245.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC5111E823F for ; Mon, 20 Jun 2011 17:59:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp54.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id ADF902B04F8; Mon, 20 Jun 2011 20:59:30 -0400 (EDT) X-Virus-Scanned: OK Received: from dynamic7.wm-web.iad.mlsrvr.com (dynamic7.wm-web.iad1a.rsapps.net [192.168.2.148]) by smtp54.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 949DB2B04AC; Mon, 20 Jun 2011 20:59:30 -0400 (EDT) Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic7.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 7FF4F153806A; Mon, 20 Jun 2011 20:59:30 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Mon, 20 Jun 2011 17:59:30 -0700 (PDT) Date: Mon, 20 Jun 2011 17:59:30 -0700 (PDT) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-opsawg-mib-floats.all@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1308617970.522710224@apps.rackspace.com> X-Mailer: webmail7.0 Subject: [secdir] secdir review of draft-ietf-opsawg-mib-floats X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 00:59:31 -0000 Sorry this is late. I have reviewed this document as part of the security d= irectorate's ongoing effort to review all IETF documents being processed by= the IESG. These comments were written primarily for the benefit of the se= curity area directors. Document editors and WG chairs should treat these c= omments just like any other last call comments.=0A=0AFrom the introduction,= this doc defines textual conventions for the representation of floating-po= int numbers. The security considerations section points out that the doc on= ly defines textual conventions, and says, "Meaningful security consideratio= ns can only be written in the MIB modules that define management objects. = Therefore, this memo has no impact on the security of the Internet." I agre= e with this.=0A=0A--Scott=0A=0A=0A=0A From kivinen@iki.fi Tue Jun 21 02:17:34 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A7F11E80C1; Tue, 21 Jun 2011 02:17:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQB92o4y4UkW; Tue, 21 Jun 2011 02:17:33 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D4311E807C; Tue, 21 Jun 2011 02:17:32 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p5L9HSkr005192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jun 2011 12:17:28 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p5L9HRfL006197; Tue, 21 Jun 2011 12:17:27 +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: <19968.24999.639579.154207@fireball.kivinen.iki.fi> Date: Tue, 21 Jun 2011 12:17:27 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: draft-ietf-mpls-tp-loss-delay-profile.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-mpls-tp-loss-delay-profile-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 09:17:34 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is the profile document profiling a subset of the draft-ietf-mpls-loss-delay document and as such it does not introduce any new security considerations. The current security considerations section points directly to the draft-ietf-mpls-loss-delay. I see no issues with this document. -- kivinen@iki.fi From weiler+secdir@watson.org Thu Jun 23 15:34:24 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F1811E8081 for ; Thu, 23 Jun 2011 15:34:24 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB9+c0wlK6qq for ; Thu, 23 Jun 2011 15:34:23 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id B3B9611E8078 for ; Thu, 23 Jun 2011 15:34:23 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p5NMYMWj002984 for ; Thu, 23 Jun 2011 18:34:22 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p5NMYLcI002978 for ; Thu, 23 Jun 2011 18:34:22 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 23 Jun 2011 18:34:21 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 23 Jun 2011 18:34:22 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 22:34:24 -0000 There was a telechat today, and another is scheduled for next week. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Richard Barnes is next in the rotation. For telechat 2011-06-30 Reviewer LC end Draft Jeffrey Hutzelman T 2011-06-14 draft-ietf-soc-overload-design-06 Catherine Meadows T 2011-06-30 draft-ietf-appsawg-rfc3536bis-02 Kathleen Moriarty T 2011-06-30 draft-ietf-ftpext2-hosts-02 Sandy Murphy T 2011-06-22 draft-ietf-payload-rfc3016bis-01 Eric Rescorla T 2011-06-29 draft-ietf-dkim-rfc4871bis-12 Stefan Santesson T 2011-06-27 draft-ietf-pim-mtid-08 For telechat 2011-07-14 Reviewer LC end Draft Chris Lonvick T 2011-07-14 draft-gellens-mime-bucket-bis-05 David McGrew T 2011-07-08 draft-iesg-rfc1150bis-01 Vincent Roca T 2011-07-04 draft-ietf-mboned-ssmping-08 Yaron Sheffer T 2011-05-18 draft-ietf-sidr-repos-struct-08 Tom Yu T 2011-07-04 draft-ietf-mpls-ldp-p2mp-14 Larry Zhu T 2011-07-05 draft-ietf-mpls-tp-linear-protection-07 Glen Zorn T 2011-07-05 draft-ietf-mptcp-congestion-05 Last calls and special requests: Reviewer LC end Draft Derek Atkins 2011-07-04 draft-ietf-roll-of0-14 Rob Austein 2011-07-18 draft-shiomoto-ccamp-switch-programming-05 Shawn Emery 2011-06-06 draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-01 Phillip Hallam-Baker 2011-06-14 draft-ietf-dime-local-keytran-11 Julien Laganier 2011-06-15 draft-ietf-ipfix-configuration-model-09 Matt Lepinski 2011-07-13 draft-burgin-ipsec-suiteb-profile-00 Catherine Meadows R2011-04-13 draft-ietf-speechsc-mrcpv2-24 Russ Mundy 2011-06-30 draft-ietf-karp-design-guide-02 Magnus Nystrom 2011-07-13 draft-polk-local-emergency-rph-namespace-01 Tim Polk 2011-05-11 draft-ietf-vrrp-unified-mib-09 Tim Polk 2011-06-30 draft-ietf-codec-requirements-04 Joe Salowey 2011-05-30 draft-ietf-mpls-lsp-ping-enhanced-dsmap-09 Ondrej Sury 2011-06-30 draft-ietf-sidr-rescerts-provisioning-10 Tina TSOU 2011-04-23 draft-shin-augmented-pake-06 Carl Wallace 2011-05-30 draft-ietf-mpls-p2mp-lsp-ping-17 Carl Wallace 2011-07-21 draft-forte-lost-extensions-06 Sam Weiler 2011-07-20 draft-gutmann-cms-hmac-enc-05 Brian Weis 2011-07-04 draft-ietf-6man-flow-ecmp-03 Nico Williams 2011-07-04 draft-ietf-6man-flow-update-06 Glen Zorn 2011-06-28 draft-li-pwe3-ms-pw-pon-03 From kathleen.moriarty@emc.com Fri Jun 24 09:04:13 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFB111E80E9; Fri, 24 Jun 2011 09:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UZXbsaShB7b; Fri, 24 Jun 2011 09:04:12 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 317BB11E80E3; Fri, 24 Jun 2011 09:04:11 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p5OG4AfA003537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2011 12:04:10 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Fri, 24 Jun 2011 12:03:52 -0400 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.221.47.158]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p5OG2GdT025061; Fri, 24 Jun 2011 12:02:17 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub29.corp.emc.com ([128.221.47.158]) with mapi; Fri, 24 Jun 2011 12:02:14 -0400 From: To: , , Date: Fri, 24 Jun 2011 12:02:13 -0400 Thread-Topic: SECDIR review of draft-ietf-ftpext2-hosts-02 Thread-Index: AcwyiBUFO2skqoQCSLqk+KSpXVMV4Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: phethmon@hethmon.com, robmcm@microsoft.com Subject: [secdir] SECDIR review of draft-ietf-ftpext2-hosts-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 16:04:13 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: The document requires more information in the security considerat= ions section. Section 3.2: In terms of the types of changes that may be made, it does state 'more elab= orate changes' may be made depending on the environment. However, for secu= rity and the developers reading the specification, I think it would be best= to include the high end of the spectrum here and include isolation as one = of the explicitly stated examples as the scenario may be used in hosted env= ironments. Upon receiving the HOST command, before authenticating the user-PI, a server-FTP process SHOULD validate that the hostname given represents a valid virtual host for that server, and, if it is valid, establish the appropriate environment for that virtual host. The resultant actions needed to create that environment are not specified here, and may range from doing nothing at all, to performing a simple change of working directory, to changing authentication schemes and/or username and password lists, to making much more elaborate state changes, as necessary. Section 4: Security Considerations Please replace the term Confidentiality where you have listed "integrity" i= n the opening sentence as the protection of privacy related information is = described through confidentiality. The integrity and confidentiality of th= e data on the servers are both potentially important, but this opening sent= ence is in context of login parameters. The second paragraph does address the authentication between virtual hosts,= which is good. I think it is also important to ensure readers are aware o= f possible concerns with segregation or isolation of the virtual FTP enviro= nments. If there are security concerns that may include different user bas= es on the same physical host or different levels (sensitivity) of informati= on in different FTP hosts on the same server, the ability to have segregati= on of the environments will be important (this will happen). How can segre= gation/isolation be provided in this model? Please include information on = the options here. I am assuming that since we are talking about multiple h= osts on a single IP, that we may be within a physical host or a virtual env= ironment that has one IP address. If this is the case, what security optio= ns are available - authentication, access controls, etc.? Please include t= hem in this section. Thank you, Kathleen From robmcm@microsoft.com Fri Jun 24 12:03:37 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37ABA22801B; Fri, 24 Jun 2011 12:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.092 X-Spam-Level: X-Spam-Status: No, score=-6.092 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-8, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYLSNyXmGEZI; Fri, 24 Jun 2011 12:03:33 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 1A050228006; Fri, 24 Jun 2011 12:03:31 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 24 Jun 2011 12:03:24 -0700 Received: from DB3EHSOBE005.bigfish.com (157.54.51.80) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 24 Jun 2011 12:03:22 -0700 Received: from mail28-db3-R.bigfish.com (10.3.81.246) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.22; Fri, 24 Jun 2011 19:03:20 +0000 Received: from mail28-db3 (localhost.localdomain [127.0.0.1]) by mail28-db3-R.bigfish.com (Postfix) with ESMTP id C6CFC9281C6; Fri, 24 Jun 2011 19:03:20 +0000 (UTC) X-SpamScore: -34 X-BigFish: PS-34(zz9371M4015L103dK542Mzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT008.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail28-db3: transitioning domain of microsoft.com does not designate 157.55.61.146 as permitted sender) client-ip=157.55.61.146; envelope-from=robmcm@microsoft.com; helo=CH1PRD0302HT008.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail28-db3 (localhost.localdomain [127.0.0.1]) by mail28-db3 (MessageSwitch) id 1308942200408783_12126; Fri, 24 Jun 2011 19:03:20 +0000 (UTC) Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.252]) by mail28-db3.bigfish.com (Postfix) with ESMTP id 5CEC31950054; Fri, 24 Jun 2011 19:03:20 +0000 (UTC) Received: from CH1PRD0302HT008.namprd03.prod.outlook.com (157.55.61.146) by DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 24 Jun 2011 19:03:19 +0000 Received: from CH1PRD0302MB131.namprd03.prod.outlook.com ([169.254.11.234]) by CH1PRD0302HT008.namprd03.prod.outlook.com ([10.28.29.127]) with mapi id 14.01.0225.056; Fri, 24 Jun 2011 19:03:17 +0000 From: Robert McMurray To: "kathleen.moriarty@emc.com" , "secdir@ietf.org" , "draft-ietf-ftpext2-hosts.all@tools.ietf.org" , "iesg@ietf.org" Thread-Topic: SECDIR review of draft-ietf-ftpext2-hosts-02 Thread-Index: AcwyiBUFO2skqoQCSLqk+KSpXVMV4QADvEhg Date: Fri, 24 Jun 2011 19:03:16 +0000 Message-ID: <01AA9EC92749BF4894AC2B3039EA4A2C1949D137@CH1PRD0302MB131.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.28.29.74] Content-Type: multipart/mixed; boundary="_003_01AA9EC92749BF4894AC2B3039EA4A2C1949D137CH1PRD0302MB131_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT008.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%EMC.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HETHMON.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com X-Mailman-Approved-At: Fri, 24 Jun 2011 13:45:01 -0700 Cc: "phethmon@hethmon.com" , "Anthony Bryan \(anthonybryan@gmail.com\)" Subject: Re: [secdir] SECDIR review of draft-ietf-ftpext2-hosts-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 19:03:37 -0000 --_003_01AA9EC92749BF4894AC2B3039EA4A2C1949D137CH1PRD0302MB131_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Kathleen. [Note: Adding Anthony Bryan as the document shepherd.] Here is a suggested rewording of the fragment from Section 3.2 for which yo= u had requested an update - does this agree with what you were looking for? "The resultant actions needed to create that environment are not specified = here, and may range from doing nothing at all, to performing a simple chang= e of working directory, or changing authentication schemes and/or username = and password lists, or making much more elaborate state changes - such as c= reating isolated environments for each FTP session." Your first of comment about Section 4 is an easy change - thanks! Your second set of comments about Section 4 seems to me to be less about th= e protocol and more about the actual implementation details, which I think = we should avoid. As an example, I have a background on UNIX, Windows, and s= everal other platforms; the way that I might choose to implement segregatio= n/isolation for each of those platforms will differ radically. For example,= process isolation might come to mind as one possible implementation, but t= he way that processes actually work varies greatly depending on the platfor= m, and it might only make sense on one platform and not the others, but in = any case we shouldn't be suggesting something that specific in an RFC anywa= y. For that matter, the way that accounts and permissions are used on each = platform also differs greatly, so it does not seem to make sense to call ou= t those concepts, either. In the end, each server implementer has a variety= of platform-specific options that are available within their specific situ= ation when they are considering how to implement their unique security envi= ronments, and all of which are outside the scope of this draft. With that = in mind, I do not think that Section 4 should be updated with verbiage that= says something to the effect of, "Actual server implementations for creati= ng security environments for virtual hosts are outside the scope of this do= cument, but you could use a combination of platform-specific technologies s= uch as authentication, isolation, access control, etc." That being said, I have attached an updated version of the draft in TXT and= XML format. Thanks! -----Original Message----- From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com]=20 Sent: Friday, June 24, 2011 9:02 AM To: secdir@ietf.org; draft-ietf-ftpext2-hosts.all@tools.ietf.org; iesg@ietf= .org Cc: phethmon@hethmon.com; Robert McMurray Subject: SECDIR review of draft-ietf-ftpext2-hosts-02 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. Summary: The document requires more information in the security considerat= ions section. Section 3.2: In terms of the types of changes that may be made, it does state 'more elab= orate changes' may be made depending on the environment. However, for secu= rity and the developers reading the specification, I think it would be best= to include the high end of the spectrum here and include isolation as one = of the explicitly stated examples as the scenario may be used in hosted env= ironments. Upon receiving the HOST command, before authenticating the user-PI, a server-FTP process SHOULD validate that the hostname given represents a valid virtual host for that server, and, if it is valid, establish the appropriate environment for that virtual host. The resultant actions needed to create that environment are not specified here, and may range from doing nothing at all, to performing a simple change of working directory, to changing authentication schemes and/or username and password lists, to making much more elaborate state changes, as necessary. Section 4: Security Considerations Please replace the term Confidentiality where you have listed "integrity" i= n the opening sentence as the protection of privacy related information is = described through confidentiality. The integrity and confidentiality of th= e data on the servers are both potentially important, but this opening sent= ence is in context of login parameters. The second paragraph does address the authentication between virtual hosts,= which is good. I think it is also important to ensure readers are aware o= f possible concerns with segregation or isolation of the virtual FTP enviro= nments. If there are security concerns that may include different user bas= es on the same physical host or different levels (sensitivity) of informati= on in different FTP hosts on the same server, the ability to have segregati= on of the environments will be important (this will happen). How can segre= gation/isolation be provided in this model? Please include information on = the options here. I am assuming that since we are talking about multiple h= osts on a single IP, that we may be within a physical host or a virtual env= ironment that has one IP address. If this is the case, what security optio= ns are available - authentication, access controls, etc.? Please include t= hem in this section. Thank you, Kathleen --_003_01AA9EC92749BF4894AC2B3039EA4A2C1949D137CH1PRD0302MB131_ Content-Type: application/xml; name="draft-ietf-ftpext2-hosts-03.xml" Content-Description: draft-ietf-ftpext2-hosts-03.xml Content-Disposition: attachment; filename="draft-ietf-ftpext2-hosts-03.xml"; size=55505; creation-date="Fri, 24 Jun 2011 17:26:09 GMT"; modification-date="Fri, 24 Jun 2011 18:49:38 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXMtYXNjaWkiPz4NCjwhRE9DVFlQRSByZmMg U1lTVEVNICJyZmMyNjI5LmR0ZCJbCgoKPCFFTlRJVFkgUkZDMjExOSBTWVNURU0gImh0dHA6Ly94 bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuMjExOS54bWwi Pgo8IUVOVElUWSBSRkMyNjI5IFNZU1RFTSAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGlj L3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy4yNjI5LnhtbCI+CjwhRU5USVRZIFJGQzM1NTIgU1lT VEVNICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2Uu UkZDLjM1NTIueG1sIj4KPCFFTlRJVFkgSS1ELm5hcnRlbi1pYW5hLWNvbnNpZGVyYXRpb25zLXJm YzI0MzRiaXMgU1lTVEVNICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnht bDMvcmVmZXJlbmNlLkktRC5uYXJ0ZW4taWFuYS1jb25zaWRlcmF0aW9ucy1yZmMyNDM0YmlzLnht bCI+Cl0+DQo8P3htbC1zdHlsZXNoZWV0IHR5cGU9J3RleHQveHNsJyBocmVmPSdyZmMyNjI5Lnhz bHQnID8+DQo8P3JmYyBzdHJpY3Q9InllcyIgPz4NCjw/cmZjIHRvYz0ieWVzIj8+DQo8P3JmYyB0 b2NkZXB0aD0iNCI/Pg0KPD9yZmMgc3ltcmVmcz0ieWVzIj8+DQo8P3JmYyBzb3J0cmVmcz0ieWVz IiA/Pg0KPD9yZmMgY29tcGFjdD0ieWVzIiA/Pg0KPD9yZmMgc3ViY29tcGFjdD0ibm8iID8+DQo8 cmZjIGNhdGVnb3J5PSJzdGQiIGRvY05hbWU9ImRyYWZ0LWlldGYtZnRwZXh0Mi1ob3N0cy0wMyIg aXByPSJ0cnVzdDIwMDkwMiIgb2Jzb2xldGVzPSIiIHVwZGF0ZXM9Ijk1OSIgc3VibWlzc2lvblR5 cGU9IklFVEYiIHhtbDpsYW5nPSJlbiI+DQogIDxmcm9udD4NCiAgICA8dGl0bGUgYWJicmV2PSJG VFAgSE9TVCBDb21tYW5kIGZvciBWaXJ0dWFsIEhvc3RzIj5GaWxlIFRyYW5zZmVyIFByb3RvY29s IEhPU1QgQ29tbWFuZCBmb3IgVmlydHVhbCBIb3N0czwvdGl0bGU+DQogICAgPGF1dGhvciBmdWxs bmFtZT0iUGF1bCBIZXRobW9uIiBpbml0aWFscz0iUC4iIHN1cm5hbWU9IkhldGhtb24iPg0KICAg ICAgPG9yZ2FuaXphdGlvbj5IZXRobW9uIEJyb3RoZXJzPC9vcmdhbml6YXRpb24+DQogICAgICA8 YWRkcmVzcz4NCiAgICAgICAgPHBvc3RhbD4NCiAgICAgICAgICA8c3RyZWV0PjIzMDUgQ2h1a2Fy IFJvYWQ8L3N0cmVldD4NCiAgICAgICAgICA8Y2l0eT5Lbm94dmlsbGU8L2NpdHk+DQogICAgICAg ICAgPHJlZ2lvbj5UTjwvcmVnaW9uPg0KICAgICAgICAgIDxjb2RlPjM3OTIzPC9jb2RlPg0KICAg ICAgICAgIDxjb3VudHJ5PlVTQTwvY291bnRyeT4NCiAgICAgICAgPC9wb3N0YWw+DQogICAgICAg IDxlbWFpbD5waGV0aG1vbkBoZXRobW9uLmNvbTwvZW1haWw+DQogICAgICA8L2FkZHJlc3M+DQog ICAgPC9hdXRob3I+DQogICAgPGF1dGhvciBmdWxsbmFtZT0iUm9iZXJ0IE1jTXVycmF5IiBpbml0 aWFscz0iUi4iIHN1cm5hbWU9Ik1jTXVycmF5Ij4NCiAgICAgIDxvcmdhbml6YXRpb24+TWljcm9z b2Z0IENvcnBvcmF0aW9uPC9vcmdhbml6YXRpb24+DQogICAgICA8YWRkcmVzcz4NCiAgICAgICAg PHBvc3RhbD4NCiAgICAgICAgICA8c3RyZWV0Pk9uZSBNaWNyb3NvZnQgV2F5PC9zdHJlZXQ+DQog ICAgICAgICAgPGNpdHk+UmVkbW9uZDwvY2l0eT4NCiAgICAgICAgICA8cmVnaW9uPldBPC9yZWdp b24+DQogICAgICAgICAgPGNvZGU+OTgwNTI8L2NvZGU+DQogICAgICAgICAgPGNvdW50cnk+VVNB PC9jb3VudHJ5Pg0KICAgICAgICA8L3Bvc3RhbD4NCiAgICAgICAgPGVtYWlsPnJvYm1jbUBtaWNy b3NvZnQuY29tPC9lbWFpbD4NCiAgICAgIDwvYWRkcmVzcz4NCiAgICA8L2F1dGhvcj4NCiAgICA8 ZGF0ZSBtb250aD0iSnVuZSIgeWVhcj0iMjAxMSIgLz4NCiAgICA8d29ya2dyb3VwPkZUUEVYVDIg V29ya2luZyBHcm91cDwvd29ya2dyb3VwPg0KICAgIDxrZXl3b3JkPkZUUDwva2V5d29yZD4NCiAg ICA8a2V5d29yZD5IT1NUPC9rZXl3b3JkPg0KICAgIDxhYnN0cmFjdD4NCiAgICAgIDx0PlRoZSBG aWxlIFRyYW5zZmVyIFByb3RvY29sLCBhcyBkZWZpbmVkIGluIFJGQyA5NTkgW1JGQzA5NTldLCBk b2VzIG5vdCBwcm92aWRlIGEgd2F5IGZvciBGVFAgY2xpZW50cyBhbmQgc2VydmVycyB0byBkaWZm ZXJlbnRpYXRlIGJldHdlZW4gbXVsdGlwbGUgRE5TIG5hbWVzIHRoYXQgYXJlIHJlZ2lzdGVyZWQg Zm9yIGEgc2luZ2xlIElQIGFkZHJlc3MuICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgRlRQ IGNvbW1hbmQgdGhhdCBwcm92aWRlcyBhIG1lY2hhbmlzbSBmb3IgRlRQIGNsaWVudHMgYW5kIHNl cnZlcnMgdG8gaWRlbnRpZnkgaW5kaXZpZHVhbCB2aXJ0dWFsIGhvc3RzIG9uIGFuIEZUUCBzZXJ2 ZXIuPC90Pg0KICAgIDwvYWJzdHJhY3Q+DQogIDwvZnJvbnQ+DQogIDxtaWRkbGU+DQogICAgPHNl Y3Rpb24gdGl0bGU9IkludHJvZHVjdGlvbiIgdG9jPSJkZWZhdWx0Ij4NCiAgICAgIDx0Pkl0IGlz IGNvbW1vbiBvbiB0aGUgSW50ZXJuZXQgZm9yIG1hbnkgRE5TIG5hbWVzIHRvIHJlc29sdmUgdG8g YSBzaW5nbGUgSVAgYWRkcmVzcy4gIFRoaXMgcHJhY3RpY2UgaGFzIGludHJvZHVjZWQgdGhlIGNv bmNlcHQgb2YgYSAidmlydHVhbCBob3N0Iiwgd2hlcmUgYSBob3N0IGFwcGVhcnMgdG8gZXhpc3Qg YXMgYW4gaW5kZXBlbmRlbnQgZW50aXR5LCBidXQgaW4gcmVhbGl0eSBzaGFyZXMgaXRzIHBoeXNp Y2FsIHJlc291cmNlcyB3aXRoIG9uZSBvciBtb3JlIHNpbWlsYXIgaG9zdHMuPC90Pg0KICAgICAg PHQ+U3VjaCBhbiBhcnJhbmdlbWVudCBwcmVzZW50cyBzb21lIHByb2JsZW1zIGZvciBGVFAgc2Vy dmVycywgYXMgYW4gRlRQIHNlcnZlciBkaXN0aW5ndWlzaGVzIGluY29taW5nIEZUUCBjb25uZWN0 aW9ucyBieSB0aGVpciBJUCBhZGRyZXNzZXMsIG5vdCB0aGVpciBETlMgbmFtZXMsIGJlY2F1c2Ug aG9zdHMgYXJlIHVuaXF1ZWx5IGlkZW50aWZpZWQgYnkgdGhlaXIgYWRkcmVzcyByYXRoZXIgdGhh biBuYW1lLiAgVGhhdCBpcywgYWxsIEROUyBuYW1lcyB0aGF0IHNoYXJlIGFuIElQIGFkZHJlc3Mg YXJlIGhhbmRsZWQgYnkgdGhlIHNhbWUgRlRQIHNlcnZlciBhbmQgc2hhcmUgdGhlIHNhbWUgTmV0 d29yayBWaXJ0dWFsIEZpbGUgU3lzdGVtIChOVkZTKS48L3Q+DQogICAgICA8dD5UaGlzIG1lYW5z IHRoYXQgZGlmZmVyZW50IHZpcnR1YWwgaG9zdHMgY2Fubm90IG9mZmVyIGRpZmZlcmVudCB2aXJ0 dWFsIGZpbGUgc3lzdGVtcyB0byBjbGllbnRzLCBub3IgY2FuIHRoZXkgb2ZmZXIgZGlmZmVyZW50 IGF1dGhlbnRpY2F0aW9uIHN5c3RlbXMuICBBbnkgc2NoZW1lIHRvIG92ZXJjb21lIHRoaXMgaXNz dWUgbmVlZHMgdG8gaW5kaWNhdGUgbm90IG9ubHkgdGhlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3Ms IGJ1dCBhbHNvIHRoZSB2aXJ0dWFsIGhvc3QgbmFtZSB0aGF0IGlzIGFzc29jaWF0ZWQgd2l0aCB0 aGUgZGVzaXJlZCB2aXJ0dWFsIEZUUCBzZXJ2ZXIuICBUeXBpY2FsIHVzZXItRlRQIHByb2Nlc3Nl cyBjdXJyZW50bHkgdXNlIGhvc3RuYW1lcyB0byBwZXJmb3JtIGhvc3RuYW1lIHRvIElQIGFkZHJl c3MgcmVzb2x1dGlvbiBhbmQgdGhlbiBpZ25vcmUgaG9zdG5hbWVzIGZvciB0aGUgcmVzdCBvZiB0 aGUgRlRQIHNlc3Npb24sIHRoZXJlZm9yZSBhbnkgbWVjaGFuaXNtIHRvIG92ZXJjb21lIHRoaXMg aXNzdWUgd291bGQgcmVxdWlyZSBtb2RpZmljYXRpb25zIHRvIHRoZSB1c2VyLVBJIGFuZCBzZXJ2 ZXItUEkuPC90Pg0KICAgICAgPHQ+SXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgdGhpcyBzYW1lIHBy b2JsZW0gZXhpc3RlZCBmb3IgSFRUUC8xLjAgYXMgZGVmaW5lZCBpbiA8eHJlZiB0YXJnZXQ9IlJG QzE5NDUiIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCI+PC94cmVmPiwgYW5kIHdhcyBy ZXNvbHZlZCBpbiBIVFRQLzEuMSBhcyBkZWZpbmVkIGluIDx4cmVmIHRhcmdldD0iUkZDMjYxNiIg cGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0Ij48L3hyZWY+IHRocm91Z2ggdGhlIGFkZGl0 aW9uIG9mIHRoZSBIb3N0IHJlcXVlc3QgaGVhZGVyLiAgVGhlIGdvYWwgb2YgdGhpcyBkb2N1bWVu dCBpcyB0byBicmluZyBhIHNpbWlsYXIgbGV2ZWwgb2YgZmVhdHVyZSBwYXJpdHkgdG8gRlRQIGJ5 IGludHJvZHVjaW5nIGEgbmV3IEhPU1QgY29tbWFuZCB0aGF0IGFsbG93cyB1c2VyLUZUUCBwcm9j ZXNzZXMgdG8gc3BlY2lmeSB3aGljaCB2aXJ0dWFsIGhvc3QgdG8gY29ubmVjdCB0byBmb3IgYSBz ZXJ2ZXItRlRQIHByb2Nlc3MgdGhhdCBpcyBoYW5kbGluZyByZXF1ZXN0cyBmb3IgbXVsdGlwbGUg dmlydHVhbCBob3N0cyBvbiBhIHNpbmdsZSBJUCBhZGRyZXNzLjwvdD4NCiAgICA8L3NlY3Rpb24+ DQogICAgPHNlY3Rpb24gdGl0bGU9IkRvY3VtZW50IENvbnZlbnRpb25zIiB0b2M9ImRlZmF1bHQi Pg0KICAgICAgPHQ+VGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIs ICJTSEFMTCIsICJTSEFMTCBOT1QiLCAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5E RUQiLCAgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGlu dGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9IlJGQzIxMTkiIHBhZ2Vubz0i ZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCI+PC94cmVmPi48L3Q+DQogICAgICA8dD5JbiBleGFtcGxl cywgIkMmZ3Q7IiBhbmQgIlMmZ3Q7IiBpbmRpY2F0ZSBsaW5lcyBzZW50IGJ5IHRoZSBjbGllbnQg YW5kIHNlcnZlciwgcmVzcGVjdGl2ZWx5LjwvdD4NCiAgICAgIDx0PlRoaXMgZG9jdW1lbnQgYWxz byB1c2VzIG5vdGF0aW9uIGRlZmluZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkMwOTU5IiBwYWdlbm89 ImZhbHNlIiBmb3JtYXQ9ImRlZmF1bHQiPjwveHJlZj4gYW5kIDx4cmVmIHRhcmdldD0iUkZDMTEy MyIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0Ij48L3hyZWY+LiAgSW4gcGFydGljdWxh ciwgdGhlIHRlcm1zICJyZXBseSIsICJ1c2VyIiwgIk5WRlMiLCAiTlZUIiwgImZpbGUiLCAicGF0 aG5hbWUiLCAiRlRQIGNvbW1hbmRzIiwgIkRUUCIsICJ1c2VyLUZUUCBwcm9jZXNzIiwgInVzZXIt UEkiLCAidXNlci1EVFAiLCAic2VydmVyLUZUUCBwcm9jZXNzIiwgInNlcnZlci1QSSIsICJzZXJ2 ZXItRFRQIiwgIm1vZGUiLCAidHlwZSIsICJjb250cm9sIGNvbm5lY3Rpb24iLCAiZGF0YSBjb25u ZWN0aW9uIiwgYW5kICJBU0NJSSIsIGFyZSBhbGwgdXNlZCBoZXJlIGFzIGRlZmluZWQgdGhlcmUu PC90Pg0KICAgICAgPHQ+U3ludGF4IHJlcXVpcmVkIGlzIGRlZmluZWQgdXNpbmcgdGhlIEF1Z21l bnRlZCBCTkYgZGVmaW5lZCBpbiA8eHJlZiB0YXJnZXQ9IlJGQzUyMzQiIHBhZ2Vubz0iZmFsc2Ui IGZvcm1hdD0iZGVmYXVsdCI+PC94cmVmPi4gIFNvbWUgZ2VuZXJhbCBBQk5GIGRlZmluaXRpb25z IGFyZSByZXF1aXJlZCB0aHJvdWdob3V0IHRoZSBkb2N1bWVudDsgdGhvc2Ugd2lsbCBiZSBkZWZp bmVkIGxhdGVyIGluIHRoaXMgc2VjdGlvbi4gIEF0IGZpcnN0IHJlYWRpbmcsIGl0IG1heSBiZSB3 aXNlIHRvIHNpbXBseSByZWNhbGwgdGhhdCB0aGVzZSBkZWZpbml0aW9ucyBleGlzdCBoZXJlLCBh bmQgc2tpcCB0byB0aGUgbmV4dCBzZWN0aW9uLjwvdD4NCiAgICAgIDxzZWN0aW9uIHRpdGxlPSJC YXNpYyBUb2tlbnMiIHRvYz0iZGVmYXVsdCI+DQogICAgICAgIDx0PlRoaXMgZG9jdW1lbnQgaW1w b3J0cyB0aGUgY29yZSBkZWZpbml0aW9ucyBnaXZlbiBpbiBBcHBlbmRpeCBCIG9mIDx4cmVmIHRh cmdldD0iUkZDNTIzNCIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0IiAvPi4gIFRoZXJl IGRlZmluaXRpb25zIHdpbGwgYmUgZm91bmQgZm9yIGJhc2ljIEFCTkYgZWxlbWVudHMgbGlrZSBB TFBIQSwgRElHSVQsIFNQLCBldGMuICBUbyB0aGF0LCB0aGUgZm9sbG93aW5nIHRlcm0gaXMgYWRk ZWQgZm9yIHVzZSBpbiB0aGlzIGRvY3VtZW50LjwvdD4NCiAgICAgICAgPHQ+DQogICAgICAgICAg PGZpZ3VyZSB0aXRsZT0iIiBzdXBwcmVzcy10aXRsZT0iZmFsc2UiIGFsaWduPSJsZWZ0IiBhbHQ9 IiIgd2lkdGg9IiIgaGVpZ2h0PSIiPg0KICAgICAgICAgICAgPGFydHdvcmsgdHlwZT0iQUJORiIg eG1sOnNwYWNlPSJwcmVzZXJ2ZSIgbmFtZT0iIiBhbGlnbj0ibGVmdCIgYWx0PSIiIHdpZHRoPSIi IGhlaWdodD0iIj48IVtDREFUQVsgICAgIFRDSEFSID0gVkNIQVIgLyBTUCAvIEhUQUIgICAgOyB2 aXNpYmxlIHBsdXMgd2hpdGUgc3BhY2VdXT48L2FydHdvcms+DQogICAgICAgICAgPC9maWd1cmU+ DQogICAgICAgIDwvdD4NCiAgICAgICAgPHQ+VGhlIFZDSEFSIChmcm9tIDx4cmVmIHRhcmdldD0i UkZDNTIzNCIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0IiAvPikgYW5kIFRDSEFSIHJ1 bGVzIGdpdmUgYmFzaWMgY2hhcmFjdGVyIHR5cGVzIGZyb20gdmFyeWluZyBzdWItc2V0cyBvZiB0 aGUgQVNDSUkgY2hhcmFjdGVyIHNldCBmb3IgdXNlIGluIHZhcmlvdXMgY29tbWFuZHMgYW5kIHJl c3BvbnNlcy48L3Q+DQogICAgICAgIDx0Pk5vdGUgdGhhdCBpbiBBQk5GLCBzdHJpbmcgbGl0ZXJh bHMgYXJlIGNhc2UgaW5zZW5zaXRpdmUuICBUaGF0IGNvbnZlbnRpb24gaXMgcHJlc2VydmVkIGlu IHRoaXMgZG9jdW1lbnQsIGFuZCBpbXBsaWVzIHRoYXQgRlRQIGNvbW1hbmRzIGFuZCBwYXJhbWV0 ZXJzIHRoYXQgYXJlIGFkZGVkIGJ5IHRoaXMgc3BlY2lmaWNhdGlvbiBoYXZlIHZhbHVlcyB0aGF0 IGNhbiBiZSByZXByZXNlbnRlZCBpbiBhbnkgY2FzZS4gIFRoYXQgaXMsICJIT1NUIiBpcyB0aGUg c2FtZSBhcyAiaG9zdCIsICJIb3N0IiwgIkhvU3QiLCBldGMuLCBhbmQgImZ0cC5leGFtcGxlLmNv bSIgaXMgdGhlIHNhbWUgYXMgIkZ0cC5FeGFtcGxlLkNvbSIsICJmVHAuZVhhbXBsZS5jT20iLCBl dGMuPC90Pg0KICAgICAgPC9zZWN0aW9uPg0KICAgICAgPHNlY3Rpb24gdGl0bGU9IlNlcnZlciBS ZXBsaWVzIiB0b2M9ImRlZmF1bHQiPg0KICAgICAgICA8dD5TZWN0aW9uIDQuMiBvZiA8eHJlZiB0 YXJnZXQ9IlJGQzA5NTkiIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIgLz4gZGVmaW5l cyB0aGUgZm9ybWF0IGFuZCBtZWFuaW5nIG9mIHJlcGxpZXMgYnkgdGhlIHNlcnZlci1QSSB0byBG VFAgY29tbWFuZHMgZnJvbSB0aGUgdXNlci1QSS4gIFRob3NlIHJlcGx5IGNvbnZlbnRpb25zIGFy ZSB1c2VkIGhlcmUgd2l0aG91dCBjaGFuZ2UuPC90Pg0KICAgICAgICA8dD4NCiAgICAgICAgICA8 ZmlndXJlIHRpdGxlPSIiIHN1cHByZXNzLXRpdGxlPSJmYWxzZSIgYWxpZ249ImxlZnQiIGFsdD0i IiB3aWR0aD0iIiBoZWlnaHQ9IiI+DQogICAgICAgICAgICA8YXJ0d29yayB0eXBlPSJBQk5GIiB4 bWw6c3BhY2U9InByZXNlcnZlIiBuYW1lPSIiIGFsaWduPSJsZWZ0IiBhbHQ9IiIgd2lkdGg9IiIg aGVpZ2h0PSIiPjwhW0NEQVRBWyAgICAgZXJyb3ItcmVzcG9uc2UgPSBlcnJvci1jb2RlIFNQICpU Q0hBUiBDUkxGDQogICAgIGVycm9yLWNvZGUgICAgID0gKCI0IiAvICI1IikgMkRJR0lUXV0+PC9h cnR3b3JrPg0KICAgICAgICAgIDwvZmlndXJlPg0KICAgICAgICA8L3Q+DQogICAgICAgIDx0Pklt cGxlbWVudGVycyBzaG91bGQgbm90ZSB0aGF0IHRoZSBBQk5GIHN5bnRheCAod2hpY2ggd2FzIG5v dCB1c2VkIGluIDx4cmVmIHRhcmdldD0iUkZDMDk1OSIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJk ZWZhdWx0IiAvPikgdXNlZCBpbiB0aGlzIGRvY3VtZW50LCBhbmQgb3RoZXIgRlRQIHJlbGF0ZWQg ZG9jdW1lbnRzLCBzb21ldGltZXMgc2hvd3MgcmVwbGllcyB1c2luZyB0aGUgb25lIGxpbmUgZm9y bWF0LiAgVW5sZXNzIG90aGVyd2lzZSBleHBsaWNpdGx5IHN0YXRlZCwgdGhhdCBpcyBub3QgaW50 ZW5kZWQgdG8gaW1wbHkgdGhhdCBtdWx0aS1saW5lIHJlc3BvbnNlcyBhcmUgbm90IHBlcm1pdHRl ZC4gIEltcGxlbWVudGVycyBzaG91bGQgYXNzdW1lIHRoYXQsIHVubGVzcyBzdGF0ZWQgdG8gdGhl IGNvbnRyYXJ5LCBhbnkgcmVwbHkgdG8gYW55IEZUUCBjb21tYW5kIChpbmNsdWRpbmcgUVVJVCkg Y2FuIGJlIG9mIHRoZSBtdWx0aS1saW5lIGZvcm1hdCBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0 PSJSRkMwOTU5IiBwYWdlbm89ImZhbHNlIiBmb3JtYXQ9ImRlZmF1bHQiIC8+LjwvdD4NCiAgICAg ICAgPHQ+VGhyb3VnaG91dCB0aGlzIGRvY3VtZW50LCByZXBsaWVzIHdpbGwgYmUgaWRlbnRpZmll ZCBieSB0aGUgdGhyZWUgZGlnaXQgY29kZSB0aGF0IGlzIHRoZWlyIGZpcnN0IGVsZW1lbnQuICBU aHVzIHRoZSB0ZXJtICI1MDAgcmVwbHkiIG1lYW5zIGEgcmVwbHkgZnJvbSB0aGUgc2VydmVyLVBJ IHVzaW5nIHRoZSB0aHJlZSBkaWdpdCBjb2RlICI1MDAiLjwvdD4NCiAgICAgIDwvc2VjdGlvbj4N CiAgICA8L3NlY3Rpb24+DQogICAgPHNlY3Rpb24gdGl0bGU9IlRoZSBIT1NUIGNvbW1hbmQiIHRv Yz0iZGVmYXVsdCI+DQogICAgICA8dD5BIG5ldyBjb21tYW5kICJIT1NUIiBpcyBhZGRlZCB0byB0 aGUgRlRQIGNvbW1hbmQgc2V0IHRvIGFsbG93IHRoZSBzZXJ2ZXItRlRQIHByb2Nlc3MgdG8gZGV0 ZXJtaW5lIHRvIHdoaWNoIG9mIHBvc3NpYmx5IG1hbnkgdmlydHVhbCBob3N0cyB0aGUgY2xpZW50 IHdpc2hlcyB0byBjb25uZWN0LiAgVGhpcyBjb21tYW5kIFNIT1VMRCBiZSBpc3N1ZWQgYmVmb3Jl IHRoZSB1c2VyIGlzIGF1dGhlbnRpY2F0ZWQsIGFsbG93aW5nIHRoZSBhdXRoZW50aWNhdGlvbiBz Y2hlbWUsIGFuZCBzZXQgb2YgbGVnYWwgdXNlcnMsIHRvIGJlIGRlcGVuZGVudCB1cG9uIHRoZSB2 aXJ0dWFsIGhvc3QgY2hvc2VuLiAgU2VydmVyLUZUUCBwcm9jZXNzZXMgU0hPVUxEIHRyZWF0IGEg c2l0dWF0aW9uIHdoZXJlIHRoZSBIT1NUIGNvbW1hbmQgaXMgaXNzdWVkIGFmdGVyIHRoZSB1c2Vy IGhhcyBiZWVuIGF1dGhlbnRpY2F0ZWQgdXNpbmcgb25lIG9mIHRoZSBmb2xsb3dpbmcgdHdvIGJl aGF2aW9yczo8L3Q+DQogICAgICA8dD4NCiAgICAgICAgPGxpc3Qgc3R5bGU9ImxldHRlcnMiPg0K ICAgICAgICAgIDx0PlRyZWF0IHRoZSBsYXRlIEhPU1QgY29tbWFuZCBhcyBhbiBlcnJvbmVvdXMg c2VxdWVuY2Ugb2YgY29tbWFuZHMgYW5kIHJldHVybiBhIDUwMyByZXBseS48L3Q+DQogICAgICAg ICAgPHQ+VHJlYXQgdGhlIGxhdGUgSE9TVCBjb21tYW5kIGFzIHRob3VnaCBhIFJFSU4gY29tbWFu ZCB3YXMgc2VudCBiZWZvcmUgdGhlIEhPU1QgY29tbWFuZCBhbmQgcmVzZXQgdGhlIHVzZXItUEkg dG8gdGhlIHN0YXRlIHRoYXQgZXhpc3RlZCBhZnRlciB0aGUgVENQIGNvbm5lY3Rpb24gd2FzIGZp cnN0IGVzdGFibGlzaGVkIGFuZCBiZWZvcmUgdGhlIGluaXRpYWwgdXNlciBhdXRoZW50aWNhdGlv biBhbmQgdGhlbiByZXR1cm4gdGhlIGFwcHJvcHJpYXRlIHJlcGx5IGZvciB0aGUgSE9TVCBjb21t YW5kLjwvdD4NCiAgICAgICAgPC9saXN0Pg0KICAgICAgPC90Pg0KICAgICAgPHQ+U2VydmVycyBz aG91bGQgbm90ZSB0aGF0IHRoZSByZXNwb25zZSB0byB0aGUgSE9TVCBjb21tYW5kIGlzIGEgc2Vu c2libGUgdGltZSB0byBzZW5kIHRoZWlyICJ3ZWxjb21lIiBtZXNzYWdlLiAgVGhpcyBhbGxvd3Mg dGhlIG1lc3NhZ2UgdG8gYmUgcGVyc29uYWxpemVkIGZvciBhbnkgdmlydHVhbCBob3N0cyB0aGF0 IGFyZSBzdXBwb3J0ZWQsIGFuZCBhbHNvIGFsbG93cyB0aGUgY2xpZW50IHRvIGRldGVybWluZSB0 aGUgc3VwcG9ydGVkIGxhbmd1YWdlcywgb3IgcmVwcmVzZW50YXRpb25zLCBmb3IgdGhlIG1lc3Nh Z2UsIGFuZCBvdGhlciBtZXNzYWdlcywgdmlhIHRoZSBGRUFUIHJlc3BvbnNlLCBhbmQgc2VsZWN0 IGFuIGFwcHJvcHJpYXRlIG9uZSB2aWEgdGhlIExBTkcgY29tbWFuZC4gIFNlZSA8eHJlZiB0YXJn ZXQ9IlJGQzI2NDAiIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCI+PC94cmVmPiBmb3Ig bW9yZSBpbmZvcm1hdGlvbi48L3Q+DQogICAgICA8c2VjdGlvbiB0aXRsZT0iU3ludGF4IG9mIHRo ZSBIT1NUIGNvbW1hbmQiIHRvYz0iZGVmYXVsdCI+DQogICAgICAgIDx0PlRoZSBIT1NUIGNvbW1h bmQgaXMgZGVmaW5lZCBhcyBmb2xsb3dzLjwvdD4NCiAgICAgICAgPHQ+DQogICAgICAgICAgPGZp Z3VyZSB0aXRsZT0iIiBzdXBwcmVzcy10aXRsZT0iZmFsc2UiIGFsaWduPSJsZWZ0IiBhbHQ9IiIg d2lkdGg9IiIgaGVpZ2h0PSIiPg0KICAgICAgICAgICAgPGFydHdvcmsgdHlwZT0iQUJORiIgeG1s OnNwYWNlPSJwcmVzZXJ2ZSIgbmFtZT0iIiBhbGlnbj0ibGVmdCIgYWx0PSIiIHdpZHRoPSIiIGhl aWdodD0iIj48IVtDREFUQVsgIGhvc3QtY29tbWFuZCAgPSAiSE9TVCIgU1AgaG9zdG5hbWUgQ1JM Rg0KICBob3N0bmFtZSAgICAgID0gZG9tYWluIC8gSVAtbGl0ZXJhbA0KDQogIGRvbWFpbiAgICAg ICAgPSBzdWItZG9tYWluICooIi4iIHN1Yi1kb21haW4pDQogIHN1Yi1kb21haW4gICAgPSBsZXQt ZGlnIFtsZGgtc3RyXQ0KICBsZXQtZGlnICAgICAgID0gQUxQSEEgLyBESUdJVA0KICBsZGgtc3Ry ICAgICAgID0gKiggQUxQSEEgLyBESUdJVCAvICItIiApIGxldC1kaWcNCg0KICBJUC1saXRlcmFs ICAgID0gKCAiWyIgSVB2NmFkZHJlc3MgIl0iICkgLyBJUHY0YWRkcmVzcw0KDQogIElQdjZhZGRy ZXNzICAgPSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDYoIGgxNiAiOiIgKSBsczMyDQog ICAgICAgICAgICAgICAgICAvICAgICAgICAgICAgICAgICAgICAgICAiOjoiIDUoIGgxNiAiOiIg KSBsczMyDQogICAgICAgICAgICAgICAgICAvIFsgICAgICAgICAgICAgICBoMTYgXSAiOjoiIDQo IGgxNiAiOiIgKSBsczMyDQogICAgICAgICAgICAgICAgICAvIFsgKjEoIGgxNiAiOiIgKSBoMTYg XSAiOjoiIDMoIGgxNiAiOiIgKSBsczMyDQogICAgICAgICAgICAgICAgICAvIFsgKjIoIGgxNiAi OiIgKSBoMTYgXSAiOjoiIDIoIGgxNiAiOiIgKSBsczMyDQogICAgICAgICAgICAgICAgICAvIFsg KjMoIGgxNiAiOiIgKSBoMTYgXSAiOjoiICAgIGgxNiAiOiIgICBsczMyDQogICAgICAgICAgICAg ICAgICAvIFsgKjQoIGgxNiAiOiIgKSBoMTYgXSAiOjoiICAgICAgICAgICAgICBsczMyDQogICAg ICAgICAgICAgICAgICAvIFsgKjUoIGgxNiAiOiIgKSBoMTYgXSAiOjoiICAgICAgICAgICAgICBo MTYNCiAgICAgICAgICAgICAgICAgIC8gWyAqNiggaDE2ICI6IiApIGgxNiBdICI6OiINCg0KICBs czMyICAgICAgICAgID0gKCBoMTYgIjoiIGgxNiApIC8gSVB2NGFkZHJlc3MNCiAgICAgICAgICAg ICAgICAgIDsgbGVhc3Qtc2lnbmlmaWNhbnQgMzIgYml0cyBvZiBhZGRyZXNzDQoNCiAgaDE2ICAg ICAgICAgICA9IDEqNEhFWERJRw0KICAgICAgICAgICAgICAgICAgOyAxNiBiaXRzIG9mIGFkZHJl c3MgcmVwcmVzZW50ZWQgaW4gaGV4YWRlY2ltYWwNCg0KICBJUHY0YWRkcmVzcyAgID0gZGVjLW9j dGV0ICIuIiBkZWMtb2N0ZXQgIi4iIGRlYy1vY3RldCAiLiIgZGVjLW9jdGV0DQoNCiAgZGVjLW9j dGV0ICAgICA9IERJR0lUICAgICAgICAgICAgICAgICA7IDAtOQ0KICAgICAgICAgICAgICAgICAg LyAleDMxLTM5IERJR0lUICAgICAgIDsgMTAtOTkNCiAgICAgICAgICAgICAgICAgIC8gIjEiIDJE SUdJVCAgICAgICAgICA7IDEwMC0xOTkNCiAgICAgICAgICAgICAgICAgIC8gIjIiICV4MzAtMzQg RElHSVQgICA7IDIwMC0yNDkNCiAgICAgICAgICAgICAgICAgIC8gIjI1IiAleDMwLTM1ICAgICAg ICA7IDI1MC0yNTUNCg0KICBob3N0LXJlc3BvbnNlID0gaG9zdC1vayAvIGVycm9yLXJlc3BvbnNl DQogIGhvc3Qtb2sgICAgICAgPSAiMjIwIiBbIFNQICpUQ0hBUiBdIENSTEZdXT48L2FydHdvcms+ DQogICAgICAgICAgPC9maWd1cmU+DQogICAgICAgIDwvdD4NCiAgICAgICAgPHQ+QXMgd2l0aCBh bGwgRlRQIGNvbW1hbmRzLCB0aGUgIkhPU1QiIGNvbW1hbmQgd29yZCBpcyBjYXNlIGluZGVwZW5k ZW50LCBhbmQgTUFZIGJlIHNwZWNpZmllZCBpbiBhbnkgY2hhcmFjdGVyIGNhc2UgZGVzaXJlZC48 L3Q+DQogICAgICAgIDx0PlRoZSAiaG9zdG5hbWUiIChnaXZlbiBhcyBhIHBhcmFtZXRlcikgc3Bl Y2lmaWVzIHRoZSB2aXJ0dWFsIGhvc3QgdG8gd2hpY2ggYWNjZXNzIGlzIGRlc2lyZWQuICBUaGlz IFNIT1VMRCBiZSB0aGUgc2FtZSBob3N0IG5hbWUgdGhhdCB3YXMgdXNlZCB0byBvYnRhaW4gdGhl IElQIGFkZHJlc3MgdG8gd2hpY2ggdGhlIEZUUCBjb250cm9sIGNvbm5lY3Rpb24gd2FzIG1hZGUs IGFmdGVyIGFueSBjbGllbnQgY29udmVyc2lvbnMgaGF2ZSBiZWVuIGNvbXBsZXRlZCB0aGF0IGNv bnZlcnQgYW4gYWJicmV2aWF0ZWQgb3IgbG9jYWwgYWxpYXMgdG8gYSBjb21wbGV0ZSAoZnVsbHkg cXVhbGlmaWVkKSBkb21haW4gbmFtZSwgYnV0IGJlZm9yZSByZXNvbHZpbmcgYSBETlMgYWxpYXMg KG93bmVyIG9mIGEgQ05BTUUgcmVzb3VyY2UgcmVjb3JkKSB0byBpdHMgY2Fub25pY2FsIG5hbWUu PC90Pg0KICAgICAgICA8dD5JbnRlcm5hdGlvbmFsaXphdGlvbiBvZiBkb21haW4gbmFtZXMgaXMg b25seSBzdXBwb3J0ZWQgdGhyb3VnaCB0aGUgdXNlIG9mIFB1bnljb2RlIGFzIGRlc2NyaWJlZCBp biA8eHJlZiB0YXJnZXQ9IlJGQzM0OTIiIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIg Lz4uPC90Pg0KICAgICAgICA8dD5JZiB0aGUgdXNlciB3YXMgZ2l2ZW4gYW4gSVB2NCBvciBJUHY2 IGxpdGVyYWwgYWRkcmVzcywgYW5kIGNvbnNlcXVlbnRseSB3YXMgbm90IHJlcXVpcmVkIHRvIGRl cml2ZSB0aGUgbGl0ZXJhbCBhZGRyZXNzIGZyb20gYSBob3N0bmFtZSwgdGhlIGNsaWVudCBNQVkg c2VuZCB0aGUgSE9TVCBjb21tYW5kIHdpdGggdGhlIElQdjQgb3IgSVB2NiBsaXRlcmFsIGFkZHJl c3MgYXMgc3BlY2lmaWVkIHRvIGl0LiAgV2hpbGUgaXQgbWF5IHNlZW0gY291bnRlci1pbnR1aXRp dmUgdG8gc3BlY2lmeSBhIGxpdGVyYWwgYWRkcmVzcyBieSB1c2luZyB0aGUgSE9TVCBjb21tYW5k IGFmdGVyIHRoZSBjbGllbnQgaGFzIGFscmVhZHkgY29ubmVjdGVkIHRvIHRoZSBzZXJ2ZXIgdXNp bmcgYSBsaXRlcmFsIGFkZHJlc3MsIHRoaXMgc2hvdWxkIGJlIGV4cGVjdGVkIGJlaGF2aW9yIGJl Y2F1c2UgYSB1c2VyLUZUUCBwcm9jZXNzIHNob3VsZCBub3QgYmUgcmVxdWlyZWQgdG8gZGlmZmVy ZW50aWF0ZSBiZXR3ZWVuIGEgZnVsbHkgcXVhbGlmaWVkIGRvbWFpbiBuYW1lIGFuZCBhbiBJUHY0 IG9yIElQdjYgbmV0d29yayBsaXRlcmFsIGFkZHJlc3MuICBUaGF0IGJlaW5nIHNhaWQsIGlmIHRo ZSBJUHY0IG9yIElQdjYgbGl0ZXJhbCBhZGRyZXNzIHNwZWNpZmllZCBieSB0aGUgY2xpZW50IGRv ZXMgbm90IG1hdGNoIHRoZSBsaXRlcmFsIGFkZHJlc3MgZm9yIHRoZSBzZXJ2ZXIsIHRoZSBzZXJ2 ZXIgTVVTVCByZXNwb25kIHdpdGggYSA1MDQgcmVwbHkgdG8gaW5kaWNhdGUgdGhhdCB0aGUgSVB2 NCBvciBJUHY2IGxpdGVyYWwgYWRkcmVzcyBpcyBub3QgdmFsaWQuPC90Pg0KICAgICAgICA8dD5X aGVuIHRoZSBob3N0bmFtZSBwYXJhbWV0ZXIgY29udGFpbnMgYSBsaXRlcmFsIGFkZHJlc3MsIHNx dWFyZSBicmFja2V0cyBhcmUgZXhwZWN0ZWQgdG8gZGlzYW1iaWd1YXRlIElQdjYgYWRkcmVzcyBz eW50YXggZnJvbSBwb3J0IG51bWJlcnMgc3ludGF4LiAgVGhlcmVmb3JlLCBpZiB0aGUgbGl0ZXJh bCBhZGRyZXNzIGlzIGFuIElQdjYgYWRkcmVzcywgdGhlIElQdjYgYWRkcmVzcyBpcyByZXF1aXJl ZCB0byBiZSBlbmNsb3NlZCBpbiBzcXVhcmUgYnJhY2tldHMgKGFmdGVyIGVsaW1pbmF0aW5nIGFu eSBzeW50YXggdGhhdCBtaWdodCBhbHNvIC0gYnV0IGlzIG5vdCByZXF1aXJlZCB0byAtIGJlIGVu Y2xvc2VkIGluIGJyYWNrZXRzLCBhbmQgZnJvbSB3aGljaCB0aGUgc2VydmVyIGRlZHVjZWQgdGhh dCBhIGxpdGVyYWwgYWRkcmVzcyBoYWQgYmVlbiBzcGVjaWZpZWQuKSBGb3IgZXhhbXBsZSwgdGhl IGZvbGxvd2luZyBleGFtcGxlcyBNQVkgYmUgc2VudCBpZiB0aGUgY2xpZW50IGhhZCBiZWVuIGlu c3RydWN0ZWQgdG8gcmVzcGVjdGl2ZWx5IGNvbm5lY3QgdG8gIjE5Mi4wLjIuMSIsICJGRTgwOjpj MDAwOjAyMDEiLCBvciAiMTkyLjAuMi4xIiBhbmQgSVB2NiBzeW50YXggaXMgcHJlZmVycmVkOjwv dD4NCiAgICAgICAgPHQ+DQogICAgICAgICAgPGZpZ3VyZSB0aXRsZT0iIiBzdXBwcmVzcy10aXRs ZT0iZmFsc2UiIGFsaWduPSJsZWZ0IiBhbHQ9IiIgd2lkdGg9IiIgaGVpZ2h0PSIiPg0KICAgICAg ICAgICAgPGFydHdvcmsgeG1sOnNwYWNlPSJwcmVzZXJ2ZSIgbmFtZT0iIiB0eXBlPSIiIGFsaWdu PSJsZWZ0IiBhbHQ9IiIgd2lkdGg9IiIgaGVpZ2h0PSIiPjwhW0NEQVRBWyAgICAgSE9TVCAxOTIu MC4yLjENCiAgICAgSE9TVCBbRkU4MDo6YzAwMDowMjAxXQ0KICAgICBIT1NUIFs6OjE5Mi4wLjIu MV1dXT48L2FydHdvcms+DQogICAgICAgICAgPC9maWd1cmU+DQogICAgICAgIDwvdD4NCiAgICAg ICAgPHQ+VGhlIGNsaWVudCBNVVNUIE5PVCBzZW5kIHRoZSBwb3J0IG51bWJlciBhcyBwYXJ0IG9m IHRoZSBIT1NUIGNvbW1hbmQsIGV2ZW4gd2hlbiB0aGUgY2xpZW50IGhhcyBiZWVuIGluc3RydWN0 ZWQgdG8gY29ubmVjdCB0byBhIG5vbi1zdGFuZGFyZCBwb3J0LiAgVGhlIHJlYXNvbiBmb3IgdGhp cyByZXF1aXJlbWVudCBpcyB0aGF0IHRoZSB1c2VyLVBJIHdpbGwgaGF2ZSBlc3RhYmxpc2hlZCBh IGNvbm5lY3Rpb24gdG8gdGhlIHNlcnZlci1QSSBiZWZvcmUgdGhlIEhPU1QgY29tbWFuZCBpcyBz ZW50LCB0aGVyZWZvcmUgc3BlY2lmeWluZyBhIGRpZmZlcmVudCBwb3J0IHdpdGggdGhlIEhPU1Qg Y29tbWFuZCBoYXMgbm8gbWVhbmluZy4gIEZvciBleGFtcGxlLCB0aGUgc2VydmVyLVBJIE1VU1Qg cmVzcG9uZCB3aXRoIGEgNTAxIHJlcGx5IGlmIHRoZSBjbGllbnQgc2VuZHMgYSBIT1NUIGNvbW1h bmQgd2l0aCBzeW50YXggbGlrZSBlaXRoZXIgb2YgdGhlIGZvbGxvd2luZyBleGFtcGxlczo8L3Q+ DQogICAgICAgIDx0Pg0KICAgICAgICAgIDxmaWd1cmUgdGl0bGU9IiIgc3VwcHJlc3MtdGl0bGU9 ImZhbHNlIiBhbGlnbj0ibGVmdCIgYWx0PSIiIHdpZHRoPSIiIGhlaWdodD0iIj4NCiAgICAgICAg ICAgIDxhcnR3b3JrIHhtbDpzcGFjZT0icHJlc2VydmUiIG5hbWU9IiIgdHlwZT0iIiBhbGlnbj0i bGVmdCIgYWx0PSIiIHdpZHRoPSIiIGhlaWdodD0iIj48IVtDREFUQVsgICAgIEhPU1QgMTkyLjAu Mi4xOjIxMTINCiAgICAgSE9TVCBbRkU4MDo6YzAwMDowMjAxXToyMTEyXV0+PC9hcnR3b3JrPg0K ICAgICAgICAgIDwvZmlndXJlPg0KICAgICAgICA8L3Q+DQogICAgICAgIDx0PlRoZSBob3N0bmFt ZSBwYXJhbWV0ZXIgaXMgb3RoZXJ3aXNlIHRvIGJlIHRyZWF0ZWQgYXMgYSBmdWxseSBxdWFsaWZp ZWQgZG9tYWluIG5hbWUgb3IgcmVsYXRpdmUgbmFtZSBhcyB0aG9zZSB0ZXJtcyBhcmUgZGVmaW5l ZCBpbiBzZWN0aW9uIDMuMSBvZiA8eHJlZiB0YXJnZXQ9IlJGQzEwMzQiIHBhZ2Vubz0iZmFsc2Ui IGZvcm1hdD0iZGVmYXVsdCIgLz4uICBUaGlzIGltcGxpZXMgdGhhdCB0aGUgbmFtZSBpcyB0byBi ZSB0cmVhdGVkIGFzIGEgY2FzZS1pbmRlcGVuZGVudCBzdHJpbmcsIG1lYW5pbmcgdGhhdCB1cHBl cmNhc2UgQVNDSUkgY2hhcmFjdGVycyBhcmUgdG8gYmUgdHJlYXRlZCBhcyBlcXVpdmFsZW50IHRv IHRoZWlyIGNvcnJlc3BvbmRpbmcgbG93ZXJjYXNlIEFTQ0lJIGNoYXJhY3RlcnMsIGJ1dCBvdGhl cndpc2UgcHJlc2VydmVkIGFzIGdpdmVuLiAgSXQgYWxzbyBpbXBsaWVzIHNvbWUgbGltaXRzIG9u IHRoZSBsZW5ndGggb2YgdGhlIHBhcmFtZXRlciBhbmQgb2YgdGhlIGNvbXBvbmVudHMgdGhhdCBj cmVhdGUgaXRzIGludGVybmFsIHN0cnVjdHVyZS4gIFRob3NlIGxpbWl0cyBhcmUgbm90IGFsdGVy ZWQgaW4gYW55IHdheSBoZXJlLjwvdD4NCiAgICAgICAgPHQ+TmVpdGhlciA8eHJlZiB0YXJnZXQ9 IlJGQzEwMzQiIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIgLz4gbm9yIDx4cmVmIHRh cmdldD0iUkZDMTAzNSIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0IiAvPiBpbXBvc2Ug YW55IG90aGVyIHJlc3RyaWN0aW9ucyB1cG9uIHdoYXQga2luZHMgb2YgbmFtZXMgY2FuIGJlIHN0 b3JlZCBpbiB0aGUgRE5TLiAgVGhpcyBzcGVjaWZpY2F0aW9uLCBob3dldmVyLCBvbmx5IGFsbG93 cyB0aGUgdXNlIG9mIG5hbWVzIHRoYXQgY2FuIGJlIGluZmVycmVkIGZyb20gdGhlIEFCTkYgZ3Jh bW1hciBnaXZlbiBmb3IgdGhlICJob3N0bmFtZSIuPC90Pg0KICAgICAgPC9zZWN0aW9uPg0KICAg ICAgPHNlY3Rpb24gdGl0bGU9IkhPU1QgY29tbWFuZCBzZW1hbnRpY3MiIHRvYz0iZGVmYXVsdCI+ DQogICAgICAgIDx0PlVwb24gcmVjZWl2aW5nIHRoZSBIT1NUIGNvbW1hbmQsIGJlZm9yZSBhdXRo ZW50aWNhdGluZyB0aGUgdXNlci1QSSwgYSBzZXJ2ZXItRlRQIHByb2Nlc3MgU0hPVUxEIHZhbGlk YXRlIHRoYXQgdGhlIGhvc3RuYW1lIGdpdmVuIHJlcHJlc2VudHMgYSB2YWxpZCB2aXJ0dWFsIGhv c3QgZm9yIHRoYXQgc2VydmVyLCBhbmQsIGlmIGl0IGlzIHZhbGlkLCBlc3RhYmxpc2ggdGhlIGFw cHJvcHJpYXRlIGVudmlyb25tZW50IGZvciB0aGF0IHZpcnR1YWwgaG9zdC4gIFRoZSByZXN1bHRh bnQgYWN0aW9ucyBuZWVkZWQgdG8gY3JlYXRlIHRoYXQgZW52aXJvbm1lbnQgYXJlIG5vdCBzcGVj aWZpZWQgaGVyZSwgYW5kIG1heSByYW5nZSBmcm9tIGRvaW5nIG5vdGhpbmcgYXQgYWxsLCB0byBw ZXJmb3JtaW5nIGEgc2ltcGxlIGNoYW5nZSBvZiB3b3JraW5nIGRpcmVjdG9yeSwgY2hhbmdpbmcg YXV0aGVudGljYXRpb24gc2NoZW1lcyBhbmQvb3IgdXNlcm5hbWUgYW5kIHBhc3N3b3JkIGxpc3Rz LCBvciBtYWtpbmcgbXVjaCBtb3JlIGVsYWJvcmF0ZSBzdGF0ZSBjaGFuZ2VzIC0gc3VjaCBhcyBj cmVhdGluZyBpc29sYXRlZCBlbnZpcm9ubWVudHMgZm9yIGVhY2ggRlRQIHNlc3Npb24uPC90Pg0K ICAgICAgICA8dD5UaGUgIjIyMCIgcmVwbHkgY29kZSBmb3IgdGhlIEhPU1QgY29tbWFuZCBpcyB0 aGUgc2FtZSBhcyB0aGUgY29kZSB0aGF0IGlzIHVzZWQgaW4gdGhlIGluaXRpYWwgIndlbGNvbWUi IG1lc3NhZ2UgdGhhdCBpcyBzZW50IGFmdGVyIHRoZSBjb25uZWN0aW9uIGlzIGVzdGFibGlzaGVk LiAgVGhpcyByZXBseSBjb2RlIGlzIHVzZWQgZGVsaWJlcmF0ZWx5IGluIG9yZGVyIHRvIGFsbG93 IHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBhIGZyb250LWVuZCBGVFAgc2VydmVyIGFzIGEgd3JhcHBl ciwgd2hpY2ggc2ltcGx5IHdhaXRzIGZvciB0aGUgSE9TVCBjb21tYW5kLCBhbmQgdGhlbiBpbnZv a2VzIGEgc2VydmVyIHRoYXQgaXMgY29tcGxpYW50IHdpdGggPHhyZWYgdGFyZ2V0PSJSRkMwOTU5 IiBwYWdlbm89ImZhbHNlIiBmb3JtYXQ9ImRlZmF1bHQiIC8+IGluIHRoZSBhcHByb3ByaWF0ZSBl bnZpcm9ubWVudCBmb3IgdGhlIHBhcnRpY3VsYXIgaG9zdG5hbWUgcmVjZWl2ZWQuPC90Pg0KICAg ICAgICA8dD5JZiB0aGUgaG9zdG5hbWUgc3BlY2lmaWVkIHdvdWxkIG5vcm1hbGx5IGJlIGFjY2Vw dGFibGUsIGJ1dCBmb3IgYW55IHJlYXNvbiBpcyB0ZW1wb3JhcmlseSB1bmF2YWlsYWJsZSwgdGhl IHNlcnZlci1GVFAgcHJvY2VzcyBTSE9VTEQgcmVwbHkgdG8gdGhlIEhPU1QgY29tbWFuZCB3aXRo IGEgNDIxIHJlcGx5IGFuZCBjbG9zZSB0aGUgY29ubmVjdGlvbi4gIEluIHRoaXMgcGFydGljdWxh ciBzaXR1YXRpb24sIHRoZSBzZXJ2ZXItRlRQIHByb2Nlc3MgTUFZIGNob29zZSB0byBrZWVwIHRo ZSBjb25uZWN0aW9uIG9wZW4gaW4gb3JkZXIgdG8gYWxsb3cgdGhlIHVzZXItUEkgYW4gb3Bwb3J0 dW5pdHkgdG8gY2hvb3NlIGFub3RoZXIgdmlydHVhbCBob3N0IHdpdGggYSBzdWJzZXF1ZW50IEhP U1QgY29tbWFuZC48L3Q+DQogICAgICAgIDx0PklmIHRoZSBob3N0bmFtZSBzcGVjaWZpZWQgaXMg dW5rbm93biBhdCB0aGUgc2VydmVyLCBvciBpZiB0aGUgc2VydmVyIGlzIG90aGVyd2lzZSB1bndp bGxpbmcgdG8gdHJlYXQgdGhlIHBhcnRpY3VsYXIgY29ubmVjdGlvbiBhcyBhIGNvbm5lY3Rpb24g dG8gdGhlIGhvc3RuYW1lIHNwZWNpZmllZCwgdGhlIHNlcnZlciBTSE9VTEQgcmVzcG9uZCB3aXRo IGEgNTA0IHJlcGx5LjwvdD4NCiAgICAgICAgPHNlY3Rpb24gdGl0bGU9IlJFSU4gY29tbWFuZCBz ZW1hbnRpY3MiIHRvYz0iZGVmYXVsdCI+DQogICAgICAgICAgPHQ+QXMgc3BlY2lmaWVkIGluIDx4 cmVmIHRhcmdldD0iUkZDMDk1OSIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0IiAvPiwg dGhlIFJFSU4gY29tbWFuZCByZXR1cm5zIHRoZSBzdGF0ZSBvZiB0aGUgY29ubmVjdGlvbiB0byB3 aGF0IGl0IHdhcyBpbW1lZGlhdGVseSBhZnRlciB0aGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gd2Fz IG9wZW5lZC4gIFRoaXMgc3BlY2lmaWNhdGlvbiBtYWtlcyBubyBjaGFuZ2VzIHRvIHRoYXQgYmVo YXZpb3IuICBUaGUgZWZmZWN0IG9mIGEgSE9TVCBjb21tYW5kIE1VU1QgYmUgcmVzZXQgaWYgYSBS RUlOIGNvbW1hbmQgaXMgcGVyZm9ybWVkLCBhbmQgYSBuZXcgSE9TVCBjb21tYW5kIE1VU1QgYmUg aXNzdWVkIGluIG9yZGVyIHRvIGNvbm5lY3QgdG8gYSB2aXJ0dWFsIGhvc3QuPC90Pg0KICAgICAg ICA8L3NlY3Rpb24+DQogICAgICAgIDxzZWN0aW9uIHRpdGxlPSJVc2VyLVBJIHVzYWdlIG9mIEhP U1QiIHRvYz0iZGVmYXVsdCI+DQogICAgICAgICAgPHQ+QSB1c2VyLVBJIHRoYXQgY29uZm9ybXMg dG8gdGhpcyBzcGVjaWZpY2F0aW9uIE1VU1Qgc2VuZCB0aGUgSE9TVCBjb21tYW5kIGFmdGVyIG9w ZW5pbmcgdGhlIHRyYW5zcG9ydCBjb25uZWN0aW9uLCBvciBhZnRlciBhbnkgUkVJTiBjb21tYW5k LCBiZWZvcmUgYXR0ZW1wdGluZyB0byBhdXRoZW50aWNhdGUgdGhlIHVzZXIgd2l0aCB0aGUgVVNF UiBjb21tYW5kLiAgVGhlIGZvbGxvd2luZyBleGFtcGxlIGlsbHVzdHJhdGVzIHdoYXQgYSB0eXBp Y2FsIGxvZ2luIHNlcXVlbmNlIG1pZ2h0IGxvb2sgbGlrZSB3aGVuIHRoZSBIT1NUIGNvbW1hbmQg aXMgdXNlZDo8L3Q+DQogICAgICAgICAgPHQ+DQogICAgICAgICAgICA8ZmlndXJlIHRpdGxlPSIi IHN1cHByZXNzLXRpdGxlPSJmYWxzZSIgYWxpZ249ImxlZnQiIGFsdD0iIiB3aWR0aD0iIiBoZWln aHQ9IiI+DQogICAgICAgICAgICAgIDxhcnR3b3JrIHhtbDpzcGFjZT0icHJlc2VydmUiIG5hbWU9 IiIgdHlwZT0iIiBhbGlnbj0ibGVmdCIgYWx0PSIiIHdpZHRoPSIiIGhlaWdodD0iIj48IVtDREFU QVsgICAgIEM+IEhPU1QgZnRwLmV4YW1wbGUuY29tDQogICAgIFM+IDIyMCBIb3N0IGFjY2VwdGVk DQogICAgIEM+IFVTRVIgZm9vDQogICAgIFM+IDMzMSBQYXNzd29yZCByZXF1aXJlZA0KICAgICBD PiBQQVNTIGJhcg0KICAgICBTPiAyMzAgVXNlciBsb2dnZWQgaW5dXT48L2FydHdvcms+DQogICAg ICAgICAgICA8L2ZpZ3VyZT4NCiAgICAgICAgICA8L3Q+DQogICAgICAgICAgPHQ+VGhlIEhPU1Qg Y29tbWFuZCBjYW4gYmUgdXNlZCBpbiBjb21iaW5hdGlvbiB3aXRoIHRoZSBBQ0NUIGNvbW1hbmQg dG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIGEgdXNlcidzIHZhcmlvdXMgYWNjb3VudHMgb24gYSBz cGVjaWZpYyB2aXJ0dWFsIGhvc3QuICBJbiB0aGlzIHNjZW5hcmlvLCB0aGUgdXNlci1QSSBzZW5k cyBhIEhPU1QgY29tbWFuZCB3aGljaCB0aGUgc2VydmVyLVBJIHVzZXMgdG8gcm91dGUgYWN0aXZp dHkgdG8gdGhlIGNvcnJlY3QgdmlydHVhbCBob3N0OyB0aGUgdXNlci1QSSBzZW5kcyBjcmVkZW50 aWFscyB1c2luZyB0aGUgVVNFUiBhbmQgUEFTUyBjb21tYW5kcyB3aGljaCB0aGUgc2VydmVyLVBJ IHZhbGlkYXRlczsgdGhlbiwgdGhlIHVzZXItUEkgc2VuZHMgYW4gQUNDVCBjb21tYW5kIHRvIHNw ZWNpZnkgYW55IGFkZGl0aW9uYWwgYWNjb3VudCBpbmZvcm1hdGlvbiBmb3IgdGhlIHNlcnZlci1Q SSBpbXBsZW1lbnRhdGlvbi4gIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBpbGx1c3RyYXRlcyBhIHNl cXVlbnRpYWwgc2VyaWVzIG9mIGNsaWVudCBjb21tYW5kcyB0aGF0IHNwZWNpZnkgYm90aCBhIEhP U1QgYW5kIEFDQ1QsIHdpdGggdGhlIHNlcnZlciByZXNwb25zZXMgb21pdHRlZCBmb3IgYnJldml0 eTo8L3Q+DQogICAgICAgICAgPHQ+DQogICAgICAgICAgICA8ZmlndXJlIHRpdGxlPSIiIHN1cHBy ZXNzLXRpdGxlPSJmYWxzZSIgYWxpZ249ImxlZnQiIGFsdD0iIiB3aWR0aD0iIiBoZWlnaHQ9IiI+ DQogICAgICAgICAgICAgIDxhcnR3b3JrIHhtbDpzcGFjZT0icHJlc2VydmUiIG5hbWU9IiIgdHlw ZT0iIiBhbGlnbj0ibGVmdCIgYWx0PSIiIHdpZHRoPSIiIGhlaWdodD0iIj48IVtDREFUQVsgICAg IEM+IEhPU1QgZnRwLmV4YW1wbGUuY29tDQogICAgIEM+IFVTRVIgZm9vDQogICAgIEM+IFBBU1Mg YmFyDQogICAgIEM+IEFDQ1QgcHJvamVjdDFdXT48L2FydHdvcms+DQogICAgICAgICAgICA8L2Zp Z3VyZT4NCiAgICAgICAgICA8L3Q+DQogICAgICAgICAgPHQ+VGhpcyBpcyBhbHNvIHRydWUgd2hl biB0aGUgSE9TVCBjb21tYW5kIGlzIHVzZWQgd2l0aCB0aGUgQVVUSCBhbmQgQURBVCBjb21tYW5k cyB0aGF0IGFyZSBkaXNjdXNzZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkMyMjI4IiBwYWdlbm89ImZh bHNlIiBmb3JtYXQ9ImRlZmF1bHQiIC8+IGFuZCA8eHJlZiB0YXJnZXQ9IlJGQzQyMTciIHBhZ2Vu bz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIgLz4uICBJbiB0aGlzIHNjZW5hcmlvLCB0aGUgdXNl ci1QSSBzZW5kcyBhIEhPU1QgY29tbWFuZCB3aGljaCB0aGUgc2VydmVyLVBJIHVzZXMgdG8gcm91 dGUgYWN0aXZpdHkgdG8gdGhlIGNvcnJlY3QgdmlydHVhbCBob3N0LCB0aGVuIHRoZSB1c2VyLVBJ IHVzZXMgdGhlIEFVVEggYW5kIEFEQVQgY29tbWFuZHMgdG8gbmVnb3RpYXRlIHRoZSBzZWN1cml0 eSBtZWNoYW5pc20gYW5kIGNlcnRpZmljYXRlIHdpdGggdGhlIHNlcnZlci1QSSwgdGhlbiB0aGUg dXNlci1QSSBzZW5kcyB1c2VyIGNyZWRlbnRpYWxzIHVzaW5nIHRoZSBVU0VSIGFuZCBQQVNTIGNv bW1hbmRzIHdoaWNoIHRoZSBzZXJ2ZXItUEkgdmFsaWRhdGVzLiAgQWZ0ZXIgd2hpY2ggdGhlIHVz ZXItUEkgTUFZIHNlbmQgYW4gQUNDVCBjb21tYW5kIHRvIHNwZWNpZnkgYW55IGFkZGl0aW9uYWwg YWNjb3VudCBpbmZvcm1hdGlvbiBmb3IgdGhlIHNlcnZlci1QSSBpbXBsZW1lbnRhdGlvbi4gIFRo ZSBmb2xsb3dpbmcgZXhhbXBsZSBpbGx1c3RyYXRlcyBhIHNlcXVlbnRpYWwgc2VyaWVzIG9mIGNs aWVudCBjb21tYW5kcyB0aGF0IHNwZWNpZnkgYm90aCBhIEhPU1QgYW5kIEFDQ1Qgd2hlbiB1c2Vk IGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIHNlY3VyaXR5IGNvbW1hbmRzIHRoYXQgYXJlIGRpc2N1 c3NlZCBpbiA8eHJlZiB0YXJnZXQ9IlJGQzIyMjgiIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVm YXVsdCIgLz4gYW5kIDx4cmVmIHRhcmdldD0iUkZDNDIxNyIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0 PSJkZWZhdWx0IiAvPiwgd2l0aCB0aGUgc2VydmVyIHJlc3BvbnNlcyBvbWl0dGVkIGZvciBicmV2 aXR5OjwvdD4NCiAgICAgICAgICA8dD4NCiAgICAgICAgICAgIDxmaWd1cmUgdGl0bGU9IiIgc3Vw cHJlc3MtdGl0bGU9ImZhbHNlIiBhbGlnbj0ibGVmdCIgYWx0PSIiIHdpZHRoPSIiIGhlaWdodD0i Ij4NCiAgICAgICAgICAgICAgPGFydHdvcmsgeG1sOnNwYWNlPSJwcmVzZXJ2ZSIgbmFtZT0iIiB0 eXBlPSIiIGFsaWduPSJsZWZ0IiBhbHQ9IiIgd2lkdGg9IiIgaGVpZ2h0PSIiPjwhW0NEQVRBWyAg ICAgQz4gSE9TVCBmdHAuZXhhbXBsZS5jb20NCiAgICAgQz4gQVVUSCA8bWVjaGFuaXNtLW5hbWU+ DQogICAgIEM+IEFEQVQgPGJhc2U2NGRhdGE+DQogICAgIEM+IFVTRVIgZm9vDQogICAgIEM+IFBB U1MgYmFyDQogICAgIEM+IEFDQ1QgcHJvamVjdDFdXT48L2FydHdvcms+DQogICAgICAgICAgICA8 L2ZpZ3VyZT4NCiAgICAgICAgICA8L3Q+DQogICAgICAgIDwvc2VjdGlvbj4NCiAgICAgICAgPHNl Y3Rpb24gdGl0bGU9IlN0YXRlIERpYWdyYW1zIiB0b2M9ImRlZmF1bHQiPg0KICAgICAgICAgIDx0 PlRoZSBzdGF0ZSBkaWFncmFtcyBpbiB0aGlzIHNlY3Rpb24gaWxsdXN0cmF0ZSB0eXBpY2FsIHNl cXVlbmNlcyBmb3IgY29tbWFuZCBhbmQgcmVwbHkgaW50ZXJjaGFuZ2UgYmV0d2VlbiB0aGUgdXNl ci1QSSBhbmQgc2VydmVyLVBJLiAgVGhlc2UgZGlhZ3JhbXMgYXJlIG1vZGVsZWQgb24gdGhlIHNp bWlsYXIgZGlhZ3JhbXMgaW4gc2VjdGlvbiA2IG9mIDx4cmVmIHRhcmdldD0iUkZDMDk1OSIgcGFn ZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0IiAvPi48L3Q+DQogICAgICAgICAgPHQ+SW4gZWFj aCBkaWFncmFtLCB0aGUgKEIpICJiZWdpbiIgc3RhdGUgaXMgYXNzdW1lZCB0byBvY2N1ciBhZnRl ciB0aGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gaGFzIG9wZW5lZCwgb3IgYWZ0ZXIgYSBSRUlOIGNv bW1hbmQgaGFzIHN1Y2NlZWRlZC4gIE90aGVyIGNvbW1hbmRzIChzdWNoIGFzIEZFQVQgPHhyZWYg dGFyZ2V0PSJSRkMyMzg5IiBwYWdlbm89ImZhbHNlIiBmb3JtYXQ9ImRlZmF1bHQiIC8+KSB0aGF0 IHJlcXVpcmUgbm8gYXV0aGVudGljYXRpb24gbWF5IGhhdmUgaW50ZXJ2ZW5lZC48L3Q+DQogICAg ICAgICAgPHQ+QWRkaXRpb25hbGx5LCBhIHRocmVlLWRpZ2l0IHJlcGx5IGluZGljYXRlcyBhIHBy ZWNpc2Ugc2VydmVyIHJlcGx5IGNvZGUuICBBIHNpbmdsZSBkaWdpdCBvbiBhIHJlcGx5IHBhdGgg aW5kaWNhdGVzIGFueSBzZXJ2ZXIgcmVwbHkgdGhhdCBiZWdpbnMgd2l0aCB0aGF0IGRpZ2l0LCBl eGNlcHQgd2hlcmUgYSBwcmVjaXNlIHNlcnZlciByZXBseSBjb2RlIGlzIGRlZmluZWQgb24gYW5v dGhlciBwYXRoLiAgRm9yIGV4YW1wbGUsIGEgc2luZ2xlIGRpZ2l0ICI1IiB3aWxsIGFwcGx5IHRv ICI1MDAiLCAiNTAxIiwgIjUwMiIsIGV0Yy4sIHdoZW4gdGhvc2UgcmVwbHkgY29kZXMgYXJlIG5v dCBleHByZXNzbHkgZGVmaW5lZCBpbiB0aGUgZGlhZ3JhbS4gIEZvciBlYWNoIGNvbW1hbmQgdGhl cmUgYXJlIHRocmVlIHBvc3NpYmxlIG91dGNvbWVzOiBzdWNjZXNzIChTKSwgZmFpbHVyZSAoRiks IGFuZCBlcnJvciAoRSkuICBJbiB0aGUgc3RhdGUgZGlhZ3JhbXMgYmVsb3cgd2UgdXNlIHRoZSBz eW1ib2wgQiBmb3IgImJlZ2luIiwgYW5kIHRoZSBzeW1ib2wgVyBmb3IgIndhaXQgZm9yIHJlcGx5 Ii48L3Q+DQogICAgICAgICAgPHQ+SW4gZWFjaCBvZiB0aGVzZSBkaWFncmFtcywgYSBSRUlOIGNv bW1hbmQgd2lsbCByZXR1cm4gdGhlIGRpYWdyYW0gdG8gdGhlIChCKSAiYmVnaW4iIHN0YXRlLjwv dD4NCiAgICAgICAgICA8dD4NCiAgICAgICAgICAgIDxmaWd1cmUgdGl0bGU9IkZpZ3VyZSAxOiBU eXBpY2FsIGxvZ2luIHNlcXVlbmNlIHdpdGggSE9TVCBjb21tYW5kIiBzdXBwcmVzcy10aXRsZT0i ZmFsc2UiIGFsaWduPSJsZWZ0IiBhbHQ9IiIgd2lkdGg9IiIgaGVpZ2h0PSIiPg0KICAgICAgICAg ICAgICA8cHJlYW1ibGU+VGhlIHN0YXRlIGRpYWdyYW0gaW4gRmlndXJlIDEgc2hvd3MgYSB0eXBp Y2FsIHNlcXVlbmNlIG9mIGZsb3cgb2YgY29udHJvbCB3aGVuIEhPU1QgaXMgdXNlZCB3aXRoIFVT RVIgYW5kIFBBU1MgdG8gbG9nIGluIHRvIGEgcGFydGljdWxhciBGVFAgdmlydHVhbCBob3N0Ljwv cHJlYW1ibGU+DQogICAgICAgICAgICAgIDxhcnR3b3JrIHhtbDpzcGFjZT0icHJlc2VydmUiIG5h bWU9IiIgdHlwZT0iIiBhbGlnbj0ibGVmdCIgYWx0PSIiIHdpZHRoPSIiIGhlaWdodD0iIj48IVtD REFUQVsNCiAgICAgICAgICAgKy0tLSsgICBIT1NUICAgICstLS0rIDEsMyw1DQogICAgICAgICAg IHwgQiB8LS0tLS0tLS0tLT58IFcgfC0tLS0tLS0tLS0tLS0tLS0tDQogICAgICAgICAgICstLS0r ICAgICAgICAgICArLS0tKyAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgfCAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgIDIsNTAwLDUw MiB8IHwgNCw1MDEsNTAzLDUwNCAgICB8DQogICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tICAg LS0tLS0tLS0tLS0tICAgICAgfA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgIHwNCiAgICAgICAgICAgICBWICAgICAgICAgICAgICAgICAgIDEgICAgICAg ICB8ICAgICBWDQogICAgICAgICAgICstLS0rICAgVVNFUiAgICArLS0tKy0tLS0tLS0tLS0tLS0t PistLS0rDQogICAgICAgICAgIHwgICB8LS0tLS0tLS0tLT58IFcgfCAyICAgICAgICAgfCAgIHwg RSB8DQogICAgICAgICAgICstLS0rICAgICAgICAgICArLS0tKy0tLS0tLSAgIC0tLS0tPistLS0r DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB8ICAgICAgIHwgfCAgfA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAzIHwgfCA0LDUgICB8IHwgIHwNCiAgICAgICAgICAgICAgLS0tLS0t LS0tLS0tLS0gICAtLS0tLSAgfCB8ICB8DQogICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICB8IHwgfCAgfA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgLS0tLS0tLS0tLSAg IHwNCiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAxfCAgICAgIHwgfCAgICB8DQogICAgICAg ICAgICAgViAgICAgICAgICAgICAgIHwgICAgICB8ICAtLS0tLS0tPistLS0rDQogICAgICAgICAg ICstLS0rICAgUEFTUyAgICArLS0tKyAyICB8ICAgICAgfCAgIHwgUyB8DQogICAgICAgICAgIHwg ICB8LS0tLS0tLS0tLT58IFcgfC0tLS0tLS0tLS0tLS0tPistLS0rDQogICAgICAgICAgICstLS0r ICAgICAgICAgICArLS0tKyAgICB8ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgfCAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDQsNSAgIHwg ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICAgICAgIC0tPist LS0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgLS0tLS0tLS0tPnwgRiB8 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLS0tPistLS0rXV0+ PC9hcnR3b3JrPg0KICAgICAgICAgICAgPC9maWd1cmU+DQogICAgICAgICAgPC90Pg0KICAgICAg ICAgIDx0Pg0KICAgICAgICAgICAgPGZpZ3VyZSB0aXRsZT0iRmlndXJlIDI6IExvZ2luIHNlcXVl bmNlIHdpdGggcmVwZWF0ZWQgSE9TVCBjb21tYW5kIiBzdXBwcmVzcy10aXRsZT0iZmFsc2UiIGFs aWduPSJsZWZ0IiBhbHQ9IiIgd2lkdGg9IiIgaGVpZ2h0PSIiPg0KICAgICAgICAgICAgICA8cHJl YW1ibGU+VGhlIHN0YXRlIGRpYWdyYW0gaW4gRmlndXJlIDIgc2hvd3MgdGhlIGZsb3cgb2YgY29u dHJvbCB3aGVuIGEgSE9TVCBjb21tYW5kIGlzIHNlbnQgYWZ0ZXIgYSB1c2VyIGhhcyBhbHJlYWR5 IHN1Y2Nlc3NmdWxseSBsb2dnZWQgaW4gdG8gYSB2aXJ0dWFsIGhvc3Qgd2l0aCBVU0VSIGFuZCBQ QVNTLjwvcHJlYW1ibGU+DQogICAgICAgICAgICAgIDxhcnR3b3JrIHhtbDpzcGFjZT0icHJlc2Vy dmUiIG5hbWU9IiIgdHlwZT0iIiBhbGlnbj0ibGVmdCIgYWx0PSIiIHdpZHRoPSIiIGhlaWdodD0i Ij48IVtDREFUQVsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBWICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICArLS0tKyAgIEhP U1QgICAgKy0tLSsgMSwzLDUgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICB8IEIg fC0tLS0tLS0tLS0+fCBXIHwtLS0tLS0tLS0tLS0tLS0tLSAgICAgICAgICAgfA0KICAgICAgICAg ICArLS0tKyAgICAgICAgICAgKy0tLSsgICAgICAgICAgICAgICAgIHwgICAgICAgICAgfA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgfCAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg fA0KICAgICAgICAgICAgICAgICAgMiw1MDAsNTAyIHwgfCA0LDUwMSw1MDMsNTA0ICAgIHwgICAg ICAgICAgfA0KICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgIC0tLS0tLS0tLS0tLSAgICAg IHwgICAgICAgICAgfA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgIHwgICAgICAgICAgfA0KICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgMSAg ICAgICAgIHwgICAgIFYgICAgICAgICAgfA0KICAgICAgICAgICArLS0tKyAgIFVTRVIgICAgKy0t LSstLS0tLS0tLS0tLS0tLT4rLS0tKyAgICAgICAgfA0KICAgICAgICAgICB8ICAgfC0tLS0tLS0t LS0+fCBXIHwgMiAgICAgICAgIHwgICB8IEUgfCAgICAgICAgfA0KICAgICAgICAgICArLS0tKyAg ICAgICAgICAgKy0tLSstLS0tLS0gICAtLS0tLT4rLS0tKyAgICAgICAgfA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgfCAgICAgICB8IHwgIHwgICAgICAgICAgICAgICAgfA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAzIHwgfCA0LDUgICB8IHwgIHwgICAgICAgICAgICAgICAgfA0K ICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgIC0tLS0tICB8IHwgIHwgICAgICAgICAgICAg ICAgfA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgfCB8IHwgIHwgICAgICAg ICAgICAgICAgfA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgLS0tLS0tLS0tLSAgIHwg ICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgfCB8 ICAgIHwgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgIDF8ICAg ICAgfCB8ICAgIHwgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgIFYgICAgICAgICAgICAg ICB8ICAgICAgfCAgLS0tLS0tLT4rLS0tKyAgSE9TVCAgfA0KICAgICAgICAgICArLS0tKyAgIFBB U1MgICAgKy0tLSsgMiAgfCAgICAgIHwgICB8IFMgfC0tLS0tLS0tDQogICAgICAgICAgIHwgICB8 LS0tLS0tLS0tLT58IFcgfC0tLS0tLS0tLS0tLS0tPistLS0rDQogICAgICAgICAgICstLS0rICAg ICAgICAgICArLS0tKyAgICB8ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgfCAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDQsNSAgIHwgICAg ICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICAgICAgfA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgfCAgICAgICAtLT4rLS0tKw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgIC0tLS0tLS0tLT58IEYgfA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLT4rLS0tKw0KXV0+PC9hcnR3b3JrPg0K ICAgICAgICAgICAgPC9maWd1cmU+DQogICAgICAgICAgPC90Pg0KICAgICAgICAgIDx0Pg0KICAg ICAgICAgICAgPGZpZ3VyZSB0aXRsZT0iRmlndXJlIDM6IExvZ2luIHNlcXVlbmNlIHdpdGggSE9T VCBhbmQgQUNDVCBjb21tYW5kcyIgc3VwcHJlc3MtdGl0bGU9ImZhbHNlIiBhbGlnbj0ibGVmdCIg YWx0PSIiIHdpZHRoPSIiIGhlaWdodD0iIj4NCiAgICAgICAgICAgICAgPHByZWFtYmxlPkFmdGVy IGEgdXNlciBoYXMgbG9nZ2VkIGluLCBhbiBhZGRpdGlvbmFsIGFjY291bnQgbWF5IGJlIHJlcXVp cmVkIGJ5IHRoZSBzZXJ2ZXIgYW5kIHNwZWNpZmllZCBieSB0aGUgY2xpZW50IGJ5IHVzaW5nIEFD Q1QgY29tbWFuZC4gIFdpdGggdGhpcyBpbiBtaW5kLCB0aGUgc3RhdGUgZGlhZ3JhbSBpbiBGaWd1 cmUgMyBzaG93cyBhIHR5cGljYWwgc2VxdWVuY2Ugb2YgZmxvdyBvZiBjb250cm9sIHdoZW4gSE9T VCBpcyB1c2VkIHdpdGggVVNFUiBhbmQgUEFTUyB0byBsb2cgaW4gdG8gYW4gRlRQIHZpcnR1YWwg aG9zdCBhbmQgQUNDVCBpcyB1c2VkIHRvIHNwZWNpZnkgYW4gYWNjb3VudC48L3ByZWFtYmxlPg0K ICAgICAgICAgICAgICA8YXJ0d29yayB4bWw6c3BhY2U9InByZXNlcnZlIiBuYW1lPSIiIHR5cGU9 IiIgYWxpZ249ImxlZnQiIGFsdD0iIiB3aWR0aD0iIiBoZWlnaHQ9IiI+PCFbQ0RBVEFbDQogICAg ICAgICAgICstLS0rICAgSE9TVCAgICArLS0tKyAxLDMsNQ0KICAgICAgICAgICB8IEIgfC0tLS0t LS0tLS0+fCBXIHwtLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgICArLS0tKyAgICAgICAgICAg Ky0tLSsgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwg ICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAyLDUwMCw1MDIgfCB8IDQsNTAx LDUwMyw1MDQgICAgfA0KICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgIC0tLS0tLS0tLS0t LS0gICAgIHwNCiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICB8DQogICAgICAgICAgICAgViAgICAgICAgICAgICAgICAgICAxICAgICAgICAgIHwgICAgVg0K ICAgICAgICAgICArLS0tKyAgIFVTRVIgICAgKy0tLSstLS0tLS0tLS0tLS0tLT4rLS0tKw0KICAg ICAgICAgICB8ICAgfC0tLS0tLS0tLS0+fCBXIHwgMiAgICAgICAtLS0tLT58IEUgfA0KICAgICAg ICAgICArLS0tKyAgICAgICAgICAgKy0tLSstLS0tLS0gIHwgIC0tLT4rLS0tKw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgfCAgICAgICB8IHwgfCB8DQogICAgICAgICAgICAgICAgICAg ICAgICAgIDMgfCB8IDQsNSAgIHwgfCB8IHwNCiAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0g ICAtLS0tLSAgfCB8IHwgfA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgfCB8 IHwgfCB8DQogICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICB8IHwgfCB8IHwNCiAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0gIHwgfA0KICAgICAgICAgICAg IHwgICAgICAgICAgICAgIDF8ICAgICAgfCB8ICAgfCB8DQogICAgICAgICAgICAgViAgICAgICAg ICAgICAgIHwgICAgICB8IHwgICB8IHwNCiAgICAgICAgICAgKy0tLSsgICBQQVNTICAgICstLS0r IDIgIHwgIC0tLS0tLS0+Ky0tLSsNCiAgICAgICAgICAgfCAgIHwtLS0tLS0tLS0tPnwgVyB8LS0t LS0tLS0tLS0tLS0+fCBTIHwNCiAgICAgICAgICAgKy0tLSsgICAgICAgICAgICstLS0rICAgLS0t LS0tLS0tLS0+Ky0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwgICB8IHwgICAg IHwgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAzIHwgfDQsNXwgfCAgICAgfCB8DQogICAg ICAgICAgICAgIC0tLS0tLS0tLS0tLS0tICAgLS0tLS0tLS0gICB8ICAtLS0tDQogICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgfCB8ICB8ICB8ICAgICAgfA0KICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgIHwgfCAgfCAgfCAgICAgIHwNCiAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgIC0tLS0tLS0tLS0tLSAgICAgICB8DQogICAgICAgICAgICAgfCAgICAgICAgICAg IDEsM3wgICAgfCB8ICB8ICAgICAgICAgfA0KICAgICAgICAgICAgIFYgICAgICAgICAgICAgICB8 ICAgMnwgfCAgfCAgICAgICAgIFYNCiAgICAgICAgICAgKy0tLSsgICBBQ0NUICAgICstLS0rLS0g IHwgICAtLS0tLS0+Ky0tLSsNCiAgICAgICAgICAgfCAgIHwtLS0tLS0tLS0tPnwgVyB8IDQsNSAt LS0tLS0tLS0+fCBGIHwNCiAgICAgICAgICAgKy0tLSsgICAgICAgICAgICstLS0rLS0tLS0tLS0t LS0tLS0+Ky0tLStdXT48L2FydHdvcms+DQogICAgICAgICAgICA8L2ZpZ3VyZT4NCiAgICAgICAg ICA8L3Q+DQogICAgICAgICAgPHQ+DQogICAgICAgICAgICA8ZmlndXJlIHRpdGxlPSJGaWd1cmUg NDogTG9naW4gc2VxdWVuY2Ugd2l0aCBIT1NUIGFuZCBBVVRIL0FEQVQgY29tbWFuZHMiIHN1cHBy ZXNzLXRpdGxlPSJmYWxzZSIgYWxpZ249ImxlZnQiIGFsdD0iIiB3aWR0aD0iIiBoZWlnaHQ9IiI+ DQogICAgICAgICAgICAgIDxwcmVhbWJsZT5XaGVuIHRoZSBIT1NUIGNvbW1hbmQgaXMgdXNlZCBp biBjb21iaW5hdGlvbiB3aXRoIHRoZSBGVFAgc2VjdXJpdHkgZXh0ZW5zaW9ucyB0aGF0IHdlcmUg aW50cm9kdWNlZCBpbiA8eHJlZiB0YXJnZXQ9IlJGQzIyMjgiIHBhZ2Vubz0iZmFsc2UiIGZvcm1h dD0iZGVmYXVsdCIgLz4sIGl0IFNIT1VMRCBwcmVjZWRlIHRoZSBzZWN1cml0eSBoYW5kc2hha2Uu ICBUaGlzIGFsbG93cyBib3RoIHVzZXItUEkgYW5kIHNlcnZlci1GVFAgcHJvY2Vzc2VzIHRvIG1h cCBhbiBGVFAgSE9TVCB0byBzZWN1cml0eSBkYXRhIGFwcHJvcHJpYXRlbHkuICBUaGUgc3RhdGUg ZGlhZ3JhbSBpbiBGaWd1cmUgNCBzaG93cyBhIHR5cGljYWwgc2VxdWVuY2Ugb2YgZmxvdyBvZiBj b250cm9sIHdoZW4gSE9TVCBpcyB1c2VkIHdpdGggdGhlIEFVVEggYW5kIEFEQVQgY29tbWFuZHMg dGhhdCBhcmUgZGlzY3Vzc2VkIGluIDx4cmVmIHRhcmdldD0iUkZDMjIyOCIgcGFnZW5vPSJmYWxz ZSIgZm9ybWF0PSJkZWZhdWx0IiAvPi48L3ByZWFtYmxlPg0KICAgICAgICAgICAgICA8YXJ0d29y ayB4bWw6c3BhY2U9InByZXNlcnZlIiBuYW1lPSIiIHR5cGU9IiIgYWxpZ249ImxlZnQiIGFsdD0i IiB3aWR0aD0iIiBoZWlnaHQ9IiI+PCFbQ0RBVEFbDQogICAgICAgICAgICstLS0rICAgSE9TVCAg ICArLS0tKyAxLDMsNQ0KICAgICAgICAgICB8IEIgfC0tLS0tLS0tLS0+fCBXIHwtLS0tLS0tLS0t LS0tLS0tLS0gDQogICAgICAgICAgICstLS0rICAgICAgICAgICArLS0tKyAgICAgICAgICAgICAg ICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwgICAgICAgICAgICAgICAgICAg fA0KICAgICAgICAgICAgICAgICAgMiw1MDAsNTAyIHwgfCA0LDUwMSw1MDMsNTA0ICAgICB8DQog ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tICAgLS0tLS0tLS0tLS0tLSAgICAgIHwNCiAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgfA0KICAgICAgICAg ICAgIFYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICB8DQogICAgICAgICAgICst LS0rICAgQVVUSCAgICArLS0tKyA0LDUgICAgICAgIHwgICAgIHwNCiAgICAgICAgICAgfCAgIHwt LS0tLS0tLS0tPnwgVyB8LS0tLS0tLS0tLS0+fCAgICAgfA0KICAgICAgICAgICArLS0tKyAgICAg ICAgICAgKy0tLSsgICAgICAgICAgICB8ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgIDIz NCB8IHwgICAgICAgICAgICAgIHwgICAgIHwNCiAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLSAg fCAzMzQgICAgICAgICAgfCAgICAgfA0KICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAg ICAgICAgICAgICB8ICAgICB8DQogICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLXwtLS0tLS0t ICAgICAgIHwgICAgIHwNCiAgICAgICAgICAgICB8ICAgfCAgICAgICAgICAgfCAgICAgICB8ICAg ICAgfCAgICAgfA0KICAgICAgICAgICAgIFYgICB8ICAgICAgICAgICBWICAzMzUgIHwgICAgICB8 ICAgICB8DQogICAgICAgICAgICstLS0rIHwgQURBVCAgICArLS0tKy0tLS0tICAgICAgIHwgICAg IHwNCiAgICAgICAgICAgfCAgIHwtLS0tLS0tLS0tPnwgVyB8IDQsNSAgICAgICAgfCAgICAgfA0K ICAgICAgICAgICArLS0tKyB8ICAgICAgICAgKy0tLSstLS0tLS0tLS0tLT58ICAgICB8DQogICAg ICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAgIHwNCiAgICAgICAg ICAgICAtLS0tICAgICAgICAgMjM1fCAgICAgICAgICAgICAgfCAgICAgfA0KICAgICAgICAgICAg fCAgLS0tLS0tLS0tLS0tLS0gICAgICAgICAgICAgICB8ICAgICB8DQogICAgICAgICAgICB8IHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgIHwNCiAgICAgICAgICAgIFYgViAgICAg ICAgICAgICAgICAgIDEgICAgICAgICAgfCAgICAgVg0KICAgICAgICAgICArLS0tKyAgIFVTRVIg ICAgKy0tLSstLS0tLS0tLS0tLS0tLS0+Ky0tLSsNCiAgICAgICAgICAgfCAgIHwtLS0tLS0tLS0t PnwgVyB8IDIgICAgICAgICAgfCAgIHwgRSB8DQogICAgICAgICAgICstLS0rICAgICAgICAgICAr LS0tKy0tLS0tLS0gICAtLS0tLT4rLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg fCAgICAgICAgfCB8ICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgIDMgfCB8IDQsNSAgICB8 IHwgIHwNCiAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0gICAtLS0tLS0gIHwgfCAgfA0KICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwgfCB8ICB8DQogICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLSAgIHwNCiAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAxfCAgICAgICB8IHwgICAgfA0KICAgICAgICAgICAgIFYgICAgICAgICAgICAgICB8ICAg ICAgIHwgIC0tLS0tLS0+Ky0tLSsNCiAgICAgICAgICAgKy0tLSsgICBQQVNTICAgICstLS0rIDIg ICB8ICAgICAgfCAgIHwgUyB8DQogICAgICAgICAgIHwgICB8LS0tLS0tLS0tLT58IFcgfC0tLS0t LS0tLS0tLS0tLT4rLS0tKw0KICAgICAgICAgICArLS0tKyAgICAgICAgICAgKy0tLSsgICAgIHwg ICAgICB8ICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICAgICAgfA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDQsNSAgIHwgICAgICB8DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgfCAgICAgICAtLT4rLS0tKw0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAtLS0tLS0tLS0+fCBGIHwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLS0tPistLS0rXV0+PC9hcnR3b3JrPg0KICAg ICAgICAgICAgPC9maWd1cmU+DQogICAgICAgICAgPC90Pg0KICAgICAgICAgIDx0Pg0KICAgICAg ICAgICAgPGZpZ3VyZSB0aXRsZT0iRmlndXJlIDU6IExvZ2luIHNlcXVlbmNlIHdpdGggSE9TVCBh bmQgQVVUSC9BREFUL0FDQ1QgY29tbWFuZHMiIHN1cHByZXNzLXRpdGxlPSJmYWxzZSIgYWxpZ249 ImxlZnQiIGFsdD0iIiB3aWR0aD0iIiBoZWlnaHQ9IiI+DQogICAgICAgICAgICAgIDxwcmVhbWJs ZT5BZnRlciBhIHVzZXIgaGFzIGxvZ2dlZCBpbiB3aXRoIHRoZSBzZWN1cml0eSBjb21tYW5kcyB0 aGF0IGFyZSBkaXNjdXNzZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkMyMjI4IiBwYWdlbm89ImZhbHNl IiBmb3JtYXQ9ImRlZmF1bHQiIC8+LCBhbiBhZGRpdGlvbmFsIGFjY291bnQgbWF5IGJlIHJlcXVp cmVkIGJ5IHRoZSBzZXJ2ZXIgYW5kIHNwZWNpZmllZCBieSB0aGUgY2xpZW50IGJ5IHVzaW5nIEFD Q1QgY29tbWFuZC4gIFRoZSBzdGF0ZSBkaWFncmFtIGluIEZpZ3VyZSA1IHNob3dzIGEgdHlwaWNh bCBzZXF1ZW5jZSBvZiBmbG93IG9mIGNvbnRyb2wgd2hlbiBIT1NUIGlzIHVzZWQgd2l0aCB0aGUg QVVUSCBhbmQgQURBVCBjb21tYW5kcyB0byBsb2cgaW4gdG8gYW4gRlRQIHZpcnR1YWwgaG9zdCBh bmQgQUNDVCBpcyB1c2VkIHRvIHNwZWNpZnkgYW4gYWNjb3VudC48L3ByZWFtYmxlPg0KICAgICAg ICAgICAgICA8YXJ0d29yayB4bWw6c3BhY2U9InByZXNlcnZlIiBuYW1lPSIiIHR5cGU9IiIgYWxp Z249ImxlZnQiIGFsdD0iIiB3aWR0aD0iIiBoZWlnaHQ9IiI+PCFbQ0RBVEFbDQogICAgICAgICAg ICstLS0rICAgSE9TVCAgICArLS0tKyAxLDMsNQ0KICAgICAgICAgICB8IEIgfC0tLS0tLS0tLS0+ fCBXIHwtLS0tLS0tLS0tLS0tLS0tLS0gDQogICAgICAgICAgICstLS0rICAgICAgICAgICArLS0t KyAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwgICAg ICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgMiw1MDAsNTAyIHwgfCA0LDUwMSw1 MDMsNTA0ICAgICB8DQogICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tICAgLS0tLS0tLS0tLS0t LS0gICAgIHwNCiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgfA0KICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICB8 DQogICAgICAgICAgICstLS0rICAgQVVUSCAgICArLS0tKyA0LDUgICAgICAgICB8ICAgIHwNCiAg ICAgICAgICAgfCAgIHwtLS0tLS0tLS0tPnwgVyB8LS0tLS0tLS0tLS0tPnwgICAgfA0KICAgICAg ICAgICArLS0tKyAgICAgICAgICAgKy0tLSsgICAgICAgICAgICAgfCAgICB8DQogICAgICAgICAg ICAgICAgICAgICAgIDIzNCB8IHwgICAgICAgICAgICAgICB8ICAgIHwNCiAgICAgICAgICAgICAg ICAgIC0tLS0tLS0tLSAgfCAzMzQgICAgICAgICAgIHwgICAgfA0KICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICB8DQogICAgICAgICAgICAgIC0tLS0tLS0t LS0tLS0tLXwtLS0tLS0tICAgICAgICB8ICAgIHwNCiAgICAgICAgICAgICB8ICAgfCAgICAgICAg ICAgfCAgICAgICB8ICAgICAgIHwgICAgfA0KICAgICAgICAgICAgIFYgICB8ICAgICAgICAgICBW ICAzMzUgIHwgICAgICAgfCAgICB8DQogICAgICAgICAgICstLS0rIHwgQURBVCAgICArLS0tKy0t LS0tICAgICAgICB8ICAgIHwNCiAgICAgICAgICAgfCAgIHwtLS0tLS0tLS0tPnwgVyB8IDQsNSAg ICAgICAgIHwgICAgfA0KICAgICAgICAgICArLS0tKyB8ICAgICAgICAgKy0tLSstLS0tLS0tLS0t LS0+fCAgICB8DQogICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgICAgICB8 ICAgIHwNCiAgICAgICAgICAgICAtLS0tICAgICAgICAgMjM1fCAgICAgICAgICAgICAgIHwgICAg fA0KICAgICAgICAgICAgfCAgLS0tLS0tLS0tLS0tLS0gICAgICAgICAgICAgICAgfCAgICB8DQog ICAgICAgICAgICB8IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIHwNCiAgICAg ICAgICAgIFYgViAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgIHwgICAgVg0KICAgICAgICAg ICArLS0tKyAgIFVTRVIgICAgKy0tLSstLS0tLS0tLS0tLS0tLS0+Ky0tLSsNCiAgICAgICAgICAg fCAgIHwtLS0tLS0tLS0tPnwgVyB8IDIgICAgICAgIC0tLS0tPnwgRSB8DQogICAgICAgICAgICst LS0rICAgICAgICAgICArLS0tKy0tLS0tLS0gIHwgIC0tLT4rLS0tKw0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgfCAgICAgICAgfCB8IHwgfA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAzIHwgfCA0LDUgICAgfCB8IHwgfA0KICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgIC0t LS0tLSAgfCB8IHwgfA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwgfCB8 IHwgfA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0gIHwgfA0KICAg ICAgICAgICAgIHwgICAgICAgICAgICAgIDF8ICAgICAgIHwgfCAgIHwgfA0KICAgICAgICAgICAg IFYgICAgICAgICAgICAgICB8ICAgICAgIHwgfCAgIHwgfA0KICAgICAgICAgICArLS0tKyAgIFBB U1MgICAgKy0tLSsgMiAgIHwgIC0tLS0tLS0+Ky0tLSsNCiAgICAgICAgICAgfCAgIHwtLS0tLS0t LS0tPnwgVyB8LS0tLS0tLS0tLS0tLS0tPnwgUyB8DQogICAgICAgICAgICstLS0rICAgICAgICAg ICArLS0tKyAgIC0tLS0tLS0tLS0tLT4rLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgfCAgIHwgIHwgICAgIHwgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAzIHwgfDQsNXwg IHwgICAgIHwgfA0KICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgIC0tLS0tLS0tLSAgIHwg IC0tLS0NCiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8ICB8ICB8ICB8ICAgICAg fA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLSAgICAgICB8DQog ICAgICAgICAgICAgfCAgICAgICAgICAgIDEsM3wgICAgfCAgfCAgfCAgICAgICAgIHwNCiAgICAg ICAgICAgICBWICAgICAgICAgICAgICAgfCAgIDJ8ICB8ICB8ICAgICAgICAgVg0KICAgICAgICAg ICArLS0tKyAgIEFDQ1QgICAgKy0tLSstLSAgIHwgICAtLS0tLS0+Ky0tLSsNCiAgICAgICAgICAg fCAgIHwtLS0tLS0tLS0tPnwgVyB8IDQsNSAgLS0tLS0tLS0tPnwgRiB8DQogICAgICAgICAgICst LS0rICAgICAgICAgICArLS0tKy0tLS0tLS0tLS0tLS0tLT4rLS0tK11dPjwvYXJ0d29yaz4NCiAg ICAgICAgICAgIDwvZmlndXJlPg0KICAgICAgICAgIDwvdD4NCiAgICAgICAgPC9zZWN0aW9uPg0K ICAgICAgPC9zZWN0aW9uPg0KICAgICAgPHNlY3Rpb24gdGl0bGU9IkhPU1QgY29tbWFuZCBlcnJv cnMiIHRvYz0iZGVmYXVsdCI+DQogICAgICAgIDx0PlRoZSBzZXJ2ZXItUEkgU0hPVUxEIHJlcGx5 IHdpdGggYSA1MDAgb3IgNTAyIHJlcGx5IGlmIHRoZSBIT1NUIGNvbW1hbmQgaXMgdW5yZWNvZ25p emVkIG9yIHVuaW1wbGVtZW50ZWQuPC90Pg0KICAgICAgICA8dD5BcyBkaXNjdXNzZWQgaW4gc2Vj dGlvbiAzIG9mIHRoaXMgZG9jdW1lbnQsIGlmIGEgSE9TVCBjb21tYW5kIGlzIHNlbnQgYWZ0ZXIg YSB1c2VyIGhhcyBiZWVuIGF1dGhlbnRpY2F0ZWQgdGhlIHNlcnZlciBTSE9VTEQgZG8gb25lIG9m IHRoZSBmb2xsb3dpbmc6PC90Pg0KICAgICAgICA8dD4NCiAgICAgICAgICA8bGlzdCBzdHlsZT0i bGV0dGVycyI+DQogICAgICAgICAgICA8dD5TZW5kIGEgNTAzIHJlcGx5IGZvciBhbiBpbnZhbGlk IHNlcXVlbmNlIG9mIGNvbW1hbmRzLjwvdD4NCiAgICAgICAgICAgIDx0PlRyZWF0IHRoZSBIT1NU IGNvbW1hbmQgYXMgdGhvdWdoIGEgUkVJTiBjb21tYW5kIHdhcyBzZW50IGFuZCByZXNldCB0aGUg dXNlci1QSSB0byB0aGUgc3RhdGUgdGhhdCBleGlzdGVkIGFmdGVyIHRoZSBwcmV2aW91cyBIT1NU IGNvbW1hbmQgd2FzIHNlbnQgYW5kIGJlZm9yZSB0aGUgdXNlciBoYWQgYmVlbiBhdXRoZW50aWNh dGVkLCBhbmQgdGhlbiByZXR1cm4gdGhlIGFwcHJvcHJpYXRlIHJlcGx5IGZvciB0aGUgSE9TVCBj b21tYW5kLjwvdD4NCiAgICAgICAgICA8L2xpc3Q+DQogICAgICAgIDwvdD4NCiAgICAgICAgPHQ+ QSA1MDEgcmVwbHkgU0hPVUxEIGJlIHNlbnQgaWYgdGhlIGhvc3RuYW1lIGdpdmVuIGlzIHN5bnRh Y3RpY2FsbHkgaW52YWxpZCwgYW5kIGEgNTA0IHJlcGx5IFNIT1VMRCBiZSBzZW50IGlmIGEgc3lu dGFjdGljYWxseSB2YWxpZCBob3N0bmFtZSBpcyBub3QgYSB2YWxpZCB2aXJ0dWFsIGhvc3QgbmFt ZSBmb3IgdGhlIHNlcnZlci4gIEluIGFsbCBzdWNoIGNhc2VzLCB0aGUgc2VydmVyLUZUUCBwcm9j ZXNzIE1VU1QgZG8gb25lIG9mIHRoZSBmb2xsb3dpbmc6PC90Pg0KICAgICAgICA8dD4NCiAgICAg ICAgICA8bGlzdCBzdHlsZT0ibGV0dGVycyI+DQogICAgICAgICAgICA8dD5JZ25vcmUgdGhlIEhP U1QgY29tbWFuZCBhbmQgYWN0IGFzIGlmIGEgSE9TVCBjb21tYW5kIGhhZCBub3QgYmVlbiBzZW50 LiAgQSB1c2VyLUZUUCBwcm9jZXNzIE1BWSB0aGVuIHNlbmQgYSBzdWJzZXF1ZW50IEhPU1QgY29t bWFuZCB3aXRoIGEgZGlmZmVyZW50IGhvc3RuYW1lLjwvdD4NCiAgICAgICAgICAgIDx0PkNsb3Nl IHRoZSBjb25uZWN0aW9uLjwvdD4NCiAgICAgICAgICA8L2xpc3Q+DQogICAgICAgIDwvdD4NCiAg ICAgICAgPHQ+QSB1c2VyLVBJIHJlY2VpdmluZyBhIDUwMCBvciA1MDIgcmVwbHkgdG8gYSBIT1NU IGNvbW1hbmQgU0hPVUxEIGFzc3VtZSB0aGF0IHRoZSBzZXJ2ZXItUEkgZG9lcyBub3QgaW1wbGVt ZW50IHZpcnR1YWwgc2VydmVycyBieSB1c2luZyB0aGUgSE9TVCBjb21tYW5kLiAgVGhlIHVzZXIt UEkgTUFZIHRoZW4gcHJvY2VlZCB0byBsb2dpbiBhcyBpZiB0aGUgSE9TVCBjb21tYW5kIGhhZCBu b3QgYmVlbiBzZW50LjwvdD4NCiAgICAgICAgPHQ+QSB1c2VyLVBJIHJlY2VpdmluZyBhbiBlcnJv ciByZXBseSB0aGF0IGlzIGRpZmZlcmVudCBmcm9tIHRoZSBlcnJvcnMgdGhhdCBoYXZlIGJlZW4g ZGVzY3JpYmVkIGhlcmUgU0hPVUxEIGFzc3VtZSB0aGF0IHRoZSB2aXJ0dWFsIEhPU1QgaXMgdW5h dmFpbGFibGUsIGFuZCB0ZXJtaW5hdGUgY29tbXVuaWNhdGlvbnMuPC90Pg0KICAgICAgICA8dD5B IHNlcnZlci1QSSB0aGF0IHJlY2VpdmVzIGEgVVNFUiBjb21tYW5kIHRvIGJlZ2luIHRoZSBhdXRo ZW50aWNhdGlvbiBzZXF1ZW5jZSB3aXRob3V0IGhhdmluZyByZWNlaXZlZCBhIEhPU1QgY29tbWFu ZCBTSE9VTEQgTk9UIHJlamVjdCB0aGUgVVNFUiBjb21tYW5kLiAgQ2xpZW50cyBjb25mb3JtaW5n IHRvIGVhcmxpZXIgRlRQIHNwZWNpZmljYXRpb25zIGRvIG5vdCBzZW5kIEhPU1QgY29tbWFuZHMu ICBJbiB0aGlzIGNhc2UgdGhlIHNlcnZlciBNQVkgYWN0IGFzIGlmIHNvbWUgZGVmYXVsdCB2aXJ0 dWFsIGhvc3QgaGFkIGJlZW4gZXhwbGljaXRseSBzZWxlY3RlZCwgb3IgTUFZIGVudGVyIGFuIGVu dmlyb25tZW50IHRoYXQgaXMgZGlmZmVyZW50IGZyb20gdGhhdCBvZiBhbnkgc3VwcG9ydGVkIHZp cnR1YWwgaG9zdHMsIHBlcmhhcHMgb25lIGluIHdoaWNoIGEgdW5pb24gb2YgYWxsIGF2YWlsYWJs ZSBhY2NvdW50cyBleGlzdHMgYW5kIHdoaWNoIHByZXNlbnRzIGFuIE5WRlMgdGhhdCBhcHBlYXJz IHRvIGNvbnRhaW4gc3ViZGlyZWN0b3JpZXMgdGhhdCBjb250YWluIHRoZSBOVkZTIGZvciBhbGwg c3VwcG9ydGVkIHZpcnR1YWwgaG9zdHMuPC90Pg0KICAgICAgPC9zZWN0aW9uPg0KICAgICAgPHNl Y3Rpb24gdGl0bGU9IkZFQVQgcmVzcG9uc2UgZm9yIEhPU1QgY29tbWFuZCIgdG9jPSJkZWZhdWx0 Ij4NCiAgICAgICAgPHQ+V2hlbiByZXBseWluZyB0byB0aGUgRkVBVCBjb21tYW5kIDx4cmVmIHRh cmdldD0iUkZDMjM4OSIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0IiAvPiwgYSBzZXJ2 ZXItRlRQIHByb2Nlc3MgdGhhdCBzdXBwb3J0cyB0aGUgSE9TVCBjb21tYW5kIE1VU1QgaW5jbHVk ZSBhIGxpbmUgY29udGFpbmluZyB0aGUgc2luZ2xlIHdvcmQgIkhPU1QiLiAgVGhpcyB3b3JkIGlz IGNhc2UgaW5zZW5zaXRpdmUsIGFuZCBNQVkgYmUgc2VudCBpbiBhbnkgbWl4dHVyZSBvZiB1cHBl ciBvciBsb3dlciBjYXNlLCBob3dldmVyIGl0IFNIT1VMRCBiZSBzZW50IGluIHVwcGVyIGNhc2Uu ICBUaGF0IGlzLCB0aGUgcmVzcG9uc2UgU0hPVUxEIGJlOjwvdD4NCiAgICAgICAgPHQ+DQogICAg ICAgICAgPGZpZ3VyZSB0aXRsZT0iIiBzdXBwcmVzcy10aXRsZT0iZmFsc2UiIGFsaWduPSJsZWZ0 IiBhbHQ9IiIgd2lkdGg9IiIgaGVpZ2h0PSIiPg0KICAgICAgICAgICAgPGFydHdvcmsgeG1sOnNw YWNlPSJwcmVzZXJ2ZSIgbmFtZT0iIiB0eXBlPSIiIGFsaWduPSJsZWZ0IiBhbHQ9IiIgd2lkdGg9 IiIgaGVpZ2h0PSIiPjwhW0NEQVRBWyAgICAgQz4gRkVBVA0KICAgICBTPiAyMTEtIDxhbnkgZGVz Y3JpcHRpdmUgdGV4dD4NCiAgICAgUz4gIC4uLg0KICAgICBTPiAgSE9TVA0KICAgICBTPiAgLi4u DQogICAgIFM+IDIxMSBFbmRdXT48L2FydHdvcms+DQogICAgICAgICAgPC9maWd1cmU+DQogICAg ICAgIDwvdD4NCiAgICAgICAgPHQ+VGhlIGVsbGlwc2VzIGluZGljYXRlIHBsYWNlIGhvbGRlcnMg d2hlcmUgb3RoZXIgZmVhdHVyZXMgbWF5IGJlIGluY2x1ZGVkLCBhbmQgYXJlIG5vdCByZXF1aXJl ZC4gIFRoZSBvbmUtc3BhY2UgaW5kZW50YXRpb24gb2YgdGhlIGZlYXR1cmUgbGluZXMgaXMgbWFu ZGF0b3J5IDx4cmVmIHRhcmdldD0iUkZDMjM4OSIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZh dWx0IiAvPi48L3Q+DQogICAgICA8L3NlY3Rpb24+DQogICAgPC9zZWN0aW9uPg0KICAgIDxzZWN0 aW9uIGFuY2hvcj0iU2VjdXJpdHkiIHRpdGxlPSJTZWN1cml0eSBDb25zaWRlcmF0aW9ucyIgdG9j PSJkZWZhdWx0Ij4NCiAgICAgIDx0PldpdGggdGhlIGludHJvZHVjdGlvbiBvZiB2aXJ0dWFsIGhv c3RzIHRvIEZUUCwgc2VydmVyIGltcGxlbWVudGVycyB3aWxsIG5lZWQgdG8gdGFrZSBzb21lIGNh cmUgdG8gZW5zdXJlIHRoYXQgdGhlIGNvbmZpZGVudGlhbGl0eSBvZiBwb3RlbnRpYWxseSBzZW5z aXRpdmUgaW5mb3JtYXRpb24gaXMgbWFpbnRhaW5lZC4gIEZvciBleGFtcGxlLCB3aGlsZSBob3N0 bmFtZXMgbWF5IGdlbmVyYWxseSBiZSBhc3N1bWVkIHRvIGJlIHB1YmxpY2x5IGF2YWlsYWJsZSBE TlMgbmFtZXMsIHRoaXMgbWF5IG5vdCBhbHdheXMgYmUgdGhlIHNpdHVhdGlvbi4gIFNvbWUgb3Jn YW5pemF0aW9ucyBtYXkgdXNlIHByaXZhdGUgaG9zdG5hbWVzLCBhbmQgdGhhdCBpbmZvcm1hdGlv biBTSE9VTEQgYmUgcHJvdGVjdGVkIHdoZW4gdHJhbnNtaXR0ZWQgYmV0d2VlbiB0aGUgY2xpZW50 IGFuZCBzZXJ2ZXIgYnkgdXNpbmcgYSBzdHJvbmcgbWV0aG9kIG9mIGVuY3J5cHRpb24uPC90Pg0K ICAgICAgPHQ+U2VydmVyIGltcGxlbWVudGF0aW9ucyBTSE9VTEQgcmVzZXQgdGhlIHNlY3VyaXR5 IGVudmlyb25tZW50IHdoZW4gYSBIT1NUIGNvbW1hbmQgaXMgc2VudCBhZnRlciBhIHVzZXIgaGFz IGxvZ2dlZCBpbi4gIFRoaXMgYWxsb3dzIGZvciBpbmRpdmlkdWFsIGF1dGhlbnRpY2F0aW9uIGVu dmlyb25tZW50cyBmb3IgZWFjaCB2aXJ0dWFsIGhvc3Qgb24gYW4gRlRQIHNlcnZlci4gIEZvciBl eGFtcGxlLCBhIHZpcnR1YWwgaG9zdCAiZm9vLmV4YW1wbGUuY29tIiBvbiBhbiBGVFAgc2VydmVy IG1pZ2h0IHVzZSBhIHNwZWNpZmljIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBsaXN0LCB3aGlsZSB0 aGUgdmlydHVhbCBob3N0ICJiYXIuZXhhbXBsZS5jb20iIG9uIHRoZSBzYW1lIEZUUCBzZXJ2ZXIg bWlnaHQgdXNlIGEgZGlmZmVyZW50IHVzZXJuYW1lIGFuZCBwYXNzd29yZCBsaXN0LiAgSW4gc3Vj aCBhIHNjZW5hcmlvLCByZXNldHRpbmcgdGhlIHNlY3VyaXR5IGVudmlyb25tZW50IGlzIG5lY2Vz c2FyeSBmb3IgdmlydHVhbCBzZXJ2ZXJzIHRvIGFwcGVhciB0byBiZWhhdmUgaW5kZXBlbmRlbnRs eS48L3Q+DQogICAgICA8dD5BIGdlbmVyYWwgZGlzY3Vzc2lvbiBvZiBpc3N1ZXMgcmVsYXRlZCB0 byB0aGUgc2VjdXJpdHkgb2YgRlRQIGNhbiBiZSBmb3VuZCBpbiA8eHJlZiB0YXJnZXQ9IlJGQzI1 NzciIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIgLz4uPC90Pg0KICAgIDwvc2VjdGlv bj4NCiAgICA8c2VjdGlvbiBhbmNob3I9IklBTkEiIHRpdGxlPSJJQU5BIENvbnNpZGVyYXRpb25z IiB0b2M9ImRlZmF1bHQiPg0KICAgICAgPHQ+SUFOQSBpcyByZXF1ZXN0ZWQgdG8gcmVnaXN0ZXIg dGhlIGZvbGxvd2luZyBGVFAgZXh0ZW5zaW9uIGFjY29yZGluZyB0byB0aGUgcHJvY2VkdXJlIGVz dGFibGlzaGVkIGJ5IDx4cmVmIHRhcmdldD0iUkZDNTc5NyIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0 PSJkZWZhdWx0Ij48L3hyZWY+OjwvdD4NCiAgICAgIDx0ZXh0dGFibGUgdGl0bGU9IiIgc3VwcHJl c3MtdGl0bGU9ImZhbHNlIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0iZnVsbCI+DQogICAgICAgIDx0 dGNvbCBhbGlnbj0ibGVmdCI+Y21kPC90dGNvbD4NCiAgICAgICAgPHR0Y29sIGFsaWduPSJsZWZ0 Ij5GRUFUDQpDb2RlPC90dGNvbD4NCiAgICAgICAgPHR0Y29sIGFsaWduPSJsZWZ0Ij5kZXNjcmlw dGlvbjwvdHRjb2w+DQogICAgICAgIDx0dGNvbCBhbGlnbj0ibGVmdCI+dHlwZTwvdHRjb2w+DQog ICAgICAgIDx0dGNvbCBhbGlnbj0ibGVmdCI+Y29uZjwvdHRjb2w+DQogICAgICAgIDx0dGNvbCBh bGlnbj0ibGVmdCI+UkZDI3MvUmVmZXJlbmNlcw0KYW5kIE5vdGVzPC90dGNvbD4NCiAgICAgICAg PGM+SE9TVDwvYz4NCiAgICAgICAgPGM+SE9TVDwvYz4NCiAgICAgICAgPGM+SG9zdG5hbWU8L2M+ DQogICAgICAgIDxjPmE8L2M+DQogICAgICAgIDxjPm88L2M+DQogICAgICAgIDxjPlRCRDwvYz4N CiAgICAgICAgPHBvc3RhbWJsZT5OT1RFIFRPIFJGQyBFRElUT1I6IFBsZWFzZSB1cGRhdGUgVEJE IGluIHRoZSBhYm92ZSB0YWJsZSB3aXRoIHRoZSBudW1iZXIgb2YgdGhpcyBkb2N1bWVudC48L3Bv c3RhbWJsZT4NCiAgICAgIDwvdGV4dHRhYmxlPg0KICAgIDwvc2VjdGlvbj4NCiAgPC9taWRkbGU+ DQogIDxiYWNrPg0KICAgIDxyZWZlcmVuY2VzIHRpdGxlPSJOb3JtYXRpdmUgUmVmZXJlbmNlcyI+ DQogICAgICA8cmVmZXJlbmNlIGFuY2hvcj0iUkZDMDk1OSI+DQogICAgICAgIDxmcm9udD4NCiAg ICAgICAgICA8dGl0bGU+RmlsZSBUcmFuc2ZlciBQcm90b2NvbCAoRlRQKTwvdGl0bGU+DQogICAg ICAgICAgPGF1dGhvciBpbml0aWFscz0iSi4iIHN1cm5hbWU9IlBvc3RlbCI+PC9hdXRob3I+DQog ICAgICAgICAgPGF1dGhvciBpbml0aWFscz0iSi4iIHN1cm5hbWU9IlJleW5vbGRzIj48L2F1dGhv cj4NCiAgICAgICAgICA8ZGF0ZSB5ZWFyPSIxOTg1IiBtb250aD0iT2N0b2JlciIgLz4NCiAgICAg ICAgPC9mcm9udD4NCiAgICAgICAgPHNlcmllc0luZm8gbmFtZT0iU1REIiB2YWx1ZT0iOSIgLz4N CiAgICAgICAgPHNlcmllc0luZm8gbmFtZT0iUkZDIiB2YWx1ZT0iOTU5IiAvPg0KICAgICAgPC9y ZWZlcmVuY2U+DQogICAgICA8cmVmZXJlbmNlIGFuY2hvcj0iUkZDMTAzNCI+DQogICAgICAgIDxm cm9udD4NCiAgICAgICAgICA8dGl0bGU+RG9tYWluIE5hbWVzIC0gQ29uY2VwdHMgYW5kIEZhY2ls aXRpZXM8L3RpdGxlPg0KICAgICAgICAgIDxhdXRob3IgaW5pdGlhbHM9IlAuIiBzdXJuYW1lPSJN b2NrYXBldHJpcyI+PC9hdXRob3I+DQogICAgICAgICAgPGRhdGUgeWVhcj0iMTk4NyIgbW9udGg9 Ik5vdmVtYmVyIj48L2RhdGU+DQogICAgICAgIDwvZnJvbnQ+DQogICAgICAgIDxzZXJpZXNJbmZv IG5hbWU9IlNURCIgdmFsdWU9IjEzIiAvPg0KICAgICAgICA8c2VyaWVzSW5mbyBuYW1lPSJSRkMi IHZhbHVlPSIxMDM0IiAvPg0KICAgICAgPC9yZWZlcmVuY2U+DQogICAgICA8cmVmZXJlbmNlIGFu Y2hvcj0iUkZDMTAzNSI+DQogICAgICAgIDxmcm9udD4NCiAgICAgICAgICA8dGl0bGU+RG9tYWlu IE5hbWVzIC0gSW1wbGVtZW50YXRpb24gYW5kIFNwZWNpZmljYXRpb248L3RpdGxlPg0KICAgICAg ICAgIDxhdXRob3IgaW5pdGlhbHM9IlAuIiBzdXJuYW1lPSJNb2NrYXBldHJpcyI+PC9hdXRob3I+ DQogICAgICAgICAgPGRhdGUgeWVhcj0iMTk4NyIgbW9udGg9Ik5vdmVtYmVyIj48L2RhdGU+DQog ICAgICAgIDwvZnJvbnQ+DQogICAgICAgIDxzZXJpZXNJbmZvIG5hbWU9IlNURCIgdmFsdWU9IjEz IiAvPg0KICAgICAgICA8c2VyaWVzSW5mbyBuYW1lPSJSRkMiIHZhbHVlPSIxMDM1IiAvPg0KICAg ICAgPC9yZWZlcmVuY2U+DQogICAgICA8cmVmZXJlbmNlIGFuY2hvcj0iUkZDMTEyMyI+DQogICAg ICAgIDxmcm9udD4NCiAgICAgICAgICA8dGl0bGU+UmVxdWlyZW1lbnRzIGZvciBJbnRlcm5ldCBI b3N0cyAtLSBBcHBsaWNhdGlvbiBhbmQgU3VwcG9ydDwvdGl0bGU+DQogICAgICAgICAgPGF1dGhv ciBpbml0aWFscz0iUi4iIHN1cm5hbWU9IkJyYWRlbiIgLz4NCiAgICAgICAgICA8ZGF0ZSB5ZWFy PSIxOTg5IiBtb250aD0iT2N0b2JlciIgLz4NCiAgICAgICAgPC9mcm9udD4NCiAgICAgICAgPHNl cmllc0luZm8gbmFtZT0iU1REIiB2YWx1ZT0iMyIgLz4NCiAgICAgICAgPHNlcmllc0luZm8gbmFt ZT0iUkZDIiB2YWx1ZT0iMTEyMyIgLz4NCiAgICAgIDwvcmVmZXJlbmNlPg0KICAgICAgPHJlZmVy ZW5jZSBhbmNob3I9IlJGQzIxMTkiPg0KICAgICAgICA8ZnJvbnQ+DQogICAgICAgICAgPHRpdGxl PktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQgTGV2ZWxz PC90aXRsZT4NCiAgICAgICAgICA8YXV0aG9yIGluaXRpYWxzPSJTLiIgc3VybmFtZT0iQnJhZG5l ciI+PC9hdXRob3I+DQogICAgICAgICAgPGRhdGUgeWVhcj0iMTk5NyIgbW9udGg9Ik1hcmNoIiAv Pg0KICAgICAgICA8L2Zyb250Pg0KICAgICAgICA8c2VyaWVzSW5mbyBuYW1lPSJCQ1AiIHZhbHVl PSIxNCIgLz4NCiAgICAgICAgPHNlcmllc0luZm8gbmFtZT0iUkZDIiB2YWx1ZT0iMjExOSIgLz4N CiAgICAgIDwvcmVmZXJlbmNlPg0KICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IlJGQzIyMjgiPg0K ICAgICAgICA8ZnJvbnQ+DQogICAgICAgICAgPHRpdGxlPkZUUCBTZWN1cml0eSBFeHRlbnNpb25z PC90aXRsZT4NCiAgICAgICAgICA8YXV0aG9yIGluaXRpYWxzPSJNLiIgc3VybmFtZT0iSG9yb3dp dHoiPjwvYXV0aG9yPg0KICAgICAgICAgIDxhdXRob3IgaW5pdGlhbHM9IlMuIiBzdXJuYW1lPSJM dW50Ij48L2F1dGhvcj4NCiAgICAgICAgICA8ZGF0ZSB5ZWFyPSIxOTk3IiBtb250aD0iT2N0b2Jl ciIgLz4NCiAgICAgICAgPC9mcm9udD4NCiAgICAgICAgPHNlcmllc0luZm8gbmFtZT0iUkZDIiB2 YWx1ZT0iMjIyOCIgLz4NCiAgICAgIDwvcmVmZXJlbmNlPg0KICAgICAgPHJlZmVyZW5jZSBhbmNo b3I9IlJGQzIzODkiPg0KICAgICAgICA8ZnJvbnQ+DQogICAgICAgICAgPHRpdGxlPkZlYXR1cmUg bmVnb3RpYXRpb24gbWVjaGFuaXNtIGZvciB0aGUgRmlsZSBUcmFuc2ZlciBQcm90b2NvbDwvdGl0 bGU+DQogICAgICAgICAgPGF1dGhvciBpbml0aWFscz0iUC4iIHN1cm5hbWU9IkhldGhtb24iPjwv YXV0aG9yPg0KICAgICAgICAgIDxhdXRob3IgaW5pdGlhbHM9IlIuIiBzdXJuYW1lPSJFbHoiPjwv YXV0aG9yPg0KICAgICAgICAgIDxkYXRlIHllYXI9IjE5OTgiIG1vbnRoPSJBdWd1c3QiIC8+DQog ICAgICAgIDwvZnJvbnQ+DQogICAgICAgIDxzZXJpZXNJbmZvIG5hbWU9IlJGQyIgdmFsdWU9IjIz ODkiIC8+DQogICAgICA8L3JlZmVyZW5jZT4NCiAgICAgIDxyZWZlcmVuY2UgYW5jaG9yPSJSRkMy NjQwIj4NCiAgICAgICAgPGZyb250Pg0KICAgICAgICAgIDx0aXRsZT5JbnRlcm5hdGlvbmFsaXph dGlvbiBvZiB0aGUgRmlsZSBUcmFuc2ZlciBQcm90b2NvbDwvdGl0bGU+DQogICAgICAgICAgPGF1 dGhvciBpbml0aWFscz0iVy4iIHN1cm5hbWU9IkN1cnRpbiI+PC9hdXRob3I+DQogICAgICAgICAg PGRhdGUgeWVhcj0iMTk5OSIgbW9udGg9Ikp1bHkiIC8+DQogICAgICAgIDwvZnJvbnQ+DQogICAg ICAgIDxzZXJpZXNJbmZvIG5hbWU9IlJGQyIgdmFsdWU9IjI2NDAiIC8+DQogICAgICA8L3JlZmVy ZW5jZT4NCiAgICAgIDxyZWZlcmVuY2UgYW5jaG9yPSJSRkMzNDkyIj4NCiAgICAgICAgPGZyb250 Pg0KICAgICAgICAgIDx0aXRsZT5QdW55Y29kZTogQSBCb290c3RyaW5nIGVuY29kaW5nIG9mIFVu aWNvZGUgZm9yIEludGVybmF0aW9uYWxpemVkIERvbWFpbiBOYW1lcyBpbiBBcHBsaWNhdGlvbnMg KElETkEpPC90aXRsZT4NCiAgICAgICAgICA8YXV0aG9yIGluaXRpYWxzPSJBLiIgc3VybmFtZT0i Q29zdGVsbG8iPjwvYXV0aG9yPg0KICAgICAgICAgIDxkYXRlIHllYXI9IjIwMDMiIG1vbnRoPSJN YXJjaCIgLz4NCiAgICAgICAgPC9mcm9udD4NCiAgICAgICAgPHNlcmllc0luZm8gbmFtZT0iUkZD IiB2YWx1ZT0iMzQ5MiIgLz4NCiAgICAgIDwvcmVmZXJlbmNlPg0KICAgICAgPHJlZmVyZW5jZSBh bmNob3I9IlJGQzQyMTciPg0KICAgICAgICA8ZnJvbnQ+DQogICAgICAgICAgPHRpdGxlPlNlY3Vy aW5nIEZUUCB3aXRoIFRMUzwvdGl0bGU+DQogICAgICAgICAgPGF1dGhvciBpbml0aWFscz0iUC4i IHN1cm5hbWU9IkZvcmQtSHV0Y2hpbnNvbiI+PC9hdXRob3I+DQogICAgICAgICAgPGRhdGUgeWVh cj0iMjAwNSIgbW9udGg9Ik9jdG9iZXIiIC8+DQogICAgICAgIDwvZnJvbnQ+DQogICAgICAgIDxz ZXJpZXNJbmZvIG5hbWU9IlJGQyIgdmFsdWU9IjQyMTciIC8+DQogICAgICA8L3JlZmVyZW5jZT4N CiAgICAgIDxyZWZlcmVuY2UgYW5jaG9yPSJSRkM1MjM0Ij4NCiAgICAgICAgPGZyb250Pg0KICAg ICAgICAgIDx0aXRsZT5BdWdtZW50ZWQgQk5GIGZvciBTeW50YXggU3BlY2lmaWNhdGlvbnM6IEFC TkY8L3RpdGxlPg0KICAgICAgICAgIDxhdXRob3IgaW5pdGlhbHM9IkQuIiBzdXJuYW1lPSJDcm9j a2VyIj48L2F1dGhvcj4NCiAgICAgICAgICA8YXV0aG9yIGluaXRpYWxzPSJQLiIgc3VybmFtZT0i T3ZlcmVsbCI+PC9hdXRob3I+DQogICAgICAgICAgPGRhdGUgeWVhcj0iMjAwOCIgbW9udGg9Ikph bnVhcnkiIC8+DQogICAgICAgIDwvZnJvbnQ+DQogICAgICAgIDxzZXJpZXNJbmZvIG5hbWU9IlJG QyIgdmFsdWU9IjUyMzQiIC8+DQogICAgICA8L3JlZmVyZW5jZT4NCiAgICA8L3JlZmVyZW5jZXM+ DQogICAgPHJlZmVyZW5jZXMgdGl0bGU9IkluZm9ybWF0aXZlIFJlZmVyZW5jZXMiPg0KICAgICAg PHJlZmVyZW5jZSBhbmNob3I9IlJGQzE5NDUiPg0KICAgICAgICA8ZnJvbnQ+DQogICAgICAgICAg PHRpdGxlPkh5cGVydGV4dCBUcmFuc2ZlciBQcm90b2NvbCAtLSBIVFRQLzEuMDwvdGl0bGU+DQog ICAgICAgICAgPGF1dGhvciBpbml0aWFscz0iVC4iIHN1cm5hbWU9IkJlcm5lcnMtTGVlIj48L2F1 dGhvcj4NCiAgICAgICAgICA8YXV0aG9yIGluaXRpYWxzPSJSLiIgc3VybmFtZT0iRmllbGRpbmci PjwvYXV0aG9yPg0KICAgICAgICAgIDxhdXRob3IgaW5pdGlhbHM9IkguIiBzdXJuYW1lPSJGcnlz dHlrIj48L2F1dGhvcj4NCiAgICAgICAgICA8ZGF0ZSB5ZWFyPSIxOTk2IiBtb250aD0iTWF5IiAv Pg0KICAgICAgICA8L2Zyb250Pg0KICAgICAgICA8c2VyaWVzSW5mbyBuYW1lPSJSRkMiIHZhbHVl PSIxOTQ1IiAvPg0KICAgICAgPC9yZWZlcmVuY2U+DQogICAgICA8cmVmZXJlbmNlIGFuY2hvcj0i UkZDMjU3NyI+DQogICAgICAgIDxmcm9udD4NCiAgICAgICAgICA8dGl0bGU+RlRQIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zPC90aXRsZT4NCiAgICAgICAgICA8YXV0aG9yIGluaXRpYWxzPSJNLiIg c3VybmFtZT0iQWxsbWFuIj48L2F1dGhvcj4NCiAgICAgICAgICA8YXV0aG9yIGluaXRpYWxzPSJT LiIgc3VybmFtZT0iT3N0ZXJtYW5uIj48L2F1dGhvcj4NCiAgICAgICAgICA8ZGF0ZSB5ZWFyPSIx OTk5IiBtb250aD0iTWF5IiAvPg0KICAgICAgICA8L2Zyb250Pg0KICAgICAgICA8c2VyaWVzSW5m byBuYW1lPSJSRkMiIHZhbHVlPSIyNTc3IiAvPg0KICAgICAgPC9yZWZlcmVuY2U+DQogICAgICA8 cmVmZXJlbmNlIGFuY2hvcj0iUkZDMjYxNiI+DQogICAgICAgIDxmcm9udD4NCiAgICAgICAgICA8 dGl0bGU+SHlwZXJ0ZXh0IFRyYW5zZmVyIFByb3RvY29sIC0tIEhUVFAvMS4xPC90aXRsZT4NCiAg ICAgICAgICA8YXV0aG9yIGluaXRpYWxzPSJSLiIgc3VybmFtZT0iRmllbGRpbmciPjwvYXV0aG9y Pg0KICAgICAgICAgIDxhdXRob3IgaW5pdGlhbHM9IkouIiBzdXJuYW1lPSJHZXR0eXMiPjwvYXV0 aG9yPg0KICAgICAgICAgIDxhdXRob3IgaW5pdGlhbHM9IkouIiBzdXJuYW1lPSJNb2d1bCI+PC9h dXRob3I+DQogICAgICAgICAgPGF1dGhvciBpbml0aWFscz0iSC4iIHN1cm5hbWU9IkZyeXN0eWsi PjwvYXV0aG9yPg0KICAgICAgICAgIDxhdXRob3IgaW5pdGlhbHM9IkwuIiBzdXJuYW1lPSJNYXNp bnRlciI+PC9hdXRob3I+DQogICAgICAgICAgPGF1dGhvciBpbml0aWFscz0iUC4iIHN1cm5hbWU9 IkxlYWNoIj48L2F1dGhvcj4NCiAgICAgICAgICA8YXV0aG9yIGluaXRpYWxzPSJULiIgc3VybmFt ZT0iQmVybmVycy1MZWUiPjwvYXV0aG9yPg0KICAgICAgICAgIDxkYXRlIHllYXI9IjE5OTkiIG1v bnRoPSJKdW5lIiAvPg0KICAgICAgICA8L2Zyb250Pg0KICAgICAgICA8c2VyaWVzSW5mbyBuYW1l PSJSRkMiIHZhbHVlPSIyNjE2IiAvPg0KICAgICAgPC9yZWZlcmVuY2U+DQogICAgICA8cmVmZXJl bmNlIGFuY2hvcj0iUkZDNTc5NyI+DQogICAgICAgIDxmcm9udD4NCiAgICAgICAgICA8dGl0bGU+ RlRQIENvbW1hbmQgYW5kIEV4dGVuc2lvbiBSZWdpc3RyeTwvdGl0bGU+DQogICAgICAgICAgPGF1 dGhvciBpbml0aWFscz0iSi4iIHN1cm5hbWU9IktsZW5zaW4iPjwvYXV0aG9yPg0KICAgICAgICAg IDxhdXRob3IgaW5pdGlhbHM9IkEuIiBzdXJuYW1lPSJIb2VuZXMiPjwvYXV0aG9yPg0KICAgICAg ICAgIDxkYXRlIG1vbnRoPSJNYXJjaCIgeWVhcj0iMjAxMCIgLz4NCiAgICAgICAgPC9mcm9udD4N CiAgICAgICAgPHNlcmllc0luZm8gbmFtZT0iUkZDIiB2YWx1ZT0iNTc5NyIgLz4NCiAgICAgIDwv cmVmZXJlbmNlPg0KICAgIDwvcmVmZXJlbmNlcz4NCiAgICA8c2VjdGlvbiB0aXRsZT0iVW53b3Jr YWJsZSBBbHRlcm5hdGl2ZXMiIHRvYz0iZGVmYXVsdCI+DQogICAgICA8dD5EdWUgdG8gdGhlIGxl dmVsIG9mIHNjb3BlIGZvciBhZGRpbmcgYSBuZXcgY29tbWFuZCB0byBGVFAsIGEgYnJpZWYgZGlz Y3Vzc2lvbiBvZiBzdWdnZXN0ZWQgYWx0ZXJuYXRpdmVzIHRvIGEgSE9TVCBjb21tYW5kIGFuZCB0 aGVpciByZXNwZWN0aXZlIGxpbWl0YXRpb25zIGlzIHdhcnJhbnRlZC4gIFRoZSBzdWdnZXN0ZWQg YWx0ZXJuYXRpdmVzIHRoYXQgYXJlIGRpc2N1c3NlZCBpbiB0aGlzIGFwcGVuZGl4IGhhdmUgYmVl biBwcm9wb3NlZCBpbiB0aGUgcGFzdCwgYnV0IGVhY2ggb2YgdGhlc2UgaWRlYXMgd2FzIGRlZW1l ZCBpbnN1ZmZpY2llbnQgZm9yIHRoZSByZWFzb25zIHRoYXQgYXJlIGxpc3RlZCB3aXRoaW4gZWFj aCBzZWN0aW9uIG9mIHRoZSBhcHBlbmRpeC48L3Q+DQogICAgICA8c2VjdGlvbiB0aXRsZT0iT3Zl cmxvYWRpbmcgdGhlIENXRCBjb21tYW5kIiB0b2M9ImRlZmF1bHQiPg0KICAgICAgICA8dD5PbmUg c3VnZ2VzdGVkIG1ldGhvZCB0byBlbXVsYXRlIGEgZm9ybSBvZiB2aXJ0dWFsIGhvc3RzIHdvdWxk IGJlIGZvciB0aGUgY2xpZW50IHRvIHNpbXBseSBzZW5kIGEgIkNXRCIgY29tbWFuZCBhZnRlciBj b25uZWN0aW5nLCB1c2luZyB0aGUgdmlydHVhbCBob3N0IG5hbWUgYXMgdGhlIGFyZ3VtZW50IHRv IHRoZSBDV0QgY29tbWFuZC4gIFRoaXMgd291bGQgYWxsb3cgdGhlIHNlcnZlci1GVFAgcHJvY2Vz cyB0byBpbXBsZW1lbnQgdGhlIGZpbGUgc3RvcmVzIG9mIHRoZSB2aXJ0dWFsIGhvc3RzIGFzIHN1 Yi1kaXJlY3RvcmllcyBpbiBpdHMgTlZGUy4gIFRoaXMgc3VnZ2VzdGlvbiBpcyBzaW1wbGUgaW4g Y29uY2VwdCwgYW5kIG1vc3Qgc2VydmVyLUZUUCBpbXBsZW1lbnRhdGlvbnMgc3VwcG9ydCB0aGlz IHdpdGhvdXQgcmVxdWlyaW5nIGFueSBjb2RlIGNoYW5nZXMuICBXaGlsZSB0aGlzIG1ldGhvZCBp cyBzaW1wbGUgdG8gZGVzY3JpYmUsIGFuZCB0byBpbXBsZW1lbnQsIGl0IHN1ZmZlcnMgZnJvbSBz ZXZlcmFsIGRyYXdiYWNrczo8L3Q+DQogICAgICAgIDx0Pg0KICAgICAgICAgIDxsaXN0IHN0eWxl PSJsZXR0ZXJzIj4NCiAgICAgICAgICAgIDx0PlRoZSAiQ1dEIiBjb21tYW5kIGlzIGF2YWlsYWJs ZSBvbmx5IGFmdGVyIHRoZSB1c2VyLVBJIGhhcyBhdXRoZW50aWNhdGVkIGl0c2VsZiB0byB0aGUg c2VydmVyLUZUUCBwcm9jZXNzLiAgVGh1cywgYWxsIHZpcnR1YWwgaG9zdHMgd291bGQgYmUgcmVx dWlyZWQgdG8gc2hhcmUgYSBjb21tb24gYXV0aGVudGljYXRpb24gc2NoZW1lIGlmIHRoZXkgdXNl ZCB0aGlzIG1ldGhvZC48L3Q+DQogICAgICAgICAgICA8dD5UbyBtYWtlIHRoZSB2aXJ0dWFsIGhv c3QgdHJ1bHkgdHJhbnNwYXJlbnQsIGVpdGhlciB0aGUgc2VydmVyLUZUUCBwcm9jZXNzIG5lZWRz IHRvIGJlIG1vZGlmaWVkIHRvIGluY2x1ZGUgaW5mb3JtYXRpb24gdGhhdCBzaG93cyB0aGUgc3Bl Y2lhbCBuYXR1cmUgb2YgdGhpcyBmaXJzdCBDV0QgY29tbWFuZCAobmVnYXRpbmcgbW9zdCBvZiB0 aGUgYWR2YW50YWdlIG9mIHRoaXMgc2NoZW1lKSwgb3IgYWxsIHVzZXJzIG11c3Qgc2VlIHRoZSBz YW1lIGlkZW50aWNhbCBOVkZTIHZpZXcgdXBvbiBjb25uZWN0aW5nICh0aGV5IG11c3QgY29ubmVj dCBpbiB0aGUgc2FtZSBpbml0aWFsIGRpcmVjdG9yeSksIG9yIHRoZSBOVkZTIG11c3QgaW1wbGVt ZW50IHRoZSBmdWxsIHNldCBvZiB2aXJ0dWFsIGhvc3QgZGlyZWN0b3JpZXMgYXQgZWFjaCBwb3Nz aWJsZSBpbml0aWFsIGRpcmVjdG9yeSBmb3IgYW55IHBvc3NpYmxlIHVzZXIuPC90Pg0KICAgICAg ICAgICAgPHQ+VW5sZXNzIHRoZSBzZXJ2ZXIgaXMgc3BlY2lhbGx5IG1vZGlmaWVkLCBhIHVzZXIg Y29ubmVjdGluZyB0aGlzIHdheSB0byBhIHZpcnR1YWwgaG9zdCB3b3VsZCBiZSBhYmxlIHRvIGVh c2lseSBtb3ZlIHRvIGFueSBvdGhlciB2aXJ0dWFsIGhvc3Qgc3VwcG9ydGVkIGF0IHRoZSBzYW1l IHNlcnZlci1GVFAgcHJvY2VzcywgZXhwb3NpbmcgdGhlIG5hdHVyZSBvZiB0aGUgdmlydHVhbCBo b3N0LjwvdD4NCiAgICAgICAgICA8L2xpc3Q+DQogICAgICAgIDwvdD4NCiAgICAgIDwvc2VjdGlv bj4NCiAgICAgIDxzZWN0aW9uIHRpdGxlPSJPdmVybG9hZGluZyB0aGUgQUNDVCBjb21tYW5kIiB0 b2M9ImRlZmF1bHQiPg0KICAgICAgICA8dD5Bbm90aGVyIHN1Z2dlc3RlZCBtZXRob2Qgd291bGQg YmUgdG8gc2ltcGx5IG92ZXJsb2FkIHRoZSAiQUNDVCIgZm9yIEZUUCB2aXJ0dWFsIGhvc3RzLCBi dXQgdGhpcyBwcm9wb3NhbCBpcyB1bmFjY2VwdGFibGUgZm9yIHNldmVyYWwgcmVhc29ucyB3aXRo IHJlZ2FyZCB0byB3aGVuIHRoZSBBQ0NUIGNvbW1hbmQgaXMgc2VudCBkdXJpbmcgdGhlIHJlcXVl c3QgZmxvdy4gIFNlY3Rpb25zIDUuNCBhbmQgNiBvZiA8eHJlZiB0YXJnZXQ9IlJGQzA5NTkiIHBh Z2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIgLz4gZG9jdW1lbnQgdGhlIHJlcXVlc3QgZmxv dyBmb3IgYSBsb2dpbiBzZXF1ZW5jZSBhcyBVU0VSIC0mZ3Q7IFBBU1MgLSZndDsgQUNDVC4gIFRo aXMgZmxvdyBvZiBjb21tYW5kcyBtYXkgYmUgYWNjZXB0YWJsZSB3aGVuIHlvdSBhcmUgY29uc2lk ZXJpbmcgYSBzaW5nbGUgdXNlciBoYXZpbmcgbXVsdGlwbGUgYWNjb3VudHMgb24gYW4gRlRQIHNl cnZlciwgYnV0IGZhaWxzIHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiB2aXJ0dWFsIGhvc3RzIHdo ZW4geW91IGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgdHdvIGlzc3Vlczo8L3Q+DQogICAgICAgIDx0 Pg0KICAgICAgICAgIDxsaXN0IHN0eWxlPSJsZXR0ZXJzIj4NCiAgICAgICAgICAgIDx0PlRoZSBm aXJzdCBwcm9ibGVtIHdpdGggb3ZlcmxvYWRpbmcgdGhlIEFDQ1QgY29tbWFuZCBpcyBjZXJ0aWZp Y2F0ZSBuZWdvdGlhdGlvbiB3aGVuIHVzaW5nIHRoZSBGVFAgc2VjdXJpdHkgZXh0ZW5zaW9ucyB0 aGF0IGFyZSBkb2N1bWVudGVkIGluIDx4cmVmIHRhcmdldD0iUkZDMjIyOCIgcGFnZW5vPSJmYWxz ZSIgZm9ybWF0PSJkZWZhdWx0IiAvPiBhbmQgPHhyZWYgdGFyZ2V0PSJSRkM0MjE3IiBwYWdlbm89 ImZhbHNlIiBmb3JtYXQ9ImRlZmF1bHQiIC8+LiAgSW4gb3JkZXIgdG8gc2FmZWd1YXJkIHVzZXIg Y3JlZGVudGlhbHMsIHNlY3VyaXR5IG1lY2hhbmlzbSBhbmQgY2VydGlmaWNhdGUgbmVnb3RpYXRp b24gbXVzdCBvY2N1ciBiZWZvcmUgbG9naW4gY3JlZGVudGlhbHMgYXJlIHNlbnQgYnkgdGhlIGNs aWVudC4gIFRoZSBwcm9ibGVtIHdpdGggdXNpbmcgdGhlIEFDQ1QgY29tbWFuZCBpbiB0aGlzIHNj ZW5hcmlvIGlzIHRoYXQgdGhlcmUgaXMgbm8gd2F5IG9mIGVuc3VyaW5nIHRoYXQgdGhlIGNlcnRp ZmljYXRlIG1hdGNoZXMgdGhlIGNvcnJlY3QgdmlydHVhbCBob3N0IGJlZm9yZSB0aGUgdXNlciBj cmVkZW50aWFscyBhcmUgc2VudC48L3Q+DQogICAgICAgICAgICA8dD5UaGUgc2Vjb25kIHByb2Js ZW0gd2l0aCBvdmVybG9hZGluZyB0aGUgQUNDVCBjb21tYW5kIGlzIGhvdyB1c2VyIGNyZWRlbnRp YWxzIGFyZSBpbXBsZW1lbnRlZCBmb3IgRlRQIHZpcnR1YWwgaG9zdHMuICBGVFAgc2VydmVyIGlt cGxlbWVudGF0aW9ucyBtYXkgYWxsb3cgdGhlIHVzZSBvZiBjdXN0b20gdXNlciBjcmVkZW50aWFs cyBvbiBhIHBlci12aXJ0dWFsLWhvc3QgYmFzaXMuICBGb3IgZXhhbXBsZSwgaW4gb25lIHBhcnRp Y3VsYXIgaW1wbGVtZW50YXRpb24gdGhlIHZpcnR1YWwgaG9zdCBuZWdvdGlhdGlvbiBvY2N1cnMs IGFuZCB0aGVuIHRoZSB1c2VyIGNyZWRlbnRpYWxzIGFyZSBsb29rZWQgdXAgdXNpbmcgdGhlIGFj Y291bnQgbWVjaGFuaXNtIHRoYXQgaXMgc3BlY2lmaWMgdG8gdGhhdCB2aXJ0dWFsIGhvc3QuICBT byBvbmNlIGFnYWluIHRoZSB2aXJ0dWFsIGhvc3QgbmVnb3RpYXRpb24gbXVzdCB0YWtlIHBsYWNl IGJlZm9yZSB0aGUgdXNlciBjcmVkZW50aWFscyBhcmUgc2VudC48L3Q+DQogICAgICAgICAgPC9s aXN0Pg0KICAgICAgICA8L3Q+DQogICAgICA8L3NlY3Rpb24+DQogICAgICA8c2VjdGlvbiB0aXRs ZT0iT3ZlcmxvYWRpbmcgdGhlIFVTRVIgY29tbWFuZCIgdG9jPSJkZWZhdWx0Ij4NCiAgICAgICAg PHQ+QW4gYWRkaXRpb25hbCBzdWdnZXN0aW9uIHdvdWxkIGJlIHRvIG92ZXJsb2FkIHdlbGwta25v d24gc3ludGF4IHRocm91Z2ggdGhlIGV4aXN0aW5nIFVTRVIgY29tbWFuZCwgYXMgaWxsdXN0cmF0 ZWQgaW4gdGhlIGZvbGxvd2luZyBleGFtcGxlOjwvdD4NCiAgICAgICAgPHQ+DQogICAgICAgICAg PGZpZ3VyZSB0aXRsZT0iIiBzdXBwcmVzcy10aXRsZT0iZmFsc2UiIGFsaWduPSJsZWZ0IiBhbHQ9 IiIgd2lkdGg9IiIgaGVpZ2h0PSIiPg0KICAgICAgICAgICAgPGFydHdvcmsgeG1sOnNwYWNlPSJw cmVzZXJ2ZSIgbmFtZT0iIiB0eXBlPSIiIGFsaWduPSJsZWZ0IiBhbHQ9IiIgd2lkdGg9IiIgaGVp Z2h0PSIiPjwhW0NEQVRBWyAgICAgQz4gVVNFUiBmb29AZXhhbXBsZS5jb20NCiAgICAgUz4gMzMx IFBhc3N3b3JkIHJlcXVpcmVkDQogICAgIEM+IFBBU1MgYmFyDQogICAgIFM+IDIzMCBVc2VyIGxv Z2dlZCBpbl1dPjwvYXJ0d29yaz4NCiAgICAgICAgICA8L2ZpZ3VyZT4NCiAgICAgICAgPC90Pg0K ICAgICAgICA8dD5JbiB0aGlzIGV4YW1wbGUsIHRoZSB1c2VyICJmb28iIG1pZ2h0IGJlIGF0dGVt cHRpbmcgdG8gbG9nIG9uIHRvIHRoZSB2aXJ0dWFsIGhvc3QgImV4YW1wbGUuY29tIiBvbiBhbiBG VFAgc2VydmVyLiAgVGhpcyBzdWdnZXN0aW9uIG1heSBzZWVtIHBsYXVzaWJsZSBhdCBmaXJzdCwg YnV0IGludHJvZHVjZXMgc2V2ZXJhbCBpbXBsZW1lbnRhdGlvbiBwcm9ibGVtcy4gIEZvciBleGFt cGxlOjwvdD4NCiAgICAgICAgPHQ+DQogICAgICAgICAgPGxpc3Qgc3R5bGU9ImxldHRlcnMiPg0K ICAgICAgICAgICAgPHQ+U29tZSBuZXR3b3JrIGVudmlyb25tZW50cyBhbHJlYWR5IHVzZSB0aGUg InVzZXJuYW1lQGhvc3RuYW1lIiBzeW50YXggZm9yIG5ldHdvcmsgY3JlZGVudGlhbHMsIHdoZXJl IHRoZSAiaG9zdG5hbWUiIHBvcnRpb24gcmVmZXJzIHRvIHRoZSBsb2NhdGlvbiBvZiB0aGUgdXNl cidzIGNyZWRlbnRpYWxzIHdpdGhpbiB0aGUgbmV0d29yayBoaWVyYXJjaHkuICBVc2luZyB0aGUg ImZvb0BleGFtcGxlLmNvbSIgc3ludGF4IGl0IGJlY29tZXMgZGlmZmljdWx0IHRvIGRpZmZlcmVu dGlhdGUgYmV0d2VlbiB0aGUgdXNlciAiZm9vIiBsb2dnaW5nIGludG8gYSB2aXJ0dWFsIGhvc3Qg bmFtZWQgImV4YW1wbGUuY29tIiBvbiBhbiBGVFAgc2VydmVyIHZlcnN1cyB0aGUgdXNlciAiZm9v QGV4YW1wbGUuY29tIiBsb2dnaW5nIGludG8gYW4gRlRQIHNlcnZlciB3aXRoIG5vIHNwZWNpZmll ZCB2aXJ0dWFsIGhvc3QuPC90Pg0KICAgICAgICAgICAgPHQ+V2hlbiB1c2luZyB0aGUgRlRQIHNl Y3VyaXR5IGV4dGVuc2lvbnMgdGhhdCBhcmUgZG9jdW1lbnRlZCBpbiA8eHJlZiB0YXJnZXQ9IlJG QzIyMjgiIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIgLz4gYW5kIDx4cmVmIHRhcmdl dD0iUkZDNDIxNyIgcGFnZW5vPSJmYWxzZSIgZm9ybWF0PSJkZWZhdWx0IiAvPiwgc2VjdXJpdHkg bWVjaGFuaXNtIGFuZCBjZXJ0aWZpY2F0ZSBuZWdvdGlhdGlvbiBtdXN0IG9jY3VyIGJlZm9yZSBs b2dpbiBjcmVkZW50aWFscyBhcmUgc2VudCBieSB0aGUgY2xpZW50LiAgTW9yZSBzcGVjaWZpY2Fs bHksIHRoZSBBVVRIL0FEQVQgY29tbWFuZHMgbXVzdCBiZSBzZW50IGJlZm9yZSB0aGUgVVNFUiBj b21tYW5kIGluIG9yZGVyIHRvIHNhZmVndWFyZCB1c2VyIGNyZWRlbnRpYWxzLiAgSWYgeW91IG92 ZXJsb2FkIHRoZSBVU0VSIGNvbW1hbmQsIHRoZXJlIGlzIG5vIHdheSBvZiBlbnN1cmluZyB0aGF0 IHRoZSBjZXJ0aWZpY2F0ZSBtYXRjaGVzIHRoZSBjb3JyZWN0IHZpcnR1YWwgaG9zdCBiZWZvcmUg dGhlIHVzZXIgY3JlZGVudGlhbHMgYXJlIHNlbnQgYnkgdGhlIGNsaWVudC48L3Q+DQogICAgICAg ICAgPC9saXN0Pg0KICAgICAgICA8L3Q+DQogICAgICA8L3NlY3Rpb24+DQogICAgICA8c2VjdGlv biB0aXRsZT0iQ29uY2x1c2lvbiIgdG9jPSJkZWZhdWx0Ij4NCiAgICAgICAgPHQ+VGhlIGNvbmNs dXNpb24gZnJvbSB0aGUgZXhhbWluYXRpb24gb2YgdGhlIGV4aXN0aW5nIHBvc3NpYmlsaXRpZXMg c2VlbXMgdG8gYmUgdGhhdCBpbiBvcmRlciB0byBvYnRhaW4gYW4gYWRlcXVhdGUgZW11bGF0aW9u IG9mICJyZWFsIiBGVFAgc2VydmVycywgY2xpZW50IGFuZCBzZXJ2ZXIgbW9kaWZpY2F0aW9ucyB0 byBzdXBwb3J0IHZpcnR1YWwgaG9zdHMgYXJlIG5lY2Vzc2FyeS4gIFRoZXJlZm9yZSBhIG5ldyBG VFAgY29tbWFuZCBzZWVtcyB0aGUgbW9zdCBsaWtlbHkgc29sdXRpb24gdG8gcHJvdmlkZSB0aGUg cmVxdWlyZWQgbGV2ZWwgb2Ygc3VwcG9ydC48L3Q+DQogICAgICA8L3NlY3Rpb24+DQogICAgPC9z ZWN0aW9uPg0KICAgIDxzZWN0aW9uIGFuY2hvcj0iQWNrbm93bGVkZ2VtZW50cyIgdGl0bGU9IkFj a25vd2xlZGdlbWVudHMiIHRvYz0iZGVmYXVsdCI+DQogICAgICA8dD5Sb2JlcnQgRWx6IGFuZCBQ YXVsIEhldGhtb24gcHJvdmlkZWQgYSBkZXRhaWxlZCBkaXNjdXNzaW9uIG9mIHRoZSBIT1NUIGNv bW1hbmQgaW4gdGhlaXIgSW50ZXJuZXQgZHJhZnQgdGl0bGVkICJFeHRlbnNpb25zIHRvIEZUUCIg YXMgcGFydCBvZiB0aGVpciB3b3JrIHdpdGggdGhlIEZUUEVYVCBXb3JraW5nIEdyb3VwIGF0IHRo ZSBJRVRGLiAgVGhlaXIgd29yayBmb3JtZWQgdGhlIGJhc2lzIGZvciBtdWNoIG9mIHRoaXMgZG9j dW1lbnQsIGFuZCB0aGVpciBoZWxwIGhhcyBiZWVuIGdyZWF0bHkgYXBwcmVjaWF0ZWQuICBUaGV5 IHdvdWxkIGFsc28gbGlrZSB0byBjcmVkaXQgQmVybmhhcmQgUm9zZW5rcmFlbnplciBmb3IgaGF2 aW5nIGZpcnN0IHN1Z2dlc3RlZCBhbmQgZGVzY3JpYmVkIHRoZSBIT1NUIGNvbW1hbmQuPC90Pg0K ICAgICAgPHQ+QWxleGV5IE1lbG5pa292LCBBbGZyZWQgSG9lbmVzLCBKb2huIEtsZW5zaW4sIGFu ZCBKb2UgVG91Y2ggaGF2ZSBtYWRlIHNldmVyYWwgc3VnZ2VzdGlvbnMgYWJvdXQgZWFybGllciB2 ZXJzaW9ucyBvZiB0aGlzIGRvY3VtZW50OyBtYW55IG9mIHRoZWlyIHN1Z2dlc3Rpb25zIGhhdmUg YmVlbiBpbmNvcnBvcmF0ZWQsIGFuZCB0aGVpciBjb250cmlidXRpb25zIGFyZSBncmF0ZWZ1bGx5 IGFja25vd2xlZGdlZC4gIEluIGFkZGl0aW9uLCBBbGVjIFJvd2VsbCdzIGFzc2lzdGFuY2UgaW4g bWFraW5nIHNlY3Rpb25zIG9mIHRoaXMgZG9jdW1lbnQgbW9yZSByZWFkYWJsZSB3YXMgaW52YWx1 YWJsZS48L3Q+DQogICAgPC9zZWN0aW9uPg0KICA8L2JhY2s+DQo8L3JmYz4= --_003_01AA9EC92749BF4894AC2B3039EA4A2C1949D137CH1PRD0302MB131_ Content-Type: text/plain; name="draft-ietf-ftpext2-hosts-03.txt" Content-Description: draft-ietf-ftpext2-hosts-03.txt Content-Disposition: attachment; filename="draft-ietf-ftpext2-hosts-03.txt"; size=51964; creation-date="Fri, 24 Jun 2011 18:51:55 GMT"; modification-date="Fri, 24 Jun 2011 18:54:34 GMT" Content-Transfer-Encoding: base64 DQoNCg0KRlRQRVhUMiBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBQLiBIZXRobW9uDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEhldGhtb24gQnJvdGhlcnMNClVwZGF0ZXM6IDk1OSAoaWYg YXBwcm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBNY011cnJheQ0K SW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgTWljcm9z b2Z0IENvcnBvcmF0aW9uDQpFeHBpcmVzOiBEZWNlbWJlciAyNiwgMjAxMSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEp1bmUgMjQsIDIwMTENCg0KDQogICAgICAgICBGaWxlIFRyYW5z ZmVyIFByb3RvY29sIEhPU1QgQ29tbWFuZCBmb3IgVmlydHVhbCBIb3N0cw0KICAgICAgICAgICAg ICAgICAgICAgIGRyYWZ0LWlldGYtZnRwZXh0Mi1ob3N0cy0wMw0KDQpBYnN0cmFjdA0KDQogICBU aGUgRmlsZSBUcmFuc2ZlciBQcm90b2NvbCwgYXMgZGVmaW5lZCBpbiBSRkMgOTU5IFtSRkMwOTU5 XSwgZG9lcyBub3QNCiAgIHByb3ZpZGUgYSB3YXkgZm9yIEZUUCBjbGllbnRzIGFuZCBzZXJ2ZXJz IHRvIGRpZmZlcmVudGlhdGUgYmV0d2Vlbg0KICAgbXVsdGlwbGUgRE5TIG5hbWVzIHRoYXQgYXJl IHJlZ2lzdGVyZWQgZm9yIGEgc2luZ2xlIElQIGFkZHJlc3MuICBUaGlzDQogICBkb2N1bWVudCBk ZWZpbmVzIGEgbmV3IEZUUCBjb21tYW5kIHRoYXQgcHJvdmlkZXMgYSBtZWNoYW5pc20gZm9yIEZU UA0KICAgY2xpZW50cyBhbmQgc2VydmVycyB0byBpZGVudGlmeSBpbmRpdmlkdWFsIHZpcnR1YWwg aG9zdHMgb24gYW4gRlRQDQogICBzZXJ2ZXIuDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAg VGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRo IHRoZQ0KICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgSW50ZXJuZXQt RHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcN CiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBk aXN0cmlidXRlDQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUg bGlzdCBvZiBjdXJyZW50IEludGVybmV0LQ0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUg ZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5k IG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50 cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1E cmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhh biBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBl eHBpcmUgb24gRGVjZW1iZXIgMjYsIDIwMTEuDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29w eXJpZ2h0IChjKSAyMDExIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMg dGhlDQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4NCg0KICAgVGhp cyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdh bA0KICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cw0KICAgKGh0dHA6Ly90 cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mDQog ICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1 bWVudHMNCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVz dHJpY3Rpb25zIHdpdGggcmVzcGVjdA0KICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9u ZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QNCiAgIGluY2x1ZGUgU2ltcGxp ZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZg0KDQoN Cg0KSGV0aG1vbiAmIE1jTXVycmF5ICAgICAgRXhwaXJlcyBEZWNlbWJlciAyNiwgMjAxMSAgICAg ICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgRlRQIEhPU1QgQ29tbWFu ZCBmb3IgVmlydHVhbCBIb3N0cyAgICAgICAgICBKdW5lIDIwMTENCg0KDQogICB0aGUgVHJ1c3Qg TGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMNCiAg IGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4NCg0KDQpUYWJsZSBvZiBD b250ZW50cw0KDQogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgIDIuICBEb2N1bWVudCBDb252ZW50aW9ucyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgICAyLjEuICBC YXNpYyBUb2tlbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA0DQogICAgIDIuMi4gIFNlcnZlciBSZXBsaWVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgIDMuICBUaGUgSE9TVCBjb21tYW5kIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgICAzLjEuICBTeW50YXgg b2YgdGhlIEhPU1QgY29tbWFuZCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DQog ICAgIDMuMi4gIEhPU1QgY29tbWFuZCBzZW1hbnRpY3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDgNCiAgICAgICAzLjIuMS4gIFJFSU4gY29tbWFuZCBzZW1hbnRpY3MgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0KICAgICAgIDMuMi4yLiAgVXNlci1QSSB1 c2FnZSBvZiBIT1NUICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICAgICAg My4yLjMuICBTdGF0ZSBEaWFncmFtcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTANCiAgICAgMy4zLiAgSE9TVCBjb21tYW5kIGVycm9ycyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOA0KICAgICAzLjQuICBGRUFUIHJlc3BvbnNlIGZvciBI T1NUIGNvbW1hbmQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5DQogICA0LiAgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTkNCiAgIDUuICBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxOQ0KICAgNi4gIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIwDQogICAgIDYuMS4gIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjANCiAg ICAgNi4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAyMQ0KICAgQXBwZW5kaXggQS4gIFVud29ya2FibGUgQWx0ZXJuYXRpdmVzIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIxDQogICAgIEEuMS4gIE92ZXJsb2FkaW5nIHRo ZSBDV0QgY29tbWFuZCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjENCiAgICAgQS4y LiAgT3ZlcmxvYWRpbmcgdGhlIEFDQ1QgY29tbWFuZCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAyMg0KICAgICBBLjMuICBPdmVybG9hZGluZyB0aGUgVVNFUiBjb21tYW5kIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyDQogICAgIEEuNC4gIENvbmNsdXNpb24gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjMNCiAgIEFwcGVuZGl4IEIu ICBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAy Mw0KICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDI0DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQpIZXRobW9uICYgTWNNdXJyYXkgICAgICBFeHBpcmVzIERlY2VtYmVyIDI2LCAyMDExICAg ICAgICAgICAgICAgW1BhZ2UgMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICBGVFAgSE9TVCBDb21t YW5kIGZvciBWaXJ0dWFsIEhvc3RzICAgICAgICAgIEp1bmUgMjAxMQ0KDQoNCjEuICBJbnRyb2R1 Y3Rpb24NCg0KICAgSXQgaXMgY29tbW9uIG9uIHRoZSBJbnRlcm5ldCBmb3IgbWFueSBETlMgbmFt ZXMgdG8gcmVzb2x2ZSB0byBhDQogICBzaW5nbGUgSVAgYWRkcmVzcy4gIFRoaXMgcHJhY3RpY2Ug aGFzIGludHJvZHVjZWQgdGhlIGNvbmNlcHQgb2YgYQ0KICAgInZpcnR1YWwgaG9zdCIsIHdoZXJl IGEgaG9zdCBhcHBlYXJzIHRvIGV4aXN0IGFzIGFuIGluZGVwZW5kZW50DQogICBlbnRpdHksIGJ1 dCBpbiByZWFsaXR5IHNoYXJlcyBpdHMgcGh5c2ljYWwgcmVzb3VyY2VzIHdpdGggb25lIG9yIG1v cmUNCiAgIHNpbWlsYXIgaG9zdHMuDQoNCiAgIFN1Y2ggYW4gYXJyYW5nZW1lbnQgcHJlc2VudHMg c29tZSBwcm9ibGVtcyBmb3IgRlRQIHNlcnZlcnMsIGFzIGFuIEZUUA0KICAgc2VydmVyIGRpc3Rp bmd1aXNoZXMgaW5jb21pbmcgRlRQIGNvbm5lY3Rpb25zIGJ5IHRoZWlyIElQIGFkZHJlc3NlcywN CiAgIG5vdCB0aGVpciBETlMgbmFtZXMsIGJlY2F1c2UgaG9zdHMgYXJlIHVuaXF1ZWx5IGlkZW50 aWZpZWQgYnkgdGhlaXINCiAgIGFkZHJlc3MgcmF0aGVyIHRoYW4gbmFtZS4gIFRoYXQgaXMsIGFs bCBETlMgbmFtZXMgdGhhdCBzaGFyZSBhbiBJUA0KICAgYWRkcmVzcyBhcmUgaGFuZGxlZCBieSB0 aGUgc2FtZSBGVFAgc2VydmVyIGFuZCBzaGFyZSB0aGUgc2FtZSBOZXR3b3JrDQogICBWaXJ0dWFs IEZpbGUgU3lzdGVtIChOVkZTKS4NCg0KICAgVGhpcyBtZWFucyB0aGF0IGRpZmZlcmVudCB2aXJ0 dWFsIGhvc3RzIGNhbm5vdCBvZmZlciBkaWZmZXJlbnQNCiAgIHZpcnR1YWwgZmlsZSBzeXN0ZW1z IHRvIGNsaWVudHMsIG5vciBjYW4gdGhleSBvZmZlciBkaWZmZXJlbnQNCiAgIGF1dGhlbnRpY2F0 aW9uIHN5c3RlbXMuICBBbnkgc2NoZW1lIHRvIG92ZXJjb21lIHRoaXMgaXNzdWUgbmVlZHMgdG8N CiAgIGluZGljYXRlIG5vdCBvbmx5IHRoZSBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzLCBidXQgYWxz byB0aGUgdmlydHVhbA0KICAgaG9zdCBuYW1lIHRoYXQgaXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBk ZXNpcmVkIHZpcnR1YWwgRlRQIHNlcnZlci4NCiAgIFR5cGljYWwgdXNlci1GVFAgcHJvY2Vzc2Vz IGN1cnJlbnRseSB1c2UgaG9zdG5hbWVzIHRvIHBlcmZvcm0NCiAgIGhvc3RuYW1lIHRvIElQIGFk ZHJlc3MgcmVzb2x1dGlvbiBhbmQgdGhlbiBpZ25vcmUgaG9zdG5hbWVzIGZvciB0aGUNCiAgIHJl c3Qgb2YgdGhlIEZUUCBzZXNzaW9uLCB0aGVyZWZvcmUgYW55IG1lY2hhbmlzbSB0byBvdmVyY29t ZSB0aGlzDQogICBpc3N1ZSB3b3VsZCByZXF1aXJlIG1vZGlmaWNhdGlvbnMgdG8gdGhlIHVzZXIt UEkgYW5kIHNlcnZlci1QSS4NCg0KICAgSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgdGhpcyBzYW1l IHByb2JsZW0gZXhpc3RlZCBmb3IgSFRUUC8xLjAgYXMNCiAgIGRlZmluZWQgaW4gW1JGQzE5NDVd LCBhbmQgd2FzIHJlc29sdmVkIGluIEhUVFAvMS4xIGFzIGRlZmluZWQgaW4NCiAgIFtSRkMyNjE2 XSB0aHJvdWdoIHRoZSBhZGRpdGlvbiBvZiB0aGUgSG9zdCByZXF1ZXN0IGhlYWRlci4gIFRoZSBn b2FsDQogICBvZiB0aGlzIGRvY3VtZW50IGlzIHRvIGJyaW5nIGEgc2ltaWxhciBsZXZlbCBvZiBm ZWF0dXJlIHBhcml0eSB0byBGVFANCiAgIGJ5IGludHJvZHVjaW5nIGEgbmV3IEhPU1QgY29tbWFu ZCB0aGF0IGFsbG93cyB1c2VyLUZUUCBwcm9jZXNzZXMgdG8NCiAgIHNwZWNpZnkgd2hpY2ggdmly dHVhbCBob3N0IHRvIGNvbm5lY3QgdG8gZm9yIGEgc2VydmVyLUZUUCBwcm9jZXNzDQogICB0aGF0 IGlzIGhhbmRsaW5nIHJlcXVlc3RzIGZvciBtdWx0aXBsZSB2aXJ0dWFsIGhvc3RzIG9uIGEgc2lu Z2xlIElQDQogICBhZGRyZXNzLg0KDQoNCjIuICBEb2N1bWVudCBDb252ZW50aW9ucw0KDQogICBU aGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNI QUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZ IiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJl dGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uDQoNCiAgIEluIGV4YW1wbGVzLCAiQz4iIGFu ZCAiUz4iIGluZGljYXRlIGxpbmVzIHNlbnQgYnkgdGhlIGNsaWVudCBhbmQNCiAgIHNlcnZlciwg cmVzcGVjdGl2ZWx5Lg0KDQogICBUaGlzIGRvY3VtZW50IGFsc28gdXNlcyBub3RhdGlvbiBkZWZp bmVkIGluIFtSRkMwOTU5XSBhbmQgW1JGQzExMjNdLg0KICAgSW4gcGFydGljdWxhciwgdGhlIHRl cm1zICJyZXBseSIsICJ1c2VyIiwgIk5WRlMiLCAiTlZUIiwgImZpbGUiLA0KICAgInBhdGhuYW1l IiwgIkZUUCBjb21tYW5kcyIsICJEVFAiLCAidXNlci1GVFAgcHJvY2VzcyIsICJ1c2VyLVBJIiwN CiAgICJ1c2VyLURUUCIsICJzZXJ2ZXItRlRQIHByb2Nlc3MiLCAic2VydmVyLVBJIiwgInNlcnZl ci1EVFAiLCAibW9kZSIsDQoNCg0KDQpIZXRobW9uICYgTWNNdXJyYXkgICAgICBFeHBpcmVzIERl Y2VtYmVyIDI2LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0 ICAgICBGVFAgSE9TVCBDb21tYW5kIGZvciBWaXJ0dWFsIEhvc3RzICAgICAgICAgIEp1bmUgMjAx MQ0KDQoNCiAgICJ0eXBlIiwgImNvbnRyb2wgY29ubmVjdGlvbiIsICJkYXRhIGNvbm5lY3Rpb24i LCBhbmQgIkFTQ0lJIiwgYXJlIGFsbA0KICAgdXNlZCBoZXJlIGFzIGRlZmluZWQgdGhlcmUuDQoN CiAgIFN5bnRheCByZXF1aXJlZCBpcyBkZWZpbmVkIHVzaW5nIHRoZSBBdWdtZW50ZWQgQk5GIGRl ZmluZWQgaW4NCiAgIFtSRkM1MjM0XS4gIFNvbWUgZ2VuZXJhbCBBQk5GIGRlZmluaXRpb25zIGFy ZSByZXF1aXJlZCB0aHJvdWdob3V0IHRoZQ0KICAgZG9jdW1lbnQ7IHRob3NlIHdpbGwgYmUgZGVm aW5lZCBsYXRlciBpbiB0aGlzIHNlY3Rpb24uICBBdCBmaXJzdA0KICAgcmVhZGluZywgaXQgbWF5 IGJlIHdpc2UgdG8gc2ltcGx5IHJlY2FsbCB0aGF0IHRoZXNlIGRlZmluaXRpb25zIGV4aXN0DQog ICBoZXJlLCBhbmQgc2tpcCB0byB0aGUgbmV4dCBzZWN0aW9uLg0KDQoyLjEuICBCYXNpYyBUb2tl bnMNCg0KICAgVGhpcyBkb2N1bWVudCBpbXBvcnRzIHRoZSBjb3JlIGRlZmluaXRpb25zIGdpdmVu IGluIEFwcGVuZGl4IEIgb2YNCiAgIFtSRkM1MjM0XS4gIFRoZXJlIGRlZmluaXRpb25zIHdpbGwg YmUgZm91bmQgZm9yIGJhc2ljIEFCTkYgZWxlbWVudHMNCiAgIGxpa2UgQUxQSEEsIERJR0lULCBT UCwgZXRjLiAgVG8gdGhhdCwgdGhlIGZvbGxvd2luZyB0ZXJtIGlzIGFkZGVkIGZvcg0KICAgdXNl IGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgICAgICAgVENIQVIgPSBWQ0hBUiAvIFNQIC8gSFRBQiAg ICA7IHZpc2libGUgcGx1cyB3aGl0ZSBzcGFjZQ0KDQogICBUaGUgVkNIQVIgKGZyb20gW1JGQzUy MzRdKSBhbmQgVENIQVIgcnVsZXMgZ2l2ZSBiYXNpYyBjaGFyYWN0ZXIgdHlwZXMNCiAgIGZyb20g dmFyeWluZyBzdWItc2V0cyBvZiB0aGUgQVNDSUkgY2hhcmFjdGVyIHNldCBmb3IgdXNlIGluIHZh cmlvdXMNCiAgIGNvbW1hbmRzIGFuZCByZXNwb25zZXMuDQoNCiAgIE5vdGUgdGhhdCBpbiBBQk5G LCBzdHJpbmcgbGl0ZXJhbHMgYXJlIGNhc2UgaW5zZW5zaXRpdmUuICBUaGF0DQogICBjb252ZW50 aW9uIGlzIHByZXNlcnZlZCBpbiB0aGlzIGRvY3VtZW50LCBhbmQgaW1wbGllcyB0aGF0IEZUUA0K ICAgY29tbWFuZHMgYW5kIHBhcmFtZXRlcnMgdGhhdCBhcmUgYWRkZWQgYnkgdGhpcyBzcGVjaWZp Y2F0aW9uIGhhdmUNCiAgIHZhbHVlcyB0aGF0IGNhbiBiZSByZXByZXNlbnRlZCBpbiBhbnkgY2Fz ZS4gIFRoYXQgaXMsICJIT1NUIiBpcyB0aGUNCiAgIHNhbWUgYXMgImhvc3QiLCAiSG9zdCIsICJI b1N0IiwgZXRjLiwgYW5kICJmdHAuZXhhbXBsZS5jb20iIGlzIHRoZQ0KICAgc2FtZSBhcyAiRnRw LkV4YW1wbGUuQ29tIiwgImZUcC5lWGFtcGxlLmNPbSIsIGV0Yy4NCg0KMi4yLiAgU2VydmVyIFJl cGxpZXMNCg0KICAgU2VjdGlvbiA0LjIgb2YgW1JGQzA5NTldIGRlZmluZXMgdGhlIGZvcm1hdCBh bmQgbWVhbmluZyBvZiByZXBsaWVzIGJ5DQogICB0aGUgc2VydmVyLVBJIHRvIEZUUCBjb21tYW5k cyBmcm9tIHRoZSB1c2VyLVBJLiAgVGhvc2UgcmVwbHkNCiAgIGNvbnZlbnRpb25zIGFyZSB1c2Vk IGhlcmUgd2l0aG91dCBjaGFuZ2UuDQoNCiAgICAgICAgZXJyb3ItcmVzcG9uc2UgPSBlcnJvci1j b2RlIFNQICpUQ0hBUiBDUkxGDQogICAgICAgIGVycm9yLWNvZGUgICAgID0gKCI0IiAvICI1Iikg MkRJR0lUDQoNCiAgIEltcGxlbWVudGVycyBzaG91bGQgbm90ZSB0aGF0IHRoZSBBQk5GIHN5bnRh eCAod2hpY2ggd2FzIG5vdCB1c2VkIGluDQogICBbUkZDMDk1OV0pIHVzZWQgaW4gdGhpcyBkb2N1 bWVudCwgYW5kIG90aGVyIEZUUCByZWxhdGVkIGRvY3VtZW50cywNCiAgIHNvbWV0aW1lcyBzaG93 cyByZXBsaWVzIHVzaW5nIHRoZSBvbmUgbGluZSBmb3JtYXQuICBVbmxlc3Mgb3RoZXJ3aXNlDQog ICBleHBsaWNpdGx5IHN0YXRlZCwgdGhhdCBpcyBub3QgaW50ZW5kZWQgdG8gaW1wbHkgdGhhdCBt dWx0aS1saW5lDQogICByZXNwb25zZXMgYXJlIG5vdCBwZXJtaXR0ZWQuICBJbXBsZW1lbnRlcnMg c2hvdWxkIGFzc3VtZSB0aGF0LCB1bmxlc3MNCiAgIHN0YXRlZCB0byB0aGUgY29udHJhcnksIGFu eSByZXBseSB0byBhbnkgRlRQIGNvbW1hbmQgKGluY2x1ZGluZyBRVUlUKQ0KICAgY2FuIGJlIG9m IHRoZSBtdWx0aS1saW5lIGZvcm1hdCBkZXNjcmliZWQgaW4gW1JGQzA5NTldLg0KDQogICBUaHJv dWdob3V0IHRoaXMgZG9jdW1lbnQsIHJlcGxpZXMgd2lsbCBiZSBpZGVudGlmaWVkIGJ5IHRoZSB0 aHJlZQ0KICAgZGlnaXQgY29kZSB0aGF0IGlzIHRoZWlyIGZpcnN0IGVsZW1lbnQuICBUaHVzIHRo ZSB0ZXJtICI1MDAgcmVwbHkiDQoNCg0KDQpIZXRobW9uICYgTWNNdXJyYXkgICAgICBFeHBpcmVz IERlY2VtYmVyIDI2LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVybmV0LURy YWZ0ICAgICBGVFAgSE9TVCBDb21tYW5kIGZvciBWaXJ0dWFsIEhvc3RzICAgICAgICAgIEp1bmUg MjAxMQ0KDQoNCiAgIG1lYW5zIGEgcmVwbHkgZnJvbSB0aGUgc2VydmVyLVBJIHVzaW5nIHRoZSB0 aHJlZSBkaWdpdCBjb2RlICI1MDAiLg0KDQoNCjMuICBUaGUgSE9TVCBjb21tYW5kDQoNCiAgIEEg bmV3IGNvbW1hbmQgIkhPU1QiIGlzIGFkZGVkIHRvIHRoZSBGVFAgY29tbWFuZCBzZXQgdG8gYWxs b3cgdGhlDQogICBzZXJ2ZXItRlRQIHByb2Nlc3MgdG8gZGV0ZXJtaW5lIHRvIHdoaWNoIG9mIHBv c3NpYmx5IG1hbnkgdmlydHVhbA0KICAgaG9zdHMgdGhlIGNsaWVudCB3aXNoZXMgdG8gY29ubmVj dC4gIFRoaXMgY29tbWFuZCBTSE9VTEQgYmUgaXNzdWVkDQogICBiZWZvcmUgdGhlIHVzZXIgaXMg YXV0aGVudGljYXRlZCwgYWxsb3dpbmcgdGhlIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSwNCiAgIGFu ZCBzZXQgb2YgbGVnYWwgdXNlcnMsIHRvIGJlIGRlcGVuZGVudCB1cG9uIHRoZSB2aXJ0dWFsIGhv c3QgY2hvc2VuLg0KICAgU2VydmVyLUZUUCBwcm9jZXNzZXMgU0hPVUxEIHRyZWF0IGEgc2l0dWF0 aW9uIHdoZXJlIHRoZSBIT1NUIGNvbW1hbmQNCiAgIGlzIGlzc3VlZCBhZnRlciB0aGUgdXNlciBo YXMgYmVlbiBhdXRoZW50aWNhdGVkIHVzaW5nIG9uZSBvZiB0aGUNCiAgIGZvbGxvd2luZyB0d28g YmVoYXZpb3JzOg0KDQogICBhLiAgVHJlYXQgdGhlIGxhdGUgSE9TVCBjb21tYW5kIGFzIGFuIGVy cm9uZW91cyBzZXF1ZW5jZSBvZiBjb21tYW5kcw0KICAgICAgIGFuZCByZXR1cm4gYSA1MDMgcmVw bHkuDQoNCiAgIGIuICBUcmVhdCB0aGUgbGF0ZSBIT1NUIGNvbW1hbmQgYXMgdGhvdWdoIGEgUkVJ TiBjb21tYW5kIHdhcyBzZW50DQogICAgICAgYmVmb3JlIHRoZSBIT1NUIGNvbW1hbmQgYW5kIHJl c2V0IHRoZSB1c2VyLVBJIHRvIHRoZSBzdGF0ZSB0aGF0DQogICAgICAgZXhpc3RlZCBhZnRlciB0 aGUgVENQIGNvbm5lY3Rpb24gd2FzIGZpcnN0IGVzdGFibGlzaGVkIGFuZCBiZWZvcmUNCiAgICAg ICB0aGUgaW5pdGlhbCB1c2VyIGF1dGhlbnRpY2F0aW9uIGFuZCB0aGVuIHJldHVybiB0aGUgYXBw cm9wcmlhdGUNCiAgICAgICByZXBseSBmb3IgdGhlIEhPU1QgY29tbWFuZC4NCg0KICAgU2VydmVy cyBzaG91bGQgbm90ZSB0aGF0IHRoZSByZXNwb25zZSB0byB0aGUgSE9TVCBjb21tYW5kIGlzIGEN CiAgIHNlbnNpYmxlIHRpbWUgdG8gc2VuZCB0aGVpciAid2VsY29tZSIgbWVzc2FnZS4gIFRoaXMg YWxsb3dzIHRoZQ0KICAgbWVzc2FnZSB0byBiZSBwZXJzb25hbGl6ZWQgZm9yIGFueSB2aXJ0dWFs IGhvc3RzIHRoYXQgYXJlIHN1cHBvcnRlZCwNCiAgIGFuZCBhbHNvIGFsbG93cyB0aGUgY2xpZW50 IHRvIGRldGVybWluZSB0aGUgc3VwcG9ydGVkIGxhbmd1YWdlcywgb3INCiAgIHJlcHJlc2VudGF0 aW9ucywgZm9yIHRoZSBtZXNzYWdlLCBhbmQgb3RoZXIgbWVzc2FnZXMsIHZpYSB0aGUgRkVBVA0K ICAgcmVzcG9uc2UsIGFuZCBzZWxlY3QgYW4gYXBwcm9wcmlhdGUgb25lIHZpYSB0aGUgTEFORyBj b21tYW5kLiAgU2VlDQogICBbUkZDMjY0MF0gZm9yIG1vcmUgaW5mb3JtYXRpb24uDQoNCjMuMS4g IFN5bnRheCBvZiB0aGUgSE9TVCBjb21tYW5kDQoNCiAgIFRoZSBIT1NUIGNvbW1hbmQgaXMgZGVm aW5lZCBhcyBmb2xsb3dzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkhldGht b24gJiBNY011cnJheSAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjYsIDIwMTEgICAgICAgICAgICAg ICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgIEZUUCBIT1NUIENvbW1hbmQgZm9yIFZp cnR1YWwgSG9zdHMgICAgICAgICAgSnVuZSAyMDExDQoNCg0KICAgICBob3N0LWNvbW1hbmQgID0g IkhPU1QiIFNQIGhvc3RuYW1lIENSTEYNCiAgICAgaG9zdG5hbWUgICAgICA9IGRvbWFpbiAvIElQ LWxpdGVyYWwNCg0KICAgICBkb21haW4gICAgICAgID0gc3ViLWRvbWFpbiAqKCIuIiBzdWItZG9t YWluKQ0KICAgICBzdWItZG9tYWluICAgID0gbGV0LWRpZyBbbGRoLXN0cl0NCiAgICAgbGV0LWRp ZyAgICAgICA9IEFMUEhBIC8gRElHSVQNCiAgICAgbGRoLXN0ciAgICAgICA9ICooIEFMUEhBIC8g RElHSVQgLyAiLSIgKSBsZXQtZGlnDQoNCiAgICAgSVAtbGl0ZXJhbCAgICA9ICggIlsiIElQdjZh ZGRyZXNzICJdIiApIC8gSVB2NGFkZHJlc3MNCg0KICAgICBJUHY2YWRkcmVzcyAgID0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA2KCBoMTYgIjoiICkgbHMzMg0KICAgICAgICAgICAgICAg ICAgICAgLyAgICAgICAgICAgICAgICAgICAgICAgIjo6IiA1KCBoMTYgIjoiICkgbHMzMg0KICAg ICAgICAgICAgICAgICAgICAgLyBbICAgICAgICAgICAgICAgaDE2IF0gIjo6IiA0KCBoMTYgIjoi ICkgbHMzMg0KICAgICAgICAgICAgICAgICAgICAgLyBbICoxKCBoMTYgIjoiICkgaDE2IF0gIjo6 IiAzKCBoMTYgIjoiICkgbHMzMg0KICAgICAgICAgICAgICAgICAgICAgLyBbICoyKCBoMTYgIjoi ICkgaDE2IF0gIjo6IiAyKCBoMTYgIjoiICkgbHMzMg0KICAgICAgICAgICAgICAgICAgICAgLyBb ICozKCBoMTYgIjoiICkgaDE2IF0gIjo6IiAgICBoMTYgIjoiICAgbHMzMg0KICAgICAgICAgICAg ICAgICAgICAgLyBbICo0KCBoMTYgIjoiICkgaDE2IF0gIjo6IiAgICAgICAgICAgICAgbHMzMg0K ICAgICAgICAgICAgICAgICAgICAgLyBbICo1KCBoMTYgIjoiICkgaDE2IF0gIjo6IiAgICAgICAg ICAgICAgaDE2DQogICAgICAgICAgICAgICAgICAgICAvIFsgKjYoIGgxNiAiOiIgKSBoMTYgXSAi OjoiDQoNCiAgICAgbHMzMiAgICAgICAgICA9ICggaDE2ICI6IiBoMTYgKSAvIElQdjRhZGRyZXNz DQogICAgICAgICAgICAgICAgICAgICA7IGxlYXN0LXNpZ25pZmljYW50IDMyIGJpdHMgb2YgYWRk cmVzcw0KDQogICAgIGgxNiAgICAgICAgICAgPSAxKjRIRVhESUcNCiAgICAgICAgICAgICAgICAg ICAgIDsgMTYgYml0cyBvZiBhZGRyZXNzIHJlcHJlc2VudGVkIGluIGhleGFkZWNpbWFsDQoNCiAg ICAgSVB2NGFkZHJlc3MgICA9IGRlYy1vY3RldCAiLiIgZGVjLW9jdGV0ICIuIiBkZWMtb2N0ZXQg Ii4iIGRlYy1vY3RldA0KDQogICAgIGRlYy1vY3RldCAgICAgPSBESUdJVCAgICAgICAgICAgICAg ICAgOyAwLTkNCiAgICAgICAgICAgICAgICAgICAgIC8gJXgzMS0zOSBESUdJVCAgICAgICA7IDEw LTk5DQogICAgICAgICAgICAgICAgICAgICAvICIxIiAyRElHSVQgICAgICAgICAgOyAxMDAtMTk5 DQogICAgICAgICAgICAgICAgICAgICAvICIyIiAleDMwLTM0IERJR0lUICAgOyAyMDAtMjQ5DQog ICAgICAgICAgICAgICAgICAgICAvICIyNSIgJXgzMC0zNSAgICAgICAgOyAyNTAtMjU1DQoNCiAg ICAgaG9zdC1yZXNwb25zZSA9IGhvc3Qtb2sgLyBlcnJvci1yZXNwb25zZQ0KICAgICBob3N0LW9r ICAgICAgID0gIjIyMCIgWyBTUCAqVENIQVIgXSBDUkxGDQoNCiAgIEFzIHdpdGggYWxsIEZUUCBj b21tYW5kcywgdGhlICJIT1NUIiBjb21tYW5kIHdvcmQgaXMgY2FzZQ0KICAgaW5kZXBlbmRlbnQs IGFuZCBNQVkgYmUgc3BlY2lmaWVkIGluIGFueSBjaGFyYWN0ZXIgY2FzZSBkZXNpcmVkLg0KDQog ICBUaGUgImhvc3RuYW1lIiAoZ2l2ZW4gYXMgYSBwYXJhbWV0ZXIpIHNwZWNpZmllcyB0aGUgdmly dHVhbCBob3N0IHRvDQogICB3aGljaCBhY2Nlc3MgaXMgZGVzaXJlZC4gIFRoaXMgU0hPVUxEIGJl IHRoZSBzYW1lIGhvc3QgbmFtZSB0aGF0IHdhcw0KICAgdXNlZCB0byBvYnRhaW4gdGhlIElQIGFk ZHJlc3MgdG8gd2hpY2ggdGhlIEZUUCBjb250cm9sIGNvbm5lY3Rpb24gd2FzDQogICBtYWRlLCBh ZnRlciBhbnkgY2xpZW50IGNvbnZlcnNpb25zIGhhdmUgYmVlbiBjb21wbGV0ZWQgdGhhdCBjb252 ZXJ0DQogICBhbiBhYmJyZXZpYXRlZCBvciBsb2NhbCBhbGlhcyB0byBhIGNvbXBsZXRlIChmdWxs eSBxdWFsaWZpZWQpIGRvbWFpbg0KICAgbmFtZSwgYnV0IGJlZm9yZSByZXNvbHZpbmcgYSBETlMg YWxpYXMgKG93bmVyIG9mIGEgQ05BTUUgcmVzb3VyY2UNCiAgIHJlY29yZCkgdG8gaXRzIGNhbm9u aWNhbCBuYW1lLg0KDQoNCg0KDQpIZXRobW9uICYgTWNNdXJyYXkgICAgICBFeHBpcmVzIERlY2Vt YmVyIDI2LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0LURyYWZ0ICAg ICBGVFAgSE9TVCBDb21tYW5kIGZvciBWaXJ0dWFsIEhvc3RzICAgICAgICAgIEp1bmUgMjAxMQ0K DQoNCiAgIEludGVybmF0aW9uYWxpemF0aW9uIG9mIGRvbWFpbiBuYW1lcyBpcyBvbmx5IHN1cHBv cnRlZCB0aHJvdWdoIHRoZQ0KICAgdXNlIG9mIFB1bnljb2RlIGFzIGRlc2NyaWJlZCBpbiBbUkZD MzQ5Ml0uDQoNCiAgIElmIHRoZSB1c2VyIHdhcyBnaXZlbiBhbiBJUHY0IG9yIElQdjYgbGl0ZXJh bCBhZGRyZXNzLCBhbmQNCiAgIGNvbnNlcXVlbnRseSB3YXMgbm90IHJlcXVpcmVkIHRvIGRlcml2 ZSB0aGUgbGl0ZXJhbCBhZGRyZXNzIGZyb20gYQ0KICAgaG9zdG5hbWUsIHRoZSBjbGllbnQgTUFZ IHNlbmQgdGhlIEhPU1QgY29tbWFuZCB3aXRoIHRoZSBJUHY0IG9yIElQdjYNCiAgIGxpdGVyYWwg YWRkcmVzcyBhcyBzcGVjaWZpZWQgdG8gaXQuICBXaGlsZSBpdCBtYXkgc2VlbSBjb3VudGVyLQ0K ICAgaW50dWl0aXZlIHRvIHNwZWNpZnkgYSBsaXRlcmFsIGFkZHJlc3MgYnkgdXNpbmcgdGhlIEhP U1QgY29tbWFuZA0KICAgYWZ0ZXIgdGhlIGNsaWVudCBoYXMgYWxyZWFkeSBjb25uZWN0ZWQgdG8g dGhlIHNlcnZlciB1c2luZyBhIGxpdGVyYWwNCiAgIGFkZHJlc3MsIHRoaXMgc2hvdWxkIGJlIGV4 cGVjdGVkIGJlaGF2aW9yIGJlY2F1c2UgYSB1c2VyLUZUUCBwcm9jZXNzDQogICBzaG91bGQgbm90 IGJlIHJlcXVpcmVkIHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiBhIGZ1bGx5IHF1YWxpZmllZA0K ICAgZG9tYWluIG5hbWUgYW5kIGFuIElQdjQgb3IgSVB2NiBuZXR3b3JrIGxpdGVyYWwgYWRkcmVz cy4gIFRoYXQgYmVpbmcNCiAgIHNhaWQsIGlmIHRoZSBJUHY0IG9yIElQdjYgbGl0ZXJhbCBhZGRy ZXNzIHNwZWNpZmllZCBieSB0aGUgY2xpZW50DQogICBkb2VzIG5vdCBtYXRjaCB0aGUgbGl0ZXJh bCBhZGRyZXNzIGZvciB0aGUgc2VydmVyLCB0aGUgc2VydmVyIE1VU1QNCiAgIHJlc3BvbmQgd2l0 aCBhIDUwNCByZXBseSB0byBpbmRpY2F0ZSB0aGF0IHRoZSBJUHY0IG9yIElQdjYgbGl0ZXJhbA0K ICAgYWRkcmVzcyBpcyBub3QgdmFsaWQuDQoNCiAgIFdoZW4gdGhlIGhvc3RuYW1lIHBhcmFtZXRl ciBjb250YWlucyBhIGxpdGVyYWwgYWRkcmVzcywgc3F1YXJlDQogICBicmFja2V0cyBhcmUgZXhw ZWN0ZWQgdG8gZGlzYW1iaWd1YXRlIElQdjYgYWRkcmVzcyBzeW50YXggZnJvbSBwb3J0DQogICBu dW1iZXJzIHN5bnRheC4gIFRoZXJlZm9yZSwgaWYgdGhlIGxpdGVyYWwgYWRkcmVzcyBpcyBhbiBJ UHY2DQogICBhZGRyZXNzLCB0aGUgSVB2NiBhZGRyZXNzIGlzIHJlcXVpcmVkIHRvIGJlIGVuY2xv c2VkIGluIHNxdWFyZQ0KICAgYnJhY2tldHMgKGFmdGVyIGVsaW1pbmF0aW5nIGFueSBzeW50YXgg dGhhdCBtaWdodCBhbHNvIC0gYnV0IGlzIG5vdA0KICAgcmVxdWlyZWQgdG8gLSBiZSBlbmNsb3Nl ZCBpbiBicmFja2V0cywgYW5kIGZyb20gd2hpY2ggdGhlIHNlcnZlcg0KICAgZGVkdWNlZCB0aGF0 IGEgbGl0ZXJhbCBhZGRyZXNzIGhhZCBiZWVuIHNwZWNpZmllZC4pICBGb3IgZXhhbXBsZSwgdGhl DQogICBmb2xsb3dpbmcgZXhhbXBsZXMgTUFZIGJlIHNlbnQgaWYgdGhlIGNsaWVudCBoYWQgYmVl biBpbnN0cnVjdGVkIHRvDQogICByZXNwZWN0aXZlbHkgY29ubmVjdCB0byAiMTkyLjAuMi4xIiwg IkZFODA6OmMwMDA6MDIwMSIsIG9yDQogICAiMTkyLjAuMi4xIiBhbmQgSVB2NiBzeW50YXggaXMg cHJlZmVycmVkOg0KDQogICAgICAgIEhPU1QgMTkyLjAuMi4xDQogICAgICAgIEhPU1QgW0ZFODA6 OmMwMDA6MDIwMV0NCiAgICAgICAgSE9TVCBbOjoxOTIuMC4yLjFdDQoNCiAgIFRoZSBjbGllbnQg TVVTVCBOT1Qgc2VuZCB0aGUgcG9ydCBudW1iZXIgYXMgcGFydCBvZiB0aGUgSE9TVCBjb21tYW5k LA0KICAgZXZlbiB3aGVuIHRoZSBjbGllbnQgaGFzIGJlZW4gaW5zdHJ1Y3RlZCB0byBjb25uZWN0 IHRvIGEgbm9uLXN0YW5kYXJkDQogICBwb3J0LiAgVGhlIHJlYXNvbiBmb3IgdGhpcyByZXF1aXJl bWVudCBpcyB0aGF0IHRoZSB1c2VyLVBJIHdpbGwgaGF2ZQ0KICAgZXN0YWJsaXNoZWQgYSBjb25u ZWN0aW9uIHRvIHRoZSBzZXJ2ZXItUEkgYmVmb3JlIHRoZSBIT1NUIGNvbW1hbmQgaXMNCiAgIHNl bnQsIHRoZXJlZm9yZSBzcGVjaWZ5aW5nIGEgZGlmZmVyZW50IHBvcnQgd2l0aCB0aGUgSE9TVCBj b21tYW5kIGhhcw0KICAgbm8gbWVhbmluZy4gIEZvciBleGFtcGxlLCB0aGUgc2VydmVyLVBJIE1V U1QgcmVzcG9uZCB3aXRoIGEgNTAxIHJlcGx5DQogICBpZiB0aGUgY2xpZW50IHNlbmRzIGEgSE9T VCBjb21tYW5kIHdpdGggc3ludGF4IGxpa2UgZWl0aGVyIG9mIHRoZQ0KICAgZm9sbG93aW5nIGV4 YW1wbGVzOg0KDQogICAgICAgIEhPU1QgMTkyLjAuMi4xOjIxMTINCiAgICAgICAgSE9TVCBbRkU4 MDo6YzAwMDowMjAxXToyMTEyDQoNCiAgIFRoZSBob3N0bmFtZSBwYXJhbWV0ZXIgaXMgb3RoZXJ3 aXNlIHRvIGJlIHRyZWF0ZWQgYXMgYSBmdWxseQ0KICAgcXVhbGlmaWVkIGRvbWFpbiBuYW1lIG9y IHJlbGF0aXZlIG5hbWUgYXMgdGhvc2UgdGVybXMgYXJlIGRlZmluZWQgaW4NCiAgIHNlY3Rpb24g My4xIG9mIFtSRkMxMDM0XS4gIFRoaXMgaW1wbGllcyB0aGF0IHRoZSBuYW1lIGlzIHRvIGJlDQog ICB0cmVhdGVkIGFzIGEgY2FzZS1pbmRlcGVuZGVudCBzdHJpbmcsIG1lYW5pbmcgdGhhdCB1cHBl cmNhc2UgQVNDSUkNCg0KDQoNCkhldGhtb24gJiBNY011cnJheSAgICAgIEV4cGlyZXMgRGVjZW1i ZXIgMjYsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg IEZUUCBIT1NUIENvbW1hbmQgZm9yIFZpcnR1YWwgSG9zdHMgICAgICAgICAgSnVuZSAyMDExDQoN Cg0KICAgY2hhcmFjdGVycyBhcmUgdG8gYmUgdHJlYXRlZCBhcyBlcXVpdmFsZW50IHRvIHRoZWly IGNvcnJlc3BvbmRpbmcNCiAgIGxvd2VyY2FzZSBBU0NJSSBjaGFyYWN0ZXJzLCBidXQgb3RoZXJ3 aXNlIHByZXNlcnZlZCBhcyBnaXZlbi4gIEl0DQogICBhbHNvIGltcGxpZXMgc29tZSBsaW1pdHMg b24gdGhlIGxlbmd0aCBvZiB0aGUgcGFyYW1ldGVyIGFuZCBvZiB0aGUNCiAgIGNvbXBvbmVudHMg dGhhdCBjcmVhdGUgaXRzIGludGVybmFsIHN0cnVjdHVyZS4gIFRob3NlIGxpbWl0cyBhcmUgbm90 DQogICBhbHRlcmVkIGluIGFueSB3YXkgaGVyZS4NCg0KICAgTmVpdGhlciBbUkZDMTAzNF0gbm9y IFtSRkMxMDM1XSBpbXBvc2UgYW55IG90aGVyIHJlc3RyaWN0aW9ucyB1cG9uDQogICB3aGF0IGtp bmRzIG9mIG5hbWVzIGNhbiBiZSBzdG9yZWQgaW4gdGhlIEROUy4gIFRoaXMgc3BlY2lmaWNhdGlv biwNCiAgIGhvd2V2ZXIsIG9ubHkgYWxsb3dzIHRoZSB1c2Ugb2YgbmFtZXMgdGhhdCBjYW4gYmUg aW5mZXJyZWQgZnJvbSB0aGUNCiAgIEFCTkYgZ3JhbW1hciBnaXZlbiBmb3IgdGhlICJob3N0bmFt ZSIuDQoNCjMuMi4gIEhPU1QgY29tbWFuZCBzZW1hbnRpY3MNCg0KICAgVXBvbiByZWNlaXZpbmcg dGhlIEhPU1QgY29tbWFuZCwgYmVmb3JlIGF1dGhlbnRpY2F0aW5nIHRoZSB1c2VyLVBJLCBhDQog ICBzZXJ2ZXItRlRQIHByb2Nlc3MgU0hPVUxEIHZhbGlkYXRlIHRoYXQgdGhlIGhvc3RuYW1lIGdp dmVuIHJlcHJlc2VudHMNCiAgIGEgdmFsaWQgdmlydHVhbCBob3N0IGZvciB0aGF0IHNlcnZlciwg YW5kLCBpZiBpdCBpcyB2YWxpZCwgZXN0YWJsaXNoDQogICB0aGUgYXBwcm9wcmlhdGUgZW52aXJv bm1lbnQgZm9yIHRoYXQgdmlydHVhbCBob3N0LiAgVGhlIHJlc3VsdGFudA0KICAgYWN0aW9ucyBu ZWVkZWQgdG8gY3JlYXRlIHRoYXQgZW52aXJvbm1lbnQgYXJlIG5vdCBzcGVjaWZpZWQgaGVyZSwg YW5kDQogICBtYXkgcmFuZ2UgZnJvbSBkb2luZyBub3RoaW5nIGF0IGFsbCwgdG8gcGVyZm9ybWlu ZyBhIHNpbXBsZSBjaGFuZ2Ugb2YNCiAgIHdvcmtpbmcgZGlyZWN0b3J5LCBjaGFuZ2luZyBhdXRo ZW50aWNhdGlvbiBzY2hlbWVzIGFuZC9vciB1c2VybmFtZQ0KICAgYW5kIHBhc3N3b3JkIGxpc3Rz LCBvciBtYWtpbmcgbXVjaCBtb3JlIGVsYWJvcmF0ZSBzdGF0ZSBjaGFuZ2VzIC0NCiAgIHN1Y2gg YXMgY3JlYXRpbmcgaXNvbGF0ZWQgZW52aXJvbm1lbnRzIGZvciBlYWNoIEZUUCBzZXNzaW9uLg0K DQogICBUaGUgIjIyMCIgcmVwbHkgY29kZSBmb3IgdGhlIEhPU1QgY29tbWFuZCBpcyB0aGUgc2Ft ZSBhcyB0aGUgY29kZQ0KICAgdGhhdCBpcyB1c2VkIGluIHRoZSBpbml0aWFsICJ3ZWxjb21lIiBt ZXNzYWdlIHRoYXQgaXMgc2VudCBhZnRlciB0aGUNCiAgIGNvbm5lY3Rpb24gaXMgZXN0YWJsaXNo ZWQuICBUaGlzIHJlcGx5IGNvZGUgaXMgdXNlZCBkZWxpYmVyYXRlbHkgaW4NCiAgIG9yZGVyIHRv IGFsbG93IHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBhIGZyb250LWVuZCBGVFAgc2VydmVyIGFzIGEN CiAgIHdyYXBwZXIsIHdoaWNoIHNpbXBseSB3YWl0cyBmb3IgdGhlIEhPU1QgY29tbWFuZCwgYW5k IHRoZW4gaW52b2tlcyBhDQogICBzZXJ2ZXIgdGhhdCBpcyBjb21wbGlhbnQgd2l0aCBbUkZDMDk1 OV0gaW4gdGhlIGFwcHJvcHJpYXRlDQogICBlbnZpcm9ubWVudCBmb3IgdGhlIHBhcnRpY3VsYXIg aG9zdG5hbWUgcmVjZWl2ZWQuDQoNCiAgIElmIHRoZSBob3N0bmFtZSBzcGVjaWZpZWQgd291bGQg bm9ybWFsbHkgYmUgYWNjZXB0YWJsZSwgYnV0IGZvciBhbnkNCiAgIHJlYXNvbiBpcyB0ZW1wb3Jh cmlseSB1bmF2YWlsYWJsZSwgdGhlIHNlcnZlci1GVFAgcHJvY2VzcyBTSE9VTEQNCiAgIHJlcGx5 IHRvIHRoZSBIT1NUIGNvbW1hbmQgd2l0aCBhIDQyMSByZXBseSBhbmQgY2xvc2UgdGhlIGNvbm5l Y3Rpb24uDQogICBJbiB0aGlzIHBhcnRpY3VsYXIgc2l0dWF0aW9uLCB0aGUgc2VydmVyLUZUUCBw cm9jZXNzIE1BWSBjaG9vc2UgdG8NCiAgIGtlZXAgdGhlIGNvbm5lY3Rpb24gb3BlbiBpbiBvcmRl ciB0byBhbGxvdyB0aGUgdXNlci1QSSBhbiBvcHBvcnR1bml0eQ0KICAgdG8gY2hvb3NlIGFub3Ro ZXIgdmlydHVhbCBob3N0IHdpdGggYSBzdWJzZXF1ZW50IEhPU1QgY29tbWFuZC4NCg0KICAgSWYg dGhlIGhvc3RuYW1lIHNwZWNpZmllZCBpcyB1bmtub3duIGF0IHRoZSBzZXJ2ZXIsIG9yIGlmIHRo ZSBzZXJ2ZXINCiAgIGlzIG90aGVyd2lzZSB1bndpbGxpbmcgdG8gdHJlYXQgdGhlIHBhcnRpY3Vs YXIgY29ubmVjdGlvbiBhcyBhDQogICBjb25uZWN0aW9uIHRvIHRoZSBob3N0bmFtZSBzcGVjaWZp ZWQsIHRoZSBzZXJ2ZXIgU0hPVUxEIHJlc3BvbmQgd2l0aA0KICAgYSA1MDQgcmVwbHkuDQoNCjMu Mi4xLiAgUkVJTiBjb21tYW5kIHNlbWFudGljcw0KDQogICBBcyBzcGVjaWZpZWQgaW4gW1JGQzA5 NTldLCB0aGUgUkVJTiBjb21tYW5kIHJldHVybnMgdGhlIHN0YXRlIG9mIHRoZQ0KICAgY29ubmVj dGlvbiB0byB3aGF0IGl0IHdhcyBpbW1lZGlhdGVseSBhZnRlciB0aGUgdHJhbnNwb3J0IGNvbm5l Y3Rpb24NCiAgIHdhcyBvcGVuZWQuICBUaGlzIHNwZWNpZmljYXRpb24gbWFrZXMgbm8gY2hhbmdl cyB0byB0aGF0IGJlaGF2aW9yLg0KDQoNCg0KSGV0aG1vbiAmIE1jTXVycmF5ICAgICAgRXhwaXJl cyBEZWNlbWJlciAyNiwgMjAxMSAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgRlRQIEhPU1QgQ29tbWFuZCBmb3IgVmlydHVhbCBIb3N0cyAgICAgICAgICBKdW5l IDIwMTENCg0KDQogICBUaGUgZWZmZWN0IG9mIGEgSE9TVCBjb21tYW5kIE1VU1QgYmUgcmVzZXQg aWYgYSBSRUlOIGNvbW1hbmQgaXMNCiAgIHBlcmZvcm1lZCwgYW5kIGEgbmV3IEhPU1QgY29tbWFu ZCBNVVNUIGJlIGlzc3VlZCBpbiBvcmRlciB0byBjb25uZWN0DQogICB0byBhIHZpcnR1YWwgaG9z dC4NCg0KMy4yLjIuICBVc2VyLVBJIHVzYWdlIG9mIEhPU1QNCg0KICAgQSB1c2VyLVBJIHRoYXQg Y29uZm9ybXMgdG8gdGhpcyBzcGVjaWZpY2F0aW9uIE1VU1Qgc2VuZCB0aGUgSE9TVA0KICAgY29t bWFuZCBhZnRlciBvcGVuaW5nIHRoZSB0cmFuc3BvcnQgY29ubmVjdGlvbiwgb3IgYWZ0ZXIgYW55 IFJFSU4NCiAgIGNvbW1hbmQsIGJlZm9yZSBhdHRlbXB0aW5nIHRvIGF1dGhlbnRpY2F0ZSB0aGUg dXNlciB3aXRoIHRoZSBVU0VSDQogICBjb21tYW5kLiAgVGhlIGZvbGxvd2luZyBleGFtcGxlIGls bHVzdHJhdGVzIHdoYXQgYSB0eXBpY2FsIGxvZ2luDQogICBzZXF1ZW5jZSBtaWdodCBsb29rIGxp a2Ugd2hlbiB0aGUgSE9TVCBjb21tYW5kIGlzIHVzZWQ6DQoNCiAgICAgICAgQz4gSE9TVCBmdHAu ZXhhbXBsZS5jb20NCiAgICAgICAgUz4gMjIwIEhvc3QgYWNjZXB0ZWQNCiAgICAgICAgQz4gVVNF UiBmb28NCiAgICAgICAgUz4gMzMxIFBhc3N3b3JkIHJlcXVpcmVkDQogICAgICAgIEM+IFBBU1Mg YmFyDQogICAgICAgIFM+IDIzMCBVc2VyIGxvZ2dlZCBpbg0KDQogICBUaGUgSE9TVCBjb21tYW5k IGNhbiBiZSB1c2VkIGluIGNvbWJpbmF0aW9uIHdpdGggdGhlIEFDQ1QgY29tbWFuZCB0bw0KICAg ZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIGEgdXNlcidzIHZhcmlvdXMgYWNjb3VudHMgb24gYSBzcGVj aWZpYyB2aXJ0dWFsDQogICBob3N0LiAgSW4gdGhpcyBzY2VuYXJpbywgdGhlIHVzZXItUEkgc2Vu ZHMgYSBIT1NUIGNvbW1hbmQgd2hpY2ggdGhlDQogICBzZXJ2ZXItUEkgdXNlcyB0byByb3V0ZSBh Y3Rpdml0eSB0byB0aGUgY29ycmVjdCB2aXJ0dWFsIGhvc3Q7IHRoZQ0KICAgdXNlci1QSSBzZW5k cyBjcmVkZW50aWFscyB1c2luZyB0aGUgVVNFUiBhbmQgUEFTUyBjb21tYW5kcyB3aGljaCB0aGUN CiAgIHNlcnZlci1QSSB2YWxpZGF0ZXM7IHRoZW4sIHRoZSB1c2VyLVBJIHNlbmRzIGFuIEFDQ1Qg Y29tbWFuZCB0bw0KICAgc3BlY2lmeSBhbnkgYWRkaXRpb25hbCBhY2NvdW50IGluZm9ybWF0aW9u IGZvciB0aGUgc2VydmVyLVBJDQogICBpbXBsZW1lbnRhdGlvbi4gIFRoZSBmb2xsb3dpbmcgZXhh bXBsZSBpbGx1c3RyYXRlcyBhIHNlcXVlbnRpYWwNCiAgIHNlcmllcyBvZiBjbGllbnQgY29tbWFu ZHMgdGhhdCBzcGVjaWZ5IGJvdGggYSBIT1NUIGFuZCBBQ0NULCB3aXRoIHRoZQ0KICAgc2VydmVy IHJlc3BvbnNlcyBvbWl0dGVkIGZvciBicmV2aXR5Og0KDQogICAgICAgIEM+IEhPU1QgZnRwLmV4 YW1wbGUuY29tDQogICAgICAgIEM+IFVTRVIgZm9vDQogICAgICAgIEM+IFBBU1MgYmFyDQogICAg ICAgIEM+IEFDQ1QgcHJvamVjdDENCg0KICAgVGhpcyBpcyBhbHNvIHRydWUgd2hlbiB0aGUgSE9T VCBjb21tYW5kIGlzIHVzZWQgd2l0aCB0aGUgQVVUSCBhbmQNCiAgIEFEQVQgY29tbWFuZHMgdGhh dCBhcmUgZGlzY3Vzc2VkIGluIFtSRkMyMjI4XSBhbmQgW1JGQzQyMTddLiAgSW4gdGhpcw0KICAg c2NlbmFyaW8sIHRoZSB1c2VyLVBJIHNlbmRzIGEgSE9TVCBjb21tYW5kIHdoaWNoIHRoZSBzZXJ2 ZXItUEkgdXNlcw0KICAgdG8gcm91dGUgYWN0aXZpdHkgdG8gdGhlIGNvcnJlY3QgdmlydHVhbCBo b3N0LCB0aGVuIHRoZSB1c2VyLVBJIHVzZXMNCiAgIHRoZSBBVVRIIGFuZCBBREFUIGNvbW1hbmRz IHRvIG5lZ290aWF0ZSB0aGUgc2VjdXJpdHkgbWVjaGFuaXNtIGFuZA0KICAgY2VydGlmaWNhdGUg d2l0aCB0aGUgc2VydmVyLVBJLCB0aGVuIHRoZSB1c2VyLVBJIHNlbmRzIHVzZXINCiAgIGNyZWRl bnRpYWxzIHVzaW5nIHRoZSBVU0VSIGFuZCBQQVNTIGNvbW1hbmRzIHdoaWNoIHRoZSBzZXJ2ZXIt UEkNCiAgIHZhbGlkYXRlcy4gIEFmdGVyIHdoaWNoIHRoZSB1c2VyLVBJIE1BWSBzZW5kIGFuIEFD Q1QgY29tbWFuZCB0bw0KICAgc3BlY2lmeSBhbnkgYWRkaXRpb25hbCBhY2NvdW50IGluZm9ybWF0 aW9uIGZvciB0aGUgc2VydmVyLVBJDQogICBpbXBsZW1lbnRhdGlvbi4gIFRoZSBmb2xsb3dpbmcg ZXhhbXBsZSBpbGx1c3RyYXRlcyBhIHNlcXVlbnRpYWwNCiAgIHNlcmllcyBvZiBjbGllbnQgY29t bWFuZHMgdGhhdCBzcGVjaWZ5IGJvdGggYSBIT1NUIGFuZCBBQ0NUIHdoZW4gdXNlZA0KICAgaW4g Y29uanVuY3Rpb24gd2l0aCB0aGUgc2VjdXJpdHkgY29tbWFuZHMgdGhhdCBhcmUgZGlzY3Vzc2Vk IGluDQogICBbUkZDMjIyOF0gYW5kIFtSRkM0MjE3XSwgd2l0aCB0aGUgc2VydmVyIHJlc3BvbnNl cyBvbWl0dGVkIGZvcg0KDQoNCg0KSGV0aG1vbiAmIE1jTXVycmF5ICAgICAgRXhwaXJlcyBEZWNl bWJlciAyNiwgMjAxMSAgICAgICAgICAgICAgIFtQYWdlIDldDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgRlRQIEhPU1QgQ29tbWFuZCBmb3IgVmlydHVhbCBIb3N0cyAgICAgICAgICBKdW5lIDIwMTEN Cg0KDQogICBicmV2aXR5Og0KDQogICAgICAgIEM+IEhPU1QgZnRwLmV4YW1wbGUuY29tDQogICAg ICAgIEM+IEFVVEggPG1lY2hhbmlzbS1uYW1lPg0KICAgICAgICBDPiBBREFUIDxiYXNlNjRkYXRh Pg0KICAgICAgICBDPiBVU0VSIGZvbw0KICAgICAgICBDPiBQQVNTIGJhcg0KICAgICAgICBDPiBB Q0NUIHByb2plY3QxDQoNCjMuMi4zLiAgU3RhdGUgRGlhZ3JhbXMNCg0KICAgVGhlIHN0YXRlIGRp YWdyYW1zIGluIHRoaXMgc2VjdGlvbiBpbGx1c3RyYXRlIHR5cGljYWwgc2VxdWVuY2VzIGZvcg0K ICAgY29tbWFuZCBhbmQgcmVwbHkgaW50ZXJjaGFuZ2UgYmV0d2VlbiB0aGUgdXNlci1QSSBhbmQg c2VydmVyLVBJLg0KICAgVGhlc2UgZGlhZ3JhbXMgYXJlIG1vZGVsZWQgb24gdGhlIHNpbWlsYXIg ZGlhZ3JhbXMgaW4gc2VjdGlvbiA2IG9mDQogICBbUkZDMDk1OV0uDQoNCiAgIEluIGVhY2ggZGlh Z3JhbSwgdGhlIChCKSAiYmVnaW4iIHN0YXRlIGlzIGFzc3VtZWQgdG8gb2NjdXIgYWZ0ZXIgdGhl DQogICB0cmFuc3BvcnQgY29ubmVjdGlvbiBoYXMgb3BlbmVkLCBvciBhZnRlciBhIFJFSU4gY29t bWFuZCBoYXMNCiAgIHN1Y2NlZWRlZC4gIE90aGVyIGNvbW1hbmRzIChzdWNoIGFzIEZFQVQgW1JG QzIzODldKSB0aGF0IHJlcXVpcmUgbm8NCiAgIGF1dGhlbnRpY2F0aW9uIG1heSBoYXZlIGludGVy dmVuZWQuDQoNCiAgIEFkZGl0aW9uYWxseSwgYSB0aHJlZS1kaWdpdCByZXBseSBpbmRpY2F0ZXMg YSBwcmVjaXNlIHNlcnZlciByZXBseQ0KICAgY29kZS4gIEEgc2luZ2xlIGRpZ2l0IG9uIGEgcmVw bHkgcGF0aCBpbmRpY2F0ZXMgYW55IHNlcnZlciByZXBseSB0aGF0DQogICBiZWdpbnMgd2l0aCB0 aGF0IGRpZ2l0LCBleGNlcHQgd2hlcmUgYSBwcmVjaXNlIHNlcnZlciByZXBseSBjb2RlIGlzDQog ICBkZWZpbmVkIG9uIGFub3RoZXIgcGF0aC4gIEZvciBleGFtcGxlLCBhIHNpbmdsZSBkaWdpdCAi NSIgd2lsbCBhcHBseQ0KICAgdG8gIjUwMCIsICI1MDEiLCAiNTAyIiwgZXRjLiwgd2hlbiB0aG9z ZSByZXBseSBjb2RlcyBhcmUgbm90DQogICBleHByZXNzbHkgZGVmaW5lZCBpbiB0aGUgZGlhZ3Jh bS4gIEZvciBlYWNoIGNvbW1hbmQgdGhlcmUgYXJlIHRocmVlDQogICBwb3NzaWJsZSBvdXRjb21l czogc3VjY2VzcyAoUyksIGZhaWx1cmUgKEYpLCBhbmQgZXJyb3IgKEUpLiAgSW4gdGhlDQogICBz dGF0ZSBkaWFncmFtcyBiZWxvdyB3ZSB1c2UgdGhlIHN5bWJvbCBCIGZvciAiYmVnaW4iLCBhbmQg dGhlIHN5bWJvbA0KICAgVyBmb3IgIndhaXQgZm9yIHJlcGx5Ii4NCg0KICAgSW4gZWFjaCBvZiB0 aGVzZSBkaWFncmFtcywgYSBSRUlOIGNvbW1hbmQgd2lsbCByZXR1cm4gdGhlIGRpYWdyYW0gdG8N CiAgIHRoZSAoQikgImJlZ2luIiBzdGF0ZS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCkhldGhtb24gJiBNY011cnJheSAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjYsIDIwMTEg ICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgIEZUUCBIT1NUIENv bW1hbmQgZm9yIFZpcnR1YWwgSG9zdHMgICAgICAgICAgSnVuZSAyMDExDQoNCg0KICAgVGhlIHN0 YXRlIGRpYWdyYW0gaW4gRmlndXJlIDEgc2hvd3MgYSB0eXBpY2FsIHNlcXVlbmNlIG9mIGZsb3cg b2YNCiAgIGNvbnRyb2wgd2hlbiBIT1NUIGlzIHVzZWQgd2l0aCBVU0VSIGFuZCBQQVNTIHRvIGxv ZyBpbiB0byBhDQogICBwYXJ0aWN1bGFyIEZUUCB2aXJ0dWFsIGhvc3QuDQoNCiAgICAgICAgICAg ICAgKy0tLSsgICBIT1NUICAgICstLS0rIDEsMyw1DQogICAgICAgICAgICAgIHwgQiB8LS0tLS0t LS0tLT58IFcgfC0tLS0tLS0tLS0tLS0tLS0tDQogICAgICAgICAgICAgICstLS0rICAgICAgICAg ICArLS0tKyAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgfCAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgIDIsNTAwLDUwMiB8 IHwgNCw1MDEsNTAzLDUwNCAgICB8DQogICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tICAg LS0tLS0tLS0tLS0tICAgICAgfA0KICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgIHwNCiAgICAgICAgICAgICAgICBWICAgICAgICAgICAgICAgICAgIDEg ICAgICAgICB8ICAgICBWDQogICAgICAgICAgICAgICstLS0rICAgVVNFUiAgICArLS0tKy0tLS0t LS0tLS0tLS0tPistLS0rDQogICAgICAgICAgICAgIHwgICB8LS0tLS0tLS0tLT58IFcgfCAyICAg ICAgICAgfCAgIHwgRSB8DQogICAgICAgICAgICAgICstLS0rICAgICAgICAgICArLS0tKy0tLS0t LSAgIC0tLS0tPistLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB8ICAgICAg IHwgfCAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAzIHwgfCA0LDUgICB8IHwgIHwN CiAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0gICAtLS0tLSAgfCB8ICB8DQogICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICB8IHwgfCAgfA0KICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgLS0tLS0tLS0tLSAgIHwNCiAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAxfCAgICAgIHwgfCAgICB8DQogICAgICAgICAgICAgICAgViAgICAgICAgICAgICAg IHwgICAgICB8ICAtLS0tLS0tPistLS0rDQogICAgICAgICAgICAgICstLS0rICAgUEFTUyAgICAr LS0tKyAyICB8ICAgICAgfCAgIHwgUyB8DQogICAgICAgICAgICAgIHwgICB8LS0tLS0tLS0tLT58 IFcgfC0tLS0tLS0tLS0tLS0tPistLS0rDQogICAgICAgICAgICAgICstLS0rICAgICAgICAgICAr LS0tKyAgICB8ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg fCAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDQsNSAgIHwgICAgICB8 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICAgICAgIC0tPistLS0r DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgLS0tLS0tLS0tPnwgRiB8 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLS0tPistLS0r DQoNCiAgICAgICAgICAgIEZpZ3VyZSAxOiBUeXBpY2FsIGxvZ2luIHNlcXVlbmNlIHdpdGggSE9T VCBjb21tYW5kDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkhldGhtb24g JiBNY011cnJheSAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjYsIDIwMTEgICAgICAgICAgICAgIFtQ YWdlIDExXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgIEZUUCBIT1NUIENvbW1hbmQgZm9yIFZpcnR1 YWwgSG9zdHMgICAgICAgICAgSnVuZSAyMDExDQoNCg0KICAgVGhlIHN0YXRlIGRpYWdyYW0gaW4g RmlndXJlIDIgc2hvd3MgdGhlIGZsb3cgb2YgY29udHJvbCB3aGVuIGEgSE9TVA0KICAgY29tbWFu ZCBpcyBzZW50IGFmdGVyIGEgdXNlciBoYXMgYWxyZWFkeSBzdWNjZXNzZnVsbHkgbG9nZ2VkIGlu IHRvIGENCiAgIHZpcnR1YWwgaG9zdCB3aXRoIFVTRVIgYW5kIFBBU1MuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICArLS0tKyAgIEhPU1QgICAgKy0t LSsgMSwzLDUgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICB8IEIgfC0tLS0t LS0tLS0+fCBXIHwtLS0tLS0tLS0tLS0tLS0tLSAgICAgICAgICAgfA0KICAgICAgICAgICAgICAr LS0tKyAgICAgICAgICAgKy0tLSsgICAgICAgICAgICAgICAgIHwgICAgICAgICAgfA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgfCAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg fA0KICAgICAgICAgICAgICAgICAgICAgMiw1MDAsNTAyIHwgfCA0LDUwMSw1MDMsNTA0ICAgIHwg ICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgIC0tLS0tLS0tLS0t LSAgICAgIHwgICAgICAgICAgfA0KICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgIHwgICAgICAgICAgfA0KICAgICAgICAgICAgICAgIFYgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgIHwgICAgIFYgICAgICAgICAgfA0KICAgICAgICAgICAgICArLS0t KyAgIFVTRVIgICAgKy0tLSstLS0tLS0tLS0tLS0tLT4rLS0tKyAgICAgICAgfA0KICAgICAgICAg ICAgICB8ICAgfC0tLS0tLS0tLS0+fCBXIHwgMiAgICAgICAgIHwgICB8IEUgfCAgICAgICAgfA0K ICAgICAgICAgICAgICArLS0tKyAgICAgICAgICAgKy0tLSstLS0tLS0gICAtLS0tLT4rLS0tKyAg ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgfCAgICAgICB8IHwgIHwg ICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAzIHwgfCA0LDUg ICB8IHwgIHwgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0t LSAgIC0tLS0tICB8IHwgIHwgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgfCB8IHwgIHwgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgLS0tLS0tLS0tLSAgIHwgICAgICAgICAgICAgICAgfA0KICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgfCB8ICAgIHwgICAgICAgICAgICAg ICAgfA0KICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIDF8ICAgICAgfCB8ICAgIHwgICAg ICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgIFYgICAgICAgICAgICAgICB8ICAgICAgfCAg LS0tLS0tLT4rLS0tKyAgSE9TVCAgfA0KICAgICAgICAgICAgICArLS0tKyAgIFBBU1MgICAgKy0t LSsgMiAgfCAgICAgIHwgICB8IFMgfC0tLS0tLS0tDQogICAgICAgICAgICAgIHwgICB8LS0tLS0t LS0tLT58IFcgfC0tLS0tLS0tLS0tLS0tPistLS0rDQogICAgICAgICAgICAgICstLS0rICAgICAg ICAgICArLS0tKyAgICB8ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgfCAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDQsNSAgIHwg ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICAgICAgfA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgfCAgICAgICAtLT4rLS0tKw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIC0tLS0tLS0tLT58IEYgfA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLT4rLS0tKw0K DQogICAgICAgICAgICBGaWd1cmUgMjogTG9naW4gc2VxdWVuY2Ugd2l0aCByZXBlYXRlZCBIT1NU IGNvbW1hbmQNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KSGV0aG1vbiAmIE1jTXVycmF5ICAg ICAgRXhwaXJlcyBEZWNlbWJlciAyNiwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgRlRQIEhPU1QgQ29tbWFuZCBmb3IgVmlydHVhbCBIb3N0cyAgICAg ICAgICBKdW5lIDIwMTENCg0KDQogICBBZnRlciBhIHVzZXIgaGFzIGxvZ2dlZCBpbiwgYW4gYWRk aXRpb25hbCBhY2NvdW50IG1heSBiZSByZXF1aXJlZCBieQ0KICAgdGhlIHNlcnZlciBhbmQgc3Bl Y2lmaWVkIGJ5IHRoZSBjbGllbnQgYnkgdXNpbmcgQUNDVCBjb21tYW5kLiAgV2l0aA0KICAgdGhp cyBpbiBtaW5kLCB0aGUgc3RhdGUgZGlhZ3JhbSBpbiBGaWd1cmUgMyBzaG93cyBhIHR5cGljYWwg c2VxdWVuY2UNCiAgIG9mIGZsb3cgb2YgY29udHJvbCB3aGVuIEhPU1QgaXMgdXNlZCB3aXRoIFVT RVIgYW5kIFBBU1MgdG8gbG9nIGluIHRvDQogICBhbiBGVFAgdmlydHVhbCBob3N0IGFuZCBBQ0NU IGlzIHVzZWQgdG8gc3BlY2lmeSBhbiBhY2NvdW50Lg0KDQogICAgICAgICAgICAgICstLS0rICAg SE9TVCAgICArLS0tKyAxLDMsNQ0KICAgICAgICAgICAgICB8IEIgfC0tLS0tLS0tLS0+fCBXIHwt LS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgICAgICArLS0tKyAgICAgICAgICAgKy0tLSsgICAg ICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwgICAgICAg ICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAyLDUwMCw1MDIgfCB8IDQsNTAxLDUw Myw1MDQgICAgfA0KICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgIC0tLS0tLS0tLS0t LS0gICAgIHwNCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICB8DQogICAgICAgICAgICAgICAgViAgICAgICAgICAgICAgICAgICAxICAgICAgICAgIHwg ICAgVg0KICAgICAgICAgICAgICArLS0tKyAgIFVTRVIgICAgKy0tLSstLS0tLS0tLS0tLS0tLT4r LS0tKw0KICAgICAgICAgICAgICB8ICAgfC0tLS0tLS0tLS0+fCBXIHwgMiAgICAgICAtLS0tLT58 IEUgfA0KICAgICAgICAgICAgICArLS0tKyAgICAgICAgICAgKy0tLSstLS0tLS0gIHwgIC0tLT4r LS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgfCAgICAgICB8IHwgfCB8DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDMgfCB8IDQsNSAgIHwgfCB8IHwNCiAgICAgICAg ICAgICAgICAgLS0tLS0tLS0tLS0tLS0gICAtLS0tLSAgfCB8IHwgfA0KICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgfCB8IHwgfCB8DQogICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICB8IHwgfCB8IHwNCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgIC0tLS0tLS0tLS0gIHwgfA0KICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIDF8ICAg ICAgfCB8ICAgfCB8DQogICAgICAgICAgICAgICAgViAgICAgICAgICAgICAgIHwgICAgICB8IHwg ICB8IHwNCiAgICAgICAgICAgICAgKy0tLSsgICBQQVNTICAgICstLS0rIDIgIHwgIC0tLS0tLS0+ Ky0tLSsNCiAgICAgICAgICAgICAgfCAgIHwtLS0tLS0tLS0tPnwgVyB8LS0tLS0tLS0tLS0tLS0+ fCBTIHwNCiAgICAgICAgICAgICAgKy0tLSsgICAgICAgICAgICstLS0rICAgLS0tLS0tLS0tLS0+ Ky0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwgICB8IHwgICAgIHwgfA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAzIHwgfDQsNXwgfCAgICAgfCB8DQogICAgICAg ICAgICAgICAgIC0tLS0tLS0tLS0tLS0tICAgLS0tLS0tLS0gICB8ICAtLS0tDQogICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgfCB8ICB8ICB8ICAgICAgfA0KICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgIHwgfCAgfCAgfCAgICAgIHwNCiAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLSAgICAgICB8DQogICAgICAgICAgICAgICAg fCAgICAgICAgICAgIDEsM3wgICAgfCB8ICB8ICAgICAgICAgfA0KICAgICAgICAgICAgICAgIFYg ICAgICAgICAgICAgICB8ICAgMnwgfCAgfCAgICAgICAgIFYNCiAgICAgICAgICAgICAgKy0tLSsg ICBBQ0NUICAgICstLS0rLS0gIHwgICAtLS0tLS0+Ky0tLSsNCiAgICAgICAgICAgICAgfCAgIHwt LS0tLS0tLS0tPnwgVyB8IDQsNSAtLS0tLS0tLS0+fCBGIHwNCiAgICAgICAgICAgICAgKy0tLSsg ICAgICAgICAgICstLS0rLS0tLS0tLS0tLS0tLS0+Ky0tLSsNCg0KICAgICAgICAgICBGaWd1cmUg MzogTG9naW4gc2VxdWVuY2Ugd2l0aCBIT1NUIGFuZCBBQ0NUIGNvbW1hbmRzDQoNCg0KDQoNCg0K DQoNCg0KDQoNCkhldGhtb24gJiBNY011cnJheSAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjYsIDIw MTEgICAgICAgICAgICAgIFtQYWdlIDEzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgIEZUUCBIT1NU IENvbW1hbmQgZm9yIFZpcnR1YWwgSG9zdHMgICAgICAgICAgSnVuZSAyMDExDQoNCg0KICAgV2hl biB0aGUgSE9TVCBjb21tYW5kIGlzIHVzZWQgaW4gY29tYmluYXRpb24gd2l0aCB0aGUgRlRQIHNl Y3VyaXR5DQogICBleHRlbnNpb25zIHRoYXQgd2VyZSBpbnRyb2R1Y2VkIGluIFtSRkMyMjI4XSwg aXQgU0hPVUxEIHByZWNlZGUgdGhlDQogICBzZWN1cml0eSBoYW5kc2hha2UuICBUaGlzIGFsbG93 cyBib3RoIHVzZXItUEkgYW5kIHNlcnZlci1GVFANCiAgIHByb2Nlc3NlcyB0byBtYXAgYW4gRlRQ IEhPU1QgdG8gc2VjdXJpdHkgZGF0YSBhcHByb3ByaWF0ZWx5LiAgVGhlDQogICBzdGF0ZSBkaWFn cmFtIGluIEZpZ3VyZSA0IHNob3dzIGEgdHlwaWNhbCBzZXF1ZW5jZSBvZiBmbG93IG9mIGNvbnRy b2wNCiAgIHdoZW4gSE9TVCBpcyB1c2VkIHdpdGggdGhlIEFVVEggYW5kIEFEQVQgY29tbWFuZHMg dGhhdCBhcmUgZGlzY3Vzc2VkDQogICBpbiBbUkZDMjIyOF0uDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KSGV0aG1vbiAmIE1jTXVycmF5ICAgICAgRXhwaXJlcyBEZWNlbWJlciAyNiwg MjAxMSAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgRlRQIEhP U1QgQ29tbWFuZCBmb3IgVmlydHVhbCBIb3N0cyAgICAgICAgICBKdW5lIDIwMTENCg0KDQogICAg ICAgICAgICAgICstLS0rICAgSE9TVCAgICArLS0tKyAxLDMsNQ0KICAgICAgICAgICAgICB8IEIg fC0tLS0tLS0tLS0+fCBXIHwtLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgICAgICAgKy0tLSsg ICAgICAgICAgICstLS0rICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgfCAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAy LDUwMCw1MDIgfCB8IDQsNTAxLDUwMyw1MDQgICAgIHwNCiAgICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLS0gICAtLS0tLS0tLS0tLS0tICAgICAgfA0KICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICB8DQogICAgICAgICAgICAgICAgViAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgIHwNCiAgICAgICAgICAgICAgKy0tLSsgICBBVVRI ICAgICstLS0rIDQsNSAgICAgICAgfCAgICAgfA0KICAgICAgICAgICAgICB8ICAgfC0tLS0tLS0t LS0+fCBXIHwtLS0tLS0tLS0tLT58ICAgICB8DQogICAgICAgICAgICAgICstLS0rICAgICAgICAg ICArLS0tKyAgICAgICAgICAgIHwgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgMjM0 IHwgfCAgICAgICAgICAgICAgfCAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0t ICB8IDMzNCAgICAgICAgICB8ICAgICB8DQogICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg IHwgICAgICAgICAgICAgIHwgICAgIHwNCiAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0t fC0tLS0tLS0gICAgICAgfCAgICAgfA0KICAgICAgICAgICAgICAgIHwgICB8ICAgICAgICAgICB8 ICAgICAgIHwgICAgICB8ICAgICB8DQogICAgICAgICAgICAgICAgViAgIHwgICAgICAgICAgIFYg IDMzNSAgfCAgICAgIHwgICAgIHwNCiAgICAgICAgICAgICAgKy0tLSsgfCBBREFUICAgICstLS0r LS0tLS0gICAgICAgfCAgICAgfA0KICAgICAgICAgICAgICB8ICAgfC0tLS0tLS0tLS0+fCBXIHwg NCw1ICAgICAgICB8ICAgICB8DQogICAgICAgICAgICAgICstLS0rIHwgICAgICAgICArLS0tKy0t LS0tLS0tLS0tPnwgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAg ICAgICAgICAgfCAgICAgfA0KICAgICAgICAgICAgICAgIC0tLS0gICAgICAgICAyMzV8ICAgICAg ICAgICAgICB8ICAgICB8DQogICAgICAgICAgICAgICB8ICAtLS0tLS0tLS0tLS0tLSAgICAgICAg ICAgICAgIHwgICAgIHwNCiAgICAgICAgICAgICAgIHwgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgfA0KICAgICAgICAgICAgICAgViBWICAgICAgICAgICAgICAgICAgMSAgICAg ICAgICB8ICAgICBWDQogICAgICAgICAgICAgICstLS0rICAgVVNFUiAgICArLS0tKy0tLS0tLS0t LS0tLS0tLT4rLS0tKw0KICAgICAgICAgICAgICB8ICAgfC0tLS0tLS0tLS0+fCBXIHwgMiAgICAg ICAgICB8ICAgfCBFIHwNCiAgICAgICAgICAgICAgKy0tLSsgICAgICAgICAgICstLS0rLS0tLS0t LSAgIC0tLS0tPistLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB8ICAgICAg ICB8IHwgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMyB8IHwgNCw1ICAgIHwgfCAg fA0KICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgIC0tLS0tLSAgfCB8ICB8DQogICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgfCB8IHwgIHwNCiAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tICAgfA0KICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgIDF8ICAgICAgIHwgfCAgICB8DQogICAgICAgICAgICAgICAgViAgICAgICAg ICAgICAgIHwgICAgICAgfCAgLS0tLS0tLT4rLS0tKw0KICAgICAgICAgICAgICArLS0tKyAgIFBB U1MgICAgKy0tLSsgMiAgIHwgICAgICB8ICAgfCBTIHwNCiAgICAgICAgICAgICAgfCAgIHwtLS0t LS0tLS0tPnwgVyB8LS0tLS0tLS0tLS0tLS0tPistLS0rDQogICAgICAgICAgICAgICstLS0rICAg ICAgICAgICArLS0tKyAgICAgfCAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICB8ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDQs NSAgIHwgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgfCAg ICAgICAtLT4rLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAt LS0tLS0tLS0+fCBGIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tLS0t LS0tLS0tLS0tPistLS0rDQoNCiAgICAgICAgIEZpZ3VyZSA0OiBMb2dpbiBzZXF1ZW5jZSB3aXRo IEhPU1QgYW5kIEFVVEgvQURBVCBjb21tYW5kcw0KDQogICBBZnRlciBhIHVzZXIgaGFzIGxvZ2dl ZCBpbiB3aXRoIHRoZSBzZWN1cml0eSBjb21tYW5kcyB0aGF0IGFyZQ0KICAgZGlzY3Vzc2VkIGlu IFtSRkMyMjI4XSwgYW4gYWRkaXRpb25hbCBhY2NvdW50IG1heSBiZSByZXF1aXJlZCBieSB0aGUN Cg0KDQoNCkhldGhtb24gJiBNY011cnJheSAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjYsIDIwMTEg ICAgICAgICAgICAgIFtQYWdlIDE1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgIEZUUCBIT1NUIENv bW1hbmQgZm9yIFZpcnR1YWwgSG9zdHMgICAgICAgICAgSnVuZSAyMDExDQoNCg0KICAgc2VydmVy IGFuZCBzcGVjaWZpZWQgYnkgdGhlIGNsaWVudCBieSB1c2luZyBBQ0NUIGNvbW1hbmQuICBUaGUg c3RhdGUNCiAgIGRpYWdyYW0gaW4gRmlndXJlIDUgc2hvd3MgYSB0eXBpY2FsIHNlcXVlbmNlIG9m IGZsb3cgb2YgY29udHJvbCB3aGVuDQogICBIT1NUIGlzIHVzZWQgd2l0aCB0aGUgQVVUSCBhbmQg QURBVCBjb21tYW5kcyB0byBsb2cgaW4gdG8gYW4gRlRQDQogICB2aXJ0dWFsIGhvc3QgYW5kIEFD Q1QgaXMgdXNlZCB0byBzcGVjaWZ5IGFuIGFjY291bnQuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KSGV0aG1vbiAmIE1jTXVycmF5ICAgICAgRXhwaXJlcyBEZWNlbWJlciAy NiwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMTZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgRlRQ IEhPU1QgQ29tbWFuZCBmb3IgVmlydHVhbCBIb3N0cyAgICAgICAgICBKdW5lIDIwMTENCg0KDQog ICAgICAgICAgICAgICstLS0rICAgSE9TVCAgICArLS0tKyAxLDMsNQ0KICAgICAgICAgICAgICB8 IEIgfC0tLS0tLS0tLS0+fCBXIHwtLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgICAgICAgKy0t LSsgICAgICAgICAgICstLS0rICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgfCAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAg ICAyLDUwMCw1MDIgfCB8IDQsNTAxLDUwMyw1MDQgICAgIHwNCiAgICAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLS0gICAtLS0tLS0tLS0tLS0tLSAgICAgfA0KICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICB8DQogICAgICAgICAgICAgICAgViAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIHwNCiAgICAgICAgICAgICAgKy0tLSsgICBB VVRIICAgICstLS0rIDQsNSAgICAgICAgIHwgICAgfA0KICAgICAgICAgICAgICB8ICAgfC0tLS0t LS0tLS0+fCBXIHwtLS0tLS0tLS0tLS0+fCAgICB8DQogICAgICAgICAgICAgICstLS0rICAgICAg ICAgICArLS0tKyAgICAgICAgICAgICB8ICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg MjM0IHwgfCAgICAgICAgICAgICAgIHwgICAgfA0KICAgICAgICAgICAgICAgICAgICAgLS0tLS0t LS0tICB8IDMzNCAgICAgICAgICAgfCAgICB8DQogICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgIHwgICAgICAgICAgICAgICB8ICAgIHwNCiAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0t LS0tfC0tLS0tLS0gICAgICAgIHwgICAgfA0KICAgICAgICAgICAgICAgIHwgICB8ICAgICAgICAg ICB8ICAgICAgIHwgICAgICAgfCAgICB8DQogICAgICAgICAgICAgICAgViAgIHwgICAgICAgICAg IFYgIDMzNSAgfCAgICAgICB8ICAgIHwNCiAgICAgICAgICAgICAgKy0tLSsgfCBBREFUICAgICst LS0rLS0tLS0gICAgICAgIHwgICAgfA0KICAgICAgICAgICAgICB8ICAgfC0tLS0tLS0tLS0+fCBX IHwgNCw1ICAgICAgICAgfCAgICB8DQogICAgICAgICAgICAgICstLS0rIHwgICAgICAgICArLS0t Ky0tLS0tLS0tLS0tLT58ICAgIHwNCiAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfCAg ICAgICAgICAgICAgIHwgICAgfA0KICAgICAgICAgICAgICAgIC0tLS0gICAgICAgICAyMzV8ICAg ICAgICAgICAgICAgfCAgICB8DQogICAgICAgICAgICAgICB8ICAtLS0tLS0tLS0tLS0tLSAgICAg ICAgICAgICAgICB8ICAgIHwNCiAgICAgICAgICAgICAgIHwgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgfA0KICAgICAgICAgICAgICAgViBWICAgICAgICAgICAgICAgICAgMSAg ICAgICAgICAgfCAgICBWDQogICAgICAgICAgICAgICstLS0rICAgVVNFUiAgICArLS0tKy0tLS0t LS0tLS0tLS0tLT4rLS0tKw0KICAgICAgICAgICAgICB8ICAgfC0tLS0tLS0tLS0+fCBXIHwgMiAg ICAgICAgLS0tLS0+fCBFIHwNCiAgICAgICAgICAgICAgKy0tLSsgICAgICAgICAgICstLS0rLS0t LS0tLSAgfCAgLS0tPistLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB8ICAg ICAgICB8IHwgfCB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIDMgfCB8IDQsNSAgICB8 IHwgfCB8DQogICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tICAgLS0tLS0tICB8IHwgfCB8 DQogICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgfCB8IHwgfCB8DQogICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLSAgfCB8DQogICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgMXwgICAgICAgfCB8ICAgfCB8DQogICAgICAgICAgICAgICAg ViAgICAgICAgICAgICAgIHwgICAgICAgfCB8ICAgfCB8DQogICAgICAgICAgICAgICstLS0rICAg UEFTUyAgICArLS0tKyAyICAgfCAgLS0tLS0tLT4rLS0tKw0KICAgICAgICAgICAgICB8ICAgfC0t LS0tLS0tLS0+fCBXIHwtLS0tLS0tLS0tLS0tLS0+fCBTIHwNCiAgICAgICAgICAgICAgKy0tLSsg ICAgICAgICAgICstLS0rICAgLS0tLS0tLS0tLS0tPistLS0rDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCB8ICAgfCAgfCAgICAgfCB8DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDMgfCB8NCw1fCAgfCAgICAgfCB8DQogICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0t ICAgLS0tLS0tLS0tICAgfCAgLS0tLQ0KICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgIHwgIHwgIHwgIHwgICAgICB8DQogICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAt LS0tLS0tLS0tLS0tICAgICAgIHwNCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgMSwzfCAg ICB8ICB8ICB8ICAgICAgICAgfA0KICAgICAgICAgICAgICAgIFYgICAgICAgICAgICAgICB8ICAg MnwgIHwgIHwgICAgICAgICBWDQogICAgICAgICAgICAgICstLS0rICAgQUNDVCAgICArLS0tKy0t ICAgfCAgIC0tLS0tLT4rLS0tKw0KICAgICAgICAgICAgICB8ICAgfC0tLS0tLS0tLS0+fCBXIHwg NCw1ICAtLS0tLS0tLS0+fCBGIHwNCiAgICAgICAgICAgICAgKy0tLSsgICAgICAgICAgICstLS0r LS0tLS0tLS0tLS0tLS0tPistLS0rDQoNCg0KDQpIZXRobW9uICYgTWNNdXJyYXkgICAgICBFeHBp cmVzIERlY2VtYmVyIDI2LCAyMDExICAgICAgICAgICAgICBbUGFnZSAxN10NCgwNCkludGVybmV0 LURyYWZ0ICAgICBGVFAgSE9TVCBDb21tYW5kIGZvciBWaXJ0dWFsIEhvc3RzICAgICAgICAgIEp1 bmUgMjAxMQ0KDQoNCiAgICAgIEZpZ3VyZSA1OiBMb2dpbiBzZXF1ZW5jZSB3aXRoIEhPU1QgYW5k IEFVVEgvQURBVC9BQ0NUIGNvbW1hbmRzDQoNCjMuMy4gIEhPU1QgY29tbWFuZCBlcnJvcnMNCg0K ICAgVGhlIHNlcnZlci1QSSBTSE9VTEQgcmVwbHkgd2l0aCBhIDUwMCBvciA1MDIgcmVwbHkgaWYg dGhlIEhPU1QNCiAgIGNvbW1hbmQgaXMgdW5yZWNvZ25pemVkIG9yIHVuaW1wbGVtZW50ZWQuDQoN CiAgIEFzIGRpc2N1c3NlZCBpbiBzZWN0aW9uIDMgb2YgdGhpcyBkb2N1bWVudCwgaWYgYSBIT1NU IGNvbW1hbmQgaXMgc2VudA0KICAgYWZ0ZXIgYSB1c2VyIGhhcyBiZWVuIGF1dGhlbnRpY2F0ZWQg dGhlIHNlcnZlciBTSE9VTEQgZG8gb25lIG9mIHRoZQ0KICAgZm9sbG93aW5nOg0KDQogICBhLiAg U2VuZCBhIDUwMyByZXBseSBmb3IgYW4gaW52YWxpZCBzZXF1ZW5jZSBvZiBjb21tYW5kcy4NCg0K ICAgYi4gIFRyZWF0IHRoZSBIT1NUIGNvbW1hbmQgYXMgdGhvdWdoIGEgUkVJTiBjb21tYW5kIHdh cyBzZW50IGFuZA0KICAgICAgIHJlc2V0IHRoZSB1c2VyLVBJIHRvIHRoZSBzdGF0ZSB0aGF0IGV4 aXN0ZWQgYWZ0ZXIgdGhlIHByZXZpb3VzDQogICAgICAgSE9TVCBjb21tYW5kIHdhcyBzZW50IGFu ZCBiZWZvcmUgdGhlIHVzZXIgaGFkIGJlZW4gYXV0aGVudGljYXRlZCwNCiAgICAgICBhbmQgdGhl biByZXR1cm4gdGhlIGFwcHJvcHJpYXRlIHJlcGx5IGZvciB0aGUgSE9TVCBjb21tYW5kLg0KDQog ICBBIDUwMSByZXBseSBTSE9VTEQgYmUgc2VudCBpZiB0aGUgaG9zdG5hbWUgZ2l2ZW4gaXMgc3lu dGFjdGljYWxseQ0KICAgaW52YWxpZCwgYW5kIGEgNTA0IHJlcGx5IFNIT1VMRCBiZSBzZW50IGlm IGEgc3ludGFjdGljYWxseSB2YWxpZA0KICAgaG9zdG5hbWUgaXMgbm90IGEgdmFsaWQgdmlydHVh bCBob3N0IG5hbWUgZm9yIHRoZSBzZXJ2ZXIuICBJbiBhbGwNCiAgIHN1Y2ggY2FzZXMsIHRoZSBz ZXJ2ZXItRlRQIHByb2Nlc3MgTVVTVCBkbyBvbmUgb2YgdGhlIGZvbGxvd2luZzoNCg0KICAgYS4g IElnbm9yZSB0aGUgSE9TVCBjb21tYW5kIGFuZCBhY3QgYXMgaWYgYSBIT1NUIGNvbW1hbmQgaGFk IG5vdCBiZWVuDQogICAgICAgc2VudC4gIEEgdXNlci1GVFAgcHJvY2VzcyBNQVkgdGhlbiBzZW5k IGEgc3Vic2VxdWVudCBIT1NUIGNvbW1hbmQNCiAgICAgICB3aXRoIGEgZGlmZmVyZW50IGhvc3Ru YW1lLg0KDQogICBiLiAgQ2xvc2UgdGhlIGNvbm5lY3Rpb24uDQoNCiAgIEEgdXNlci1QSSByZWNl aXZpbmcgYSA1MDAgb3IgNTAyIHJlcGx5IHRvIGEgSE9TVCBjb21tYW5kIFNIT1VMRA0KICAgYXNz dW1lIHRoYXQgdGhlIHNlcnZlci1QSSBkb2VzIG5vdCBpbXBsZW1lbnQgdmlydHVhbCBzZXJ2ZXJz IGJ5IHVzaW5nDQogICB0aGUgSE9TVCBjb21tYW5kLiAgVGhlIHVzZXItUEkgTUFZIHRoZW4gcHJv Y2VlZCB0byBsb2dpbiBhcyBpZiB0aGUNCiAgIEhPU1QgY29tbWFuZCBoYWQgbm90IGJlZW4gc2Vu dC4NCg0KICAgQSB1c2VyLVBJIHJlY2VpdmluZyBhbiBlcnJvciByZXBseSB0aGF0IGlzIGRpZmZl cmVudCBmcm9tIHRoZSBlcnJvcnMNCiAgIHRoYXQgaGF2ZSBiZWVuIGRlc2NyaWJlZCBoZXJlIFNI T1VMRCBhc3N1bWUgdGhhdCB0aGUgdmlydHVhbCBIT1NUIGlzDQogICB1bmF2YWlsYWJsZSwgYW5k IHRlcm1pbmF0ZSBjb21tdW5pY2F0aW9ucy4NCg0KICAgQSBzZXJ2ZXItUEkgdGhhdCByZWNlaXZl cyBhIFVTRVIgY29tbWFuZCB0byBiZWdpbiB0aGUgYXV0aGVudGljYXRpb24NCiAgIHNlcXVlbmNl IHdpdGhvdXQgaGF2aW5nIHJlY2VpdmVkIGEgSE9TVCBjb21tYW5kIFNIT1VMRCBOT1QgcmVqZWN0 IHRoZQ0KICAgVVNFUiBjb21tYW5kLiAgQ2xpZW50cyBjb25mb3JtaW5nIHRvIGVhcmxpZXIgRlRQ IHNwZWNpZmljYXRpb25zIGRvDQogICBub3Qgc2VuZCBIT1NUIGNvbW1hbmRzLiAgSW4gdGhpcyBj YXNlIHRoZSBzZXJ2ZXIgTUFZIGFjdCBhcyBpZiBzb21lDQogICBkZWZhdWx0IHZpcnR1YWwgaG9z dCBoYWQgYmVlbiBleHBsaWNpdGx5IHNlbGVjdGVkLCBvciBNQVkgZW50ZXIgYW4NCiAgIGVudmly b25tZW50IHRoYXQgaXMgZGlmZmVyZW50IGZyb20gdGhhdCBvZiBhbnkgc3VwcG9ydGVkIHZpcnR1 YWwNCiAgIGhvc3RzLCBwZXJoYXBzIG9uZSBpbiB3aGljaCBhIHVuaW9uIG9mIGFsbCBhdmFpbGFi bGUgYWNjb3VudHMgZXhpc3RzDQogICBhbmQgd2hpY2ggcHJlc2VudHMgYW4gTlZGUyB0aGF0IGFw cGVhcnMgdG8gY29udGFpbiBzdWJkaXJlY3Rvcmllcw0KICAgdGhhdCBjb250YWluIHRoZSBOVkZT IGZvciBhbGwgc3VwcG9ydGVkIHZpcnR1YWwgaG9zdHMuDQoNCg0KDQoNCkhldGhtb24gJiBNY011 cnJheSAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjYsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDE4 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgIEZUUCBIT1NUIENvbW1hbmQgZm9yIFZpcnR1YWwgSG9z dHMgICAgICAgICAgSnVuZSAyMDExDQoNCg0KMy40LiAgRkVBVCByZXNwb25zZSBmb3IgSE9TVCBj b21tYW5kDQoNCiAgIFdoZW4gcmVwbHlpbmcgdG8gdGhlIEZFQVQgY29tbWFuZCBbUkZDMjM4OV0s IGEgc2VydmVyLUZUUCBwcm9jZXNzDQogICB0aGF0IHN1cHBvcnRzIHRoZSBIT1NUIGNvbW1hbmQg TVVTVCBpbmNsdWRlIGEgbGluZSBjb250YWluaW5nIHRoZQ0KICAgc2luZ2xlIHdvcmQgIkhPU1Qi LiAgVGhpcyB3b3JkIGlzIGNhc2UgaW5zZW5zaXRpdmUsIGFuZCBNQVkgYmUgc2VudA0KICAgaW4g YW55IG1peHR1cmUgb2YgdXBwZXIgb3IgbG93ZXIgY2FzZSwgaG93ZXZlciBpdCBTSE9VTEQgYmUg c2VudCBpbg0KICAgdXBwZXIgY2FzZS4gIFRoYXQgaXMsIHRoZSByZXNwb25zZSBTSE9VTEQgYmU6 DQoNCiAgICAgICAgQz4gRkVBVA0KICAgICAgICBTPiAyMTEtIDxhbnkgZGVzY3JpcHRpdmUgdGV4 dD4NCiAgICAgICAgUz4gIC4uLg0KICAgICAgICBTPiAgSE9TVA0KICAgICAgICBTPiAgLi4uDQog ICAgICAgIFM+IDIxMSBFbmQNCg0KICAgVGhlIGVsbGlwc2VzIGluZGljYXRlIHBsYWNlIGhvbGRl cnMgd2hlcmUgb3RoZXIgZmVhdHVyZXMgbWF5IGJlDQogICBpbmNsdWRlZCwgYW5kIGFyZSBub3Qg cmVxdWlyZWQuICBUaGUgb25lLXNwYWNlIGluZGVudGF0aW9uIG9mIHRoZQ0KICAgZmVhdHVyZSBs aW5lcyBpcyBtYW5kYXRvcnkgW1JGQzIzODldLg0KDQoNCjQuICBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucw0KDQogICBXaXRoIHRoZSBpbnRyb2R1Y3Rpb24gb2YgdmlydHVhbCBob3N0cyB0byBGVFAs IHNlcnZlciBpbXBsZW1lbnRlcnMNCiAgIHdpbGwgbmVlZCB0byB0YWtlIHNvbWUgY2FyZSB0byBl bnN1cmUgdGhhdCB0aGUgY29uZmlkZW50aWFsaXR5IG9mDQogICBwb3RlbnRpYWxseSBzZW5zaXRp dmUgaW5mb3JtYXRpb24gaXMgbWFpbnRhaW5lZC4gIEZvciBleGFtcGxlLCB3aGlsZQ0KICAgaG9z dG5hbWVzIG1heSBnZW5lcmFsbHkgYmUgYXNzdW1lZCB0byBiZSBwdWJsaWNseSBhdmFpbGFibGUg RE5TDQogICBuYW1lcywgdGhpcyBtYXkgbm90IGFsd2F5cyBiZSB0aGUgc2l0dWF0aW9uLiAgU29t ZSBvcmdhbml6YXRpb25zIG1heQ0KICAgdXNlIHByaXZhdGUgaG9zdG5hbWVzLCBhbmQgdGhhdCBp bmZvcm1hdGlvbiBTSE9VTEQgYmUgcHJvdGVjdGVkIHdoZW4NCiAgIHRyYW5zbWl0dGVkIGJldHdl ZW4gdGhlIGNsaWVudCBhbmQgc2VydmVyIGJ5IHVzaW5nIGEgc3Ryb25nIG1ldGhvZCBvZg0KICAg ZW5jcnlwdGlvbi4NCg0KICAgU2VydmVyIGltcGxlbWVudGF0aW9ucyBTSE9VTEQgcmVzZXQgdGhl IHNlY3VyaXR5IGVudmlyb25tZW50IHdoZW4gYQ0KICAgSE9TVCBjb21tYW5kIGlzIHNlbnQgYWZ0 ZXIgYSB1c2VyIGhhcyBsb2dnZWQgaW4uICBUaGlzIGFsbG93cyBmb3INCiAgIGluZGl2aWR1YWwg YXV0aGVudGljYXRpb24gZW52aXJvbm1lbnRzIGZvciBlYWNoIHZpcnR1YWwgaG9zdCBvbiBhbg0K ICAgRlRQIHNlcnZlci4gIEZvciBleGFtcGxlLCBhIHZpcnR1YWwgaG9zdCAiZm9vLmV4YW1wbGUu Y29tIiBvbiBhbiBGVFANCiAgIHNlcnZlciBtaWdodCB1c2UgYSBzcGVjaWZpYyB1c2VybmFtZSBh bmQgcGFzc3dvcmQgbGlzdCwgd2hpbGUgdGhlDQogICB2aXJ0dWFsIGhvc3QgImJhci5leGFtcGxl LmNvbSIgb24gdGhlIHNhbWUgRlRQIHNlcnZlciBtaWdodCB1c2UgYQ0KICAgZGlmZmVyZW50IHVz ZXJuYW1lIGFuZCBwYXNzd29yZCBsaXN0LiAgSW4gc3VjaCBhIHNjZW5hcmlvLCByZXNldHRpbmcN CiAgIHRoZSBzZWN1cml0eSBlbnZpcm9ubWVudCBpcyBuZWNlc3NhcnkgZm9yIHZpcnR1YWwgc2Vy dmVycyB0byBhcHBlYXINCiAgIHRvIGJlaGF2ZSBpbmRlcGVuZGVudGx5Lg0KDQogICBBIGdlbmVy YWwgZGlzY3Vzc2lvbiBvZiBpc3N1ZXMgcmVsYXRlZCB0byB0aGUgc2VjdXJpdHkgb2YgRlRQIGNh biBiZQ0KICAgZm91bmQgaW4gW1JGQzI1NzddLg0KDQoNCjUuICBJQU5BIENvbnNpZGVyYXRpb25z DQoNCiAgIElBTkEgaXMgcmVxdWVzdGVkIHRvIHJlZ2lzdGVyIHRoZSBmb2xsb3dpbmcgRlRQIGV4 dGVuc2lvbiBhY2NvcmRpbmcNCg0KDQoNCkhldGhtb24gJiBNY011cnJheSAgICAgIEV4cGlyZXMg RGVjZW1iZXIgMjYsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDE5XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgIEZUUCBIT1NUIENvbW1hbmQgZm9yIFZpcnR1YWwgSG9zdHMgICAgICAgICAgSnVuZSAy MDExDQoNCg0KICAgdG8gdGhlIHByb2NlZHVyZSBlc3RhYmxpc2hlZCBieSBbUkZDNTc5N106DQoN CiAgICstLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tKw0KICAgfCBjbWQgIHwgRkVBVCAgICB8IGRlc2NyaXB0aW9uIHwgdHlw ZSB8IGNvbmYgfCBSRkMjcy9SZWZlcmVuY2VzIGFuZCB8DQogICB8ICAgICAgfCBDb2RlICAgIHwg ICAgICAgICAgICAgfCAgICAgIHwgICAgICB8IE5vdGVzICAgICAgICAgICAgICAgIHwNCiAgICst LS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tKw0KICAgfCBIT1NUIHwgSE9TVCAgICB8IEhvc3RuYW1lICAgIHwgYSAgICB8IG8g ICAgfCBUQkQgICAgICAgICAgICAgICAgICB8DQogICArLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0t LS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KICAgICBOT1RF IFRPIFJGQyBFRElUT1I6IFBsZWFzZSB1cGRhdGUgVEJEIGluIHRoZSBhYm92ZSB0YWJsZSB3aXRo IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgIG51bWJlciBvZiB0aGlzIGRvY3VtZW50Lg0K DQoNCjYuICBSZWZlcmVuY2VzDQoNCjYuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtS RkMwOTU5XSAgUG9zdGVsLCBKLiBhbmQgSi4gUmV5bm9sZHMsICJGaWxlIFRyYW5zZmVyIFByb3Rv Y29sDQogICAgICAgICAgICAgIChGVFApIiwgU1REIDksIFJGQyA5NTksIE9jdG9iZXIgMTk4NS4N Cg0KICAgW1JGQzEwMzRdICBNb2NrYXBldHJpcywgUC4sICJEb21haW4gTmFtZXMgLSBDb25jZXB0 cyBhbmQgRmFjaWxpdGllcyIsDQogICAgICAgICAgICAgIFNURCAxMywgUkZDIDEwMzQsIE5vdmVt YmVyIDE5ODcuDQoNCiAgIFtSRkMxMDM1XSAgTW9ja2FwZXRyaXMsIFAuLCAiRG9tYWluIE5hbWVz IC0gSW1wbGVtZW50YXRpb24gYW5kDQogICAgICAgICAgICAgIFNwZWNpZmljYXRpb24iLCBTVEQg MTMsIFJGQyAxMDM1LCBOb3ZlbWJlciAxOTg3Lg0KDQogICBbUkZDMTEyM10gIEJyYWRlbiwgUi4s ICJSZXF1aXJlbWVudHMgZm9yIEludGVybmV0IEhvc3RzIC0tDQogICAgICAgICAgICAgIEFwcGxp Y2F0aW9uIGFuZCBTdXBwb3J0IiwgU1REIDMsIFJGQyAxMTIzLCBPY3RvYmVyIDE5ODkuDQoNCiAg IFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIElu ZGljYXRlDQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIx MTksIE1hcmNoIDE5OTcuDQoNCiAgIFtSRkMyMjI4XSAgSG9yb3dpdHosIE0uIGFuZCBTLiBMdW50 LCAiRlRQIFNlY3VyaXR5IEV4dGVuc2lvbnMiLA0KICAgICAgICAgICAgICBSRkMgMjIyOCwgT2N0 b2JlciAxOTk3Lg0KDQogICBbUkZDMjM4OV0gIEhldGhtb24sIFAuIGFuZCBSLiBFbHosICJGZWF0 dXJlIG5lZ290aWF0aW9uIG1lY2hhbmlzbSBmb3INCiAgICAgICAgICAgICAgdGhlIEZpbGUgVHJh bnNmZXIgUHJvdG9jb2wiLCBSRkMgMjM4OSwgQXVndXN0IDE5OTguDQoNCiAgIFtSRkMyNjQwXSAg Q3VydGluLCBXLiwgIkludGVybmF0aW9uYWxpemF0aW9uIG9mIHRoZSBGaWxlIFRyYW5zZmVyDQog ICAgICAgICAgICAgIFByb3RvY29sIiwgUkZDIDI2NDAsIEp1bHkgMTk5OS4NCg0KICAgW1JGQzM0 OTJdICBDb3N0ZWxsbywgQS4sICJQdW55Y29kZTogQSBCb290c3RyaW5nIGVuY29kaW5nIG9mIFVu aWNvZGUNCiAgICAgICAgICAgICAgZm9yIEludGVybmF0aW9uYWxpemVkIERvbWFpbiBOYW1lcyBp biBBcHBsaWNhdGlvbnMNCiAgICAgICAgICAgICAgKElETkEpIiwgUkZDIDM0OTIsIE1hcmNoIDIw MDMuDQoNCiAgIFtSRkM0MjE3XSAgRm9yZC1IdXRjaGluc29uLCBQLiwgIlNlY3VyaW5nIEZUUCB3 aXRoIFRMUyIsIFJGQyA0MjE3LA0KICAgICAgICAgICAgICBPY3RvYmVyIDIwMDUuDQoNCg0KDQoN CkhldGhtb24gJiBNY011cnJheSAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjYsIDIwMTEgICAgICAg ICAgICAgIFtQYWdlIDIwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgIEZUUCBIT1NUIENvbW1hbmQg Zm9yIFZpcnR1YWwgSG9zdHMgICAgICAgICAgSnVuZSAyMDExDQoNCg0KICAgW1JGQzUyMzRdICBD cm9ja2VyLCBELiBhbmQgUC4gT3ZlcmVsbCwgIkF1Z21lbnRlZCBCTkYgZm9yIFN5bnRheA0KICAg ICAgICAgICAgICBTcGVjaWZpY2F0aW9uczogQUJORiIsIFJGQyA1MjM0LCBKYW51YXJ5IDIwMDgu DQoNCjYuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW1JGQzE5NDVdICBCZXJuZXJz LUxlZSwgVC4sIEZpZWxkaW5nLCBSLiwgYW5kIEguIEZyeXN0eWssICJIeXBlcnRleHQNCiAgICAg ICAgICAgICAgVHJhbnNmZXIgUHJvdG9jb2wgLS0gSFRUUC8xLjAiLCBSRkMgMTk0NSwgTWF5IDE5 OTYuDQoNCiAgIFtSRkMyNTc3XSAgQWxsbWFuLCBNLiBhbmQgUy4gT3N0ZXJtYW5uLCAiRlRQIFNl Y3VyaXR5DQogICAgICAgICAgICAgIENvbnNpZGVyYXRpb25zIiwgUkZDIDI1NzcsIE1heSAxOTk5 Lg0KDQogICBbUkZDMjYxNl0gIEZpZWxkaW5nLCBSLiwgR2V0dHlzLCBKLiwgTW9ndWwsIEouLCBG cnlzdHlrLCBILiwNCiAgICAgICAgICAgICAgTWFzaW50ZXIsIEwuLCBMZWFjaCwgUC4sIGFuZCBU LiBCZXJuZXJzLUxlZSwgIkh5cGVydGV4dA0KICAgICAgICAgICAgICBUcmFuc2ZlciBQcm90b2Nv bCAtLSBIVFRQLzEuMSIsIFJGQyAyNjE2LCBKdW5lIDE5OTkuDQoNCiAgIFtSRkM1Nzk3XSAgS2xl bnNpbiwgSi4gYW5kIEEuIEhvZW5lcywgIkZUUCBDb21tYW5kIGFuZCBFeHRlbnNpb24NCiAgICAg ICAgICAgICAgUmVnaXN0cnkiLCBSRkMgNTc5NywgTWFyY2ggMjAxMC4NCg0KDQpBcHBlbmRpeCBB LiAgVW53b3JrYWJsZSBBbHRlcm5hdGl2ZXMNCg0KICAgRHVlIHRvIHRoZSBsZXZlbCBvZiBzY29w ZSBmb3IgYWRkaW5nIGEgbmV3IGNvbW1hbmQgdG8gRlRQLCBhIGJyaWVmDQogICBkaXNjdXNzaW9u IG9mIHN1Z2dlc3RlZCBhbHRlcm5hdGl2ZXMgdG8gYSBIT1NUIGNvbW1hbmQgYW5kIHRoZWlyDQog ICByZXNwZWN0aXZlIGxpbWl0YXRpb25zIGlzIHdhcnJhbnRlZC4gIFRoZSBzdWdnZXN0ZWQgYWx0 ZXJuYXRpdmVzIHRoYXQNCiAgIGFyZSBkaXNjdXNzZWQgaW4gdGhpcyBhcHBlbmRpeCBoYXZlIGJl ZW4gcHJvcG9zZWQgaW4gdGhlIHBhc3QsIGJ1dA0KICAgZWFjaCBvZiB0aGVzZSBpZGVhcyB3YXMg ZGVlbWVkIGluc3VmZmljaWVudCBmb3IgdGhlIHJlYXNvbnMgdGhhdCBhcmUNCiAgIGxpc3RlZCB3 aXRoaW4gZWFjaCBzZWN0aW9uIG9mIHRoZSBhcHBlbmRpeC4NCg0KQS4xLiAgT3ZlcmxvYWRpbmcg dGhlIENXRCBjb21tYW5kDQoNCiAgIE9uZSBzdWdnZXN0ZWQgbWV0aG9kIHRvIGVtdWxhdGUgYSBm b3JtIG9mIHZpcnR1YWwgaG9zdHMgd291bGQgYmUgZm9yDQogICB0aGUgY2xpZW50IHRvIHNpbXBs eSBzZW5kIGEgIkNXRCIgY29tbWFuZCBhZnRlciBjb25uZWN0aW5nLCB1c2luZyB0aGUNCiAgIHZp cnR1YWwgaG9zdCBuYW1lIGFzIHRoZSBhcmd1bWVudCB0byB0aGUgQ1dEIGNvbW1hbmQuICBUaGlz IHdvdWxkDQogICBhbGxvdyB0aGUgc2VydmVyLUZUUCBwcm9jZXNzIHRvIGltcGxlbWVudCB0aGUg ZmlsZSBzdG9yZXMgb2YgdGhlDQogICB2aXJ0dWFsIGhvc3RzIGFzIHN1Yi1kaXJlY3RvcmllcyBp biBpdHMgTlZGUy4gIFRoaXMgc3VnZ2VzdGlvbiBpcw0KICAgc2ltcGxlIGluIGNvbmNlcHQsIGFu ZCBtb3N0IHNlcnZlci1GVFAgaW1wbGVtZW50YXRpb25zIHN1cHBvcnQgdGhpcw0KICAgd2l0aG91 dCByZXF1aXJpbmcgYW55IGNvZGUgY2hhbmdlcy4gIFdoaWxlIHRoaXMgbWV0aG9kIGlzIHNpbXBs ZSB0bw0KICAgZGVzY3JpYmUsIGFuZCB0byBpbXBsZW1lbnQsIGl0IHN1ZmZlcnMgZnJvbSBzZXZl cmFsIGRyYXdiYWNrczoNCg0KICAgYS4gIFRoZSAiQ1dEIiBjb21tYW5kIGlzIGF2YWlsYWJsZSBv bmx5IGFmdGVyIHRoZSB1c2VyLVBJIGhhcw0KICAgICAgIGF1dGhlbnRpY2F0ZWQgaXRzZWxmIHRv IHRoZSBzZXJ2ZXItRlRQIHByb2Nlc3MuICBUaHVzLCBhbGwNCiAgICAgICB2aXJ0dWFsIGhvc3Rz IHdvdWxkIGJlIHJlcXVpcmVkIHRvIHNoYXJlIGEgY29tbW9uIGF1dGhlbnRpY2F0aW9uDQogICAg ICAgc2NoZW1lIGlmIHRoZXkgdXNlZCB0aGlzIG1ldGhvZC4NCg0KICAgYi4gIFRvIG1ha2UgdGhl IHZpcnR1YWwgaG9zdCB0cnVseSB0cmFuc3BhcmVudCwgZWl0aGVyIHRoZSBzZXJ2ZXItRlRQDQog ICAgICAgcHJvY2VzcyBuZWVkcyB0byBiZSBtb2RpZmllZCB0byBpbmNsdWRlIGluZm9ybWF0aW9u IHRoYXQgc2hvd3MNCiAgICAgICB0aGUgc3BlY2lhbCBuYXR1cmUgb2YgdGhpcyBmaXJzdCBDV0Qg Y29tbWFuZCAobmVnYXRpbmcgbW9zdCBvZg0KICAgICAgIHRoZSBhZHZhbnRhZ2Ugb2YgdGhpcyBz Y2hlbWUpLCBvciBhbGwgdXNlcnMgbXVzdCBzZWUgdGhlIHNhbWUNCg0KDQoNCkhldGhtb24gJiBN Y011cnJheSAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjYsIDIwMTEgICAgICAgICAgICAgIFtQYWdl IDIxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgIEZUUCBIT1NUIENvbW1hbmQgZm9yIFZpcnR1YWwg SG9zdHMgICAgICAgICAgSnVuZSAyMDExDQoNCg0KICAgICAgIGlkZW50aWNhbCBOVkZTIHZpZXcg dXBvbiBjb25uZWN0aW5nICh0aGV5IG11c3QgY29ubmVjdCBpbiB0aGUNCiAgICAgICBzYW1lIGlu aXRpYWwgZGlyZWN0b3J5KSwgb3IgdGhlIE5WRlMgbXVzdCBpbXBsZW1lbnQgdGhlIGZ1bGwgc2V0 DQogICAgICAgb2YgdmlydHVhbCBob3N0IGRpcmVjdG9yaWVzIGF0IGVhY2ggcG9zc2libGUgaW5p dGlhbCBkaXJlY3RvcnkNCiAgICAgICBmb3IgYW55IHBvc3NpYmxlIHVzZXIuDQoNCiAgIGMuICBV bmxlc3MgdGhlIHNlcnZlciBpcyBzcGVjaWFsbHkgbW9kaWZpZWQsIGEgdXNlciBjb25uZWN0aW5n IHRoaXMNCiAgICAgICB3YXkgdG8gYSB2aXJ0dWFsIGhvc3Qgd291bGQgYmUgYWJsZSB0byBlYXNp bHkgbW92ZSB0byBhbnkgb3RoZXINCiAgICAgICB2aXJ0dWFsIGhvc3Qgc3VwcG9ydGVkIGF0IHRo ZSBzYW1lIHNlcnZlci1GVFAgcHJvY2VzcywgZXhwb3NpbmcNCiAgICAgICB0aGUgbmF0dXJlIG9m IHRoZSB2aXJ0dWFsIGhvc3QuDQoNCkEuMi4gIE92ZXJsb2FkaW5nIHRoZSBBQ0NUIGNvbW1hbmQN Cg0KICAgQW5vdGhlciBzdWdnZXN0ZWQgbWV0aG9kIHdvdWxkIGJlIHRvIHNpbXBseSBvdmVybG9h ZCB0aGUgIkFDQ1QiIGZvcg0KICAgRlRQIHZpcnR1YWwgaG9zdHMsIGJ1dCB0aGlzIHByb3Bvc2Fs IGlzIHVuYWNjZXB0YWJsZSBmb3Igc2V2ZXJhbA0KICAgcmVhc29ucyB3aXRoIHJlZ2FyZCB0byB3 aGVuIHRoZSBBQ0NUIGNvbW1hbmQgaXMgc2VudCBkdXJpbmcgdGhlDQogICByZXF1ZXN0IGZsb3cu ICBTZWN0aW9ucyA1LjQgYW5kIDYgb2YgW1JGQzA5NTldIGRvY3VtZW50IHRoZSByZXF1ZXN0DQog ICBmbG93IGZvciBhIGxvZ2luIHNlcXVlbmNlIGFzIFVTRVIgLT4gUEFTUyAtPiBBQ0NULiAgVGhp cyBmbG93IG9mDQogICBjb21tYW5kcyBtYXkgYmUgYWNjZXB0YWJsZSB3aGVuIHlvdSBhcmUgY29u c2lkZXJpbmcgYSBzaW5nbGUgdXNlcg0KICAgaGF2aW5nIG11bHRpcGxlIGFjY291bnRzIG9uIGFu IEZUUCBzZXJ2ZXIsIGJ1dCBmYWlscyB0byBkaWZmZXJlbnRpYXRlDQogICBiZXR3ZWVuIHZpcnR1 YWwgaG9zdHMgd2hlbiB5b3UgY29uc2lkZXIgdGhlIGZvbGxvd2luZyB0d28gaXNzdWVzOg0KDQog ICBhLiAgVGhlIGZpcnN0IHByb2JsZW0gd2l0aCBvdmVybG9hZGluZyB0aGUgQUNDVCBjb21tYW5k IGlzDQogICAgICAgY2VydGlmaWNhdGUgbmVnb3RpYXRpb24gd2hlbiB1c2luZyB0aGUgRlRQIHNl Y3VyaXR5IGV4dGVuc2lvbnMNCiAgICAgICB0aGF0IGFyZSBkb2N1bWVudGVkIGluIFtSRkMyMjI4 XSBhbmQgW1JGQzQyMTddLiAgSW4gb3JkZXIgdG8NCiAgICAgICBzYWZlZ3VhcmQgdXNlciBjcmVk ZW50aWFscywgc2VjdXJpdHkgbWVjaGFuaXNtIGFuZCBjZXJ0aWZpY2F0ZQ0KICAgICAgIG5lZ290 aWF0aW9uIG11c3Qgb2NjdXIgYmVmb3JlIGxvZ2luIGNyZWRlbnRpYWxzIGFyZSBzZW50IGJ5IHRo ZQ0KICAgICAgIGNsaWVudC4gIFRoZSBwcm9ibGVtIHdpdGggdXNpbmcgdGhlIEFDQ1QgY29tbWFu ZCBpbiB0aGlzIHNjZW5hcmlvDQogICAgICAgaXMgdGhhdCB0aGVyZSBpcyBubyB3YXkgb2YgZW5z dXJpbmcgdGhhdCB0aGUgY2VydGlmaWNhdGUgbWF0Y2hlcw0KICAgICAgIHRoZSBjb3JyZWN0IHZp cnR1YWwgaG9zdCBiZWZvcmUgdGhlIHVzZXIgY3JlZGVudGlhbHMgYXJlIHNlbnQuDQoNCiAgIGIu ICBUaGUgc2Vjb25kIHByb2JsZW0gd2l0aCBvdmVybG9hZGluZyB0aGUgQUNDVCBjb21tYW5kIGlz IGhvdyB1c2VyDQogICAgICAgY3JlZGVudGlhbHMgYXJlIGltcGxlbWVudGVkIGZvciBGVFAgdmly dHVhbCBob3N0cy4gIEZUUCBzZXJ2ZXINCiAgICAgICBpbXBsZW1lbnRhdGlvbnMgbWF5IGFsbG93 IHRoZSB1c2Ugb2YgY3VzdG9tIHVzZXIgY3JlZGVudGlhbHMgb24gYQ0KICAgICAgIHBlci12aXJ0 dWFsLWhvc3QgYmFzaXMuICBGb3IgZXhhbXBsZSwgaW4gb25lIHBhcnRpY3VsYXINCiAgICAgICBp bXBsZW1lbnRhdGlvbiB0aGUgdmlydHVhbCBob3N0IG5lZ290aWF0aW9uIG9jY3VycywgYW5kIHRo ZW4gdGhlDQogICAgICAgdXNlciBjcmVkZW50aWFscyBhcmUgbG9va2VkIHVwIHVzaW5nIHRoZSBh Y2NvdW50IG1lY2hhbmlzbSB0aGF0DQogICAgICAgaXMgc3BlY2lmaWMgdG8gdGhhdCB2aXJ0dWFs IGhvc3QuICBTbyBvbmNlIGFnYWluIHRoZSB2aXJ0dWFsIGhvc3QNCiAgICAgICBuZWdvdGlhdGlv biBtdXN0IHRha2UgcGxhY2UgYmVmb3JlIHRoZSB1c2VyIGNyZWRlbnRpYWxzIGFyZSBzZW50Lg0K DQpBLjMuICBPdmVybG9hZGluZyB0aGUgVVNFUiBjb21tYW5kDQoNCiAgIEFuIGFkZGl0aW9uYWwg c3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBvdmVybG9hZCB3ZWxsLWtub3duIHN5bnRheA0KICAgdGhy b3VnaCB0aGUgZXhpc3RpbmcgVVNFUiBjb21tYW5kLCBhcyBpbGx1c3RyYXRlZCBpbiB0aGUgZm9s bG93aW5nDQogICBleGFtcGxlOg0KDQoNCg0KDQoNCg0KDQpIZXRobW9uICYgTWNNdXJyYXkgICAg ICBFeHBpcmVzIERlY2VtYmVyIDI2LCAyMDExICAgICAgICAgICAgICBbUGFnZSAyMl0NCgwNCklu dGVybmV0LURyYWZ0ICAgICBGVFAgSE9TVCBDb21tYW5kIGZvciBWaXJ0dWFsIEhvc3RzICAgICAg ICAgIEp1bmUgMjAxMQ0KDQoNCiAgICAgICAgQz4gVVNFUiBmb29AZXhhbXBsZS5jb20NCiAgICAg ICAgUz4gMzMxIFBhc3N3b3JkIHJlcXVpcmVkDQogICAgICAgIEM+IFBBU1MgYmFyDQogICAgICAg IFM+IDIzMCBVc2VyIGxvZ2dlZCBpbg0KDQogICBJbiB0aGlzIGV4YW1wbGUsIHRoZSB1c2VyICJm b28iIG1pZ2h0IGJlIGF0dGVtcHRpbmcgdG8gbG9nIG9uIHRvIHRoZQ0KICAgdmlydHVhbCBob3N0 ICJleGFtcGxlLmNvbSIgb24gYW4gRlRQIHNlcnZlci4gIFRoaXMgc3VnZ2VzdGlvbiBtYXkNCiAg IHNlZW0gcGxhdXNpYmxlIGF0IGZpcnN0LCBidXQgaW50cm9kdWNlcyBzZXZlcmFsIGltcGxlbWVu dGF0aW9uDQogICBwcm9ibGVtcy4gIEZvciBleGFtcGxlOg0KDQogICBhLiAgU29tZSBuZXR3b3Jr IGVudmlyb25tZW50cyBhbHJlYWR5IHVzZSB0aGUgInVzZXJuYW1lQGhvc3RuYW1lIg0KICAgICAg IHN5bnRheCBmb3IgbmV0d29yayBjcmVkZW50aWFscywgd2hlcmUgdGhlICJob3N0bmFtZSIgcG9y dGlvbg0KICAgICAgIHJlZmVycyB0byB0aGUgbG9jYXRpb24gb2YgdGhlIHVzZXIncyBjcmVkZW50 aWFscyB3aXRoaW4gdGhlDQogICAgICAgbmV0d29yayBoaWVyYXJjaHkuICBVc2luZyB0aGUgImZv b0BleGFtcGxlLmNvbSIgc3ludGF4IGl0IGJlY29tZXMNCiAgICAgICBkaWZmaWN1bHQgdG8gZGlm ZmVyZW50aWF0ZSBiZXR3ZWVuIHRoZSB1c2VyICJmb28iIGxvZ2dpbmcgaW50byBhDQogICAgICAg dmlydHVhbCBob3N0IG5hbWVkICJleGFtcGxlLmNvbSIgb24gYW4gRlRQIHNlcnZlciB2ZXJzdXMg dGhlIHVzZXINCiAgICAgICAiZm9vQGV4YW1wbGUuY29tIiBsb2dnaW5nIGludG8gYW4gRlRQIHNl cnZlciB3aXRoIG5vIHNwZWNpZmllZA0KICAgICAgIHZpcnR1YWwgaG9zdC4NCg0KICAgYi4gIFdo ZW4gdXNpbmcgdGhlIEZUUCBzZWN1cml0eSBleHRlbnNpb25zIHRoYXQgYXJlIGRvY3VtZW50ZWQg aW4NCiAgICAgICBbUkZDMjIyOF0gYW5kIFtSRkM0MjE3XSwgc2VjdXJpdHkgbWVjaGFuaXNtIGFu ZCBjZXJ0aWZpY2F0ZQ0KICAgICAgIG5lZ290aWF0aW9uIG11c3Qgb2NjdXIgYmVmb3JlIGxvZ2lu IGNyZWRlbnRpYWxzIGFyZSBzZW50IGJ5IHRoZQ0KICAgICAgIGNsaWVudC4gIE1vcmUgc3BlY2lm aWNhbGx5LCB0aGUgQVVUSC9BREFUIGNvbW1hbmRzIG11c3QgYmUgc2VudA0KICAgICAgIGJlZm9y ZSB0aGUgVVNFUiBjb21tYW5kIGluIG9yZGVyIHRvIHNhZmVndWFyZCB1c2VyIGNyZWRlbnRpYWxz Lg0KICAgICAgIElmIHlvdSBvdmVybG9hZCB0aGUgVVNFUiBjb21tYW5kLCB0aGVyZSBpcyBubyB3 YXkgb2YgZW5zdXJpbmcNCiAgICAgICB0aGF0IHRoZSBjZXJ0aWZpY2F0ZSBtYXRjaGVzIHRoZSBj b3JyZWN0IHZpcnR1YWwgaG9zdCBiZWZvcmUgdGhlDQogICAgICAgdXNlciBjcmVkZW50aWFscyBh cmUgc2VudCBieSB0aGUgY2xpZW50Lg0KDQpBLjQuICBDb25jbHVzaW9uDQoNCiAgIFRoZSBjb25j bHVzaW9uIGZyb20gdGhlIGV4YW1pbmF0aW9uIG9mIHRoZSBleGlzdGluZyBwb3NzaWJpbGl0aWVz DQogICBzZWVtcyB0byBiZSB0aGF0IGluIG9yZGVyIHRvIG9idGFpbiBhbiBhZGVxdWF0ZSBlbXVs YXRpb24gb2YgInJlYWwiDQogICBGVFAgc2VydmVycywgY2xpZW50IGFuZCBzZXJ2ZXIgbW9kaWZp Y2F0aW9ucyB0byBzdXBwb3J0IHZpcnR1YWwgaG9zdHMNCiAgIGFyZSBuZWNlc3NhcnkuICBUaGVy ZWZvcmUgYSBuZXcgRlRQIGNvbW1hbmQgc2VlbXMgdGhlIG1vc3QgbGlrZWx5DQogICBzb2x1dGlv biB0byBwcm92aWRlIHRoZSByZXF1aXJlZCBsZXZlbCBvZiBzdXBwb3J0Lg0KDQoNCkFwcGVuZGl4 IEIuICBBY2tub3dsZWRnZW1lbnRzDQoNCiAgIFJvYmVydCBFbHogYW5kIFBhdWwgSGV0aG1vbiBw cm92aWRlZCBhIGRldGFpbGVkIGRpc2N1c3Npb24gb2YgdGhlDQogICBIT1NUIGNvbW1hbmQgaW4g dGhlaXIgSW50ZXJuZXQgZHJhZnQgdGl0bGVkICJFeHRlbnNpb25zIHRvIEZUUCIgYXMNCiAgIHBh cnQgb2YgdGhlaXIgd29yayB3aXRoIHRoZSBGVFBFWFQgV29ya2luZyBHcm91cCBhdCB0aGUgSUVU Ri4gIFRoZWlyDQogICB3b3JrIGZvcm1lZCB0aGUgYmFzaXMgZm9yIG11Y2ggb2YgdGhpcyBkb2N1 bWVudCwgYW5kIHRoZWlyIGhlbHAgaGFzDQogICBiZWVuIGdyZWF0bHkgYXBwcmVjaWF0ZWQuICBU aGV5IHdvdWxkIGFsc28gbGlrZSB0byBjcmVkaXQgQmVybmhhcmQNCiAgIFJvc2Vua3JhZW56ZXIg Zm9yIGhhdmluZyBmaXJzdCBzdWdnZXN0ZWQgYW5kIGRlc2NyaWJlZCB0aGUgSE9TVA0KICAgY29t bWFuZC4NCg0KICAgQWxleGV5IE1lbG5pa292LCBBbGZyZWQgSG9lbmVzLCBKb2huIEtsZW5zaW4s IGFuZCBKb2UgVG91Y2ggaGF2ZSBtYWRlDQoNCg0KDQpIZXRobW9uICYgTWNNdXJyYXkgICAgICBF eHBpcmVzIERlY2VtYmVyIDI2LCAyMDExICAgICAgICAgICAgICBbUGFnZSAyM10NCgwNCkludGVy bmV0LURyYWZ0ICAgICBGVFAgSE9TVCBDb21tYW5kIGZvciBWaXJ0dWFsIEhvc3RzICAgICAgICAg IEp1bmUgMjAxMQ0KDQoNCiAgIHNldmVyYWwgc3VnZ2VzdGlvbnMgYWJvdXQgZWFybGllciB2ZXJz aW9ucyBvZiB0aGlzIGRvY3VtZW50OyBtYW55IG9mDQogICB0aGVpciBzdWdnZXN0aW9ucyBoYXZl IGJlZW4gaW5jb3Jwb3JhdGVkLCBhbmQgdGhlaXIgY29udHJpYnV0aW9ucyBhcmUNCiAgIGdyYXRl ZnVsbHkgYWNrbm93bGVkZ2VkLiAgSW4gYWRkaXRpb24sIEFsZWMgUm93ZWxsJ3MgYXNzaXN0YW5j ZSBpbg0KICAgbWFraW5nIHNlY3Rpb25zIG9mIHRoaXMgZG9jdW1lbnQgbW9yZSByZWFkYWJsZSB3 YXMgaW52YWx1YWJsZS4NCg0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0KICAgUGF1bCBIZXRobW9u DQogICBIZXRobW9uIEJyb3RoZXJzDQogICAyMzA1IENodWthciBSb2FkDQogICBLbm94dmlsbGUs IFROICAzNzkyMw0KICAgVVNBDQoNCiAgIEVtYWlsOiBwaGV0aG1vbkBoZXRobW9uLmNvbQ0KDQoN CiAgIFJvYmVydCBNY011cnJheQ0KICAgTWljcm9zb2Z0IENvcnBvcmF0aW9uDQogICBPbmUgTWlj cm9zb2Z0IFdheQ0KICAgUmVkbW9uZCwgV0EgIDk4MDUyDQogICBVU0ENCg0KICAgRW1haWw6IHJv Ym1jbUBtaWNyb3NvZnQuY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpIZXRobW9uICYgTWNNdXJyYXkgICAgICBFeHBpcmVzIERlY2VtYmVy IDI2LCAyMDExICAgICAgICAgICAgICBbUGFnZSAyNF0NCgwNCg== --_003_01AA9EC92749BF4894AC2B3039EA4A2C1949D137CH1PRD0302MB131_-- From kathleen.moriarty@emc.com Fri Jun 24 16:52:56 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1F29E8018; Fri, 24 Jun 2011 16:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttvkE59AH-Rj; Fri, 24 Jun 2011 16:52:56 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id D76C99E8004; Fri, 24 Jun 2011 16:52:55 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p5ONqrK2019928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2011 19:52:53 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Fri, 24 Jun 2011 19:52:51 -0400 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p5ONqVOs002511; Fri, 24 Jun 2011 19:52:32 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Fri, 24 Jun 2011 19:52:31 -0400 From: To: , , , Date: Fri, 24 Jun 2011 19:52:30 -0400 Thread-Topic: SECDIR review of draft-ietf-ftpext2-hosts-02 Thread-Index: AcwyiBUFO2skqoQCSLqk+KSpXVMV4QADvEhgAAyN90A= Message-ID: References: <01AA9EC92749BF4894AC2B3039EA4A2C1949D137@CH1PRD0302MB131.namprd03.prod.outlook.com> In-Reply-To: <01AA9EC92749BF4894AC2B3039EA4A2C1949D137@CH1PRD0302MB131.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: phethmon@hethmon.com, anthonybryan@gmail.com Subject: Re: [secdir] SECDIR review of draft-ietf-ftpext2-hosts-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 23:52:57 -0000 Hi, Robert. Thank you for making the updates. I think the change for section 3.2 looks= good, thanks! As for the security considerations, the ADs may have an opinion here as wel= l. My thought process is that if you are concerned about the environment t= hat the user authenticates into, wouldn't the environment itself be a conce= rn as well? The authentication consideration is to ensure the user gets au= thenticated into the right environment. If there is no segregation availab= le between environments, that would be a security consideration. If that v= aries between OSes, that would be a consideration as well. You might not h= ave to detail it out, but it should be stated as a consideration as this ma= y not be a solution possible in a number of use cases. Thank you, Kathleen -----Original Message----- From: Robert McMurray [mailto:robmcm@microsoft.com]=20 Sent: Friday, June 24, 2011 3:03 PM To: Moriarty, Kathleen; secdir@ietf.org; draft-ietf-ftpext2-hosts.all@tools= .ietf.org; iesg@ietf.org Cc: phethmon@hethmon.com; Anthony Bryan (anthonybryan@gmail.com) Subject: RE: SECDIR review of draft-ietf-ftpext2-hosts-02 Thanks, Kathleen. [Note: Adding Anthony Bryan as the document shepherd.] Here is a suggested rewording of the fragment from Section 3.2 for which yo= u had requested an update - does this agree with what you were looking for? "The resultant actions needed to create that environment are not specified = here, and may range from doing nothing at all, to performing a simple chang= e of working directory, or changing authentication schemes and/or username = and password lists, or making much more elaborate state changes - such as c= reating isolated environments for each FTP session." Your first of comment about Section 4 is an easy change - thanks! Your second set of comments about Section 4 seems to me to be less about th= e protocol and more about the actual implementation details, which I think = we should avoid. As an example, I have a background on UNIX, Windows, and s= everal other platforms; the way that I might choose to implement segregatio= n/isolation for each of those platforms will differ radically. For example,= process isolation might come to mind as one possible implementation, but t= he way that processes actually work varies greatly depending on the platfor= m, and it might only make sense on one platform and not the others, but in = any case we shouldn't be suggesting something that specific in an RFC anywa= y. For that matter, the way that accounts and permissions are used on each = platform also differs greatly, so it does not seem to make sense to call ou= t those concepts, either. In the end, each server implementer has a variety= of platform-specific options that are available within their specific situ= ation when they are considering how to implement their unique security envi= ronments, and all of which are outside the scope of this draft. With that = in mind, I do not think that Section 4 should be updated with verbiage that= says something to the effect of, "Actual server implementations for creati= ng security environments for virtual hosts are outside the scope of this do= cument, but you could use a combination of platform-specific technologies s= uch as authentication, isolation, access control, etc." That being said, I have attached an updated version of the draft in TXT and= XML format. Thanks! -----Original Message----- From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com]=20 Sent: Friday, June 24, 2011 9:02 AM To: secdir@ietf.org; draft-ietf-ftpext2-hosts.all@tools.ietf.org; iesg@ietf= .org Cc: phethmon@hethmon.com; Robert McMurray Subject: SECDIR review of draft-ietf-ftpext2-hosts-02 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. Summary: The document requires more information in the security considerat= ions section. Section 3.2: In terms of the types of changes that may be made, it does state 'more elab= orate changes' may be made depending on the environment. However, for secu= rity and the developers reading the specification, I think it would be best= to include the high end of the spectrum here and include isolation as one = of the explicitly stated examples as the scenario may be used in hosted env= ironments. Upon receiving the HOST command, before authenticating the user-PI, a server-FTP process SHOULD validate that the hostname given represents a valid virtual host for that server, and, if it is valid, establish the appropriate environment for that virtual host. The resultant actions needed to create that environment are not specified here, and may range from doing nothing at all, to performing a simple change of working directory, to changing authentication schemes and/or username and password lists, to making much more elaborate state changes, as necessary. Section 4: Security Considerations Please replace the term Confidentiality where you have listed "integrity" i= n the opening sentence as the protection of privacy related information is = described through confidentiality. The integrity and confidentiality of th= e data on the servers are both potentially important, but this opening sent= ence is in context of login parameters. The second paragraph does address the authentication between virtual hosts,= which is good. I think it is also important to ensure readers are aware o= f possible concerns with segregation or isolation of the virtual FTP enviro= nments. If there are security concerns that may include different user bas= es on the same physical host or different levels (sensitivity) of informati= on in different FTP hosts on the same server, the ability to have segregati= on of the environments will be important (this will happen). How can segre= gation/isolation be provided in this model? Please include information on = the options here. I am assuming that since we are talking about multiple h= osts on a single IP, that we may be within a physical host or a virtual env= ironment that has one IP address. If this is the case, what security optio= ns are available - authentication, access controls, etc.? Please include t= hem in this section. Thank you, Kathleen From robmcm@microsoft.com Fri Jun 24 18:48:04 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7009711E809C; Fri, 24 Jun 2011 18:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.105 X-Spam-Level: X-Spam-Status: No, score=-6.105 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OO1qOObVM1m; Fri, 24 Jun 2011 18:48:03 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 9482411E808E; Fri, 24 Jun 2011 18:48:03 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 24 Jun 2011 18:48:03 -0700 Received: from DB3EHSOBE003.bigfish.com (157.54.51.112) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 24 Jun 2011 18:48:02 -0700 Received: from mail39-db3-R.bigfish.com (10.3.81.250) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.22; Sat, 25 Jun 2011 01:48:01 +0000 Received: from mail39-db3 (localhost.localdomain [127.0.0.1]) by mail39-db3-R.bigfish.com (Postfix) with ESMTP id C49101698072; Sat, 25 Jun 2011 01:48:00 +0000 (UTC) X-SpamScore: -42 X-BigFish: PS-42(zz9371M111aL4015L103dK542M1dbaLzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT003.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail39-db3: transitioning domain of microsoft.com does not designate 157.55.61.146 as permitted sender) client-ip=157.55.61.146; envelope-from=robmcm@microsoft.com; helo=CH1PRD0302HT003.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail39-db3 (localhost.localdomain [127.0.0.1]) by mail39-db3 (MessageSwitch) id 1308966480534982_3130; Sat, 25 Jun 2011 01:48:00 +0000 (UTC) Received: from DB3EHSMHS003.bigfish.com (unknown [10.3.81.240]) by mail39-db3.bigfish.com (Postfix) with ESMTP id 7D63F110012; Sat, 25 Jun 2011 01:48:00 +0000 (UTC) Received: from CH1PRD0302HT003.namprd03.prod.outlook.com (157.55.61.146) by DB3EHSMHS003.bigfish.com (10.3.87.103) with Microsoft SMTP Server (TLS) id 14.1.225.22; Sat, 25 Jun 2011 01:48:00 +0000 Received: from CH1PRD0302MB131.namprd03.prod.outlook.com ([169.254.11.234]) by CH1PRD0302HT003.namprd03.prod.outlook.com ([10.28.28.161]) with mapi id 14.01.0225.056; Sat, 25 Jun 2011 01:47:58 +0000 From: Robert McMurray To: "kathleen.moriarty@emc.com" , "secdir@ietf.org" , "draft-ietf-ftpext2-hosts.all@tools.ietf.org" , "iesg@ietf.org" Thread-Topic: SECDIR review of draft-ietf-ftpext2-hosts-02 Thread-Index: AcwyiBUFO2skqoQCSLqk+KSpXVMV4QADvEhgAAyN90AAAphKUA== Date: Sat, 25 Jun 2011 01:47:58 +0000 Message-ID: <01AA9EC92749BF4894AC2B3039EA4A2C1949DC3F@CH1PRD0302MB131.namprd03.prod.outlook.com> References: <01AA9EC92749BF4894AC2B3039EA4A2C1949D137@CH1PRD0302MB131.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.29.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT003.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%EMC.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HETHMON.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com Cc: "phethmon@hethmon.com" , "anthonybryan@gmail.com" Subject: Re: [secdir] SECDIR review of draft-ietf-ftpext2-hosts-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 01:48:04 -0000 Thanks, Kathleen. At the protocol level I am only concerned that the security environment is = reset; how the environment is created and reset is implementation-specific.= So my intention was to highlight as a security consideration that an imple= menter should be aware that they might have work to do in this scenario, bu= t the details are up to them. With that in mind, what do you think of this = rewording for that section? "As discussed in section 3.3 of this document, a server implementation MAY = treat a HOST command that was sent after a user has been authenticated as t= hough a REIN command was sent. In this scenario, the server implementation = SHOULD reset the authentication environment, as that would allow for segreg= ation between the security environments for each virtual host on an FTP ser= ver. The implementation details for security environments may vary greatly = based on the requirements of each server implementation and operating syste= m, and those details are outside the scope of the protocol itself. For exam= ple, a virtual host "foo.example.com" on an FTP server might use a specific= username and password list, while the virtual host "bar.example.com" on th= e same FTP server might use a different username and password list. In such= a scenario, resetting the security environment is necessary for the virtua= l servers to appear to behave independently from a client perspective, whil= e the actual server implementation details are irrelevant at the protocol l= evel." Thanks again! Robert -----Original Message----- From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com]=20 Sent: Friday, June 24, 2011 4:53 PM To: Robert McMurray; secdir@ietf.org; draft-ietf-ftpext2-hosts.all@tools.ie= tf.org; iesg@ietf.org Cc: phethmon@hethmon.com; anthonybryan@gmail.com Subject: RE: SECDIR review of draft-ietf-ftpext2-hosts-02 Hi, Robert. Thank you for making the updates. I think the change for section 3.2 looks= good, thanks! As for the security considerations, the ADs may have an opinion here as wel= l. My thought process is that if you are concerned about the environment t= hat the user authenticates into, wouldn't the environment itself be a conce= rn as well? The authentication consideration is to ensure the user gets au= thenticated into the right environment. If there is no segregation availab= le between environments, that would be a security consideration. If that v= aries between OSes, that would be a consideration as well. You might not h= ave to detail it out, but it should be stated as a consideration as this ma= y not be a solution possible in a number of use cases. Thank you, Kathleen From kathleen.moriarty@emc.com Fri Jun 24 19:51:42 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A76111E808E; Fri, 24 Jun 2011 19:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD1tvj-dkE5l; Fri, 24 Jun 2011 19:51:41 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id E9A5111E809E; Fri, 24 Jun 2011 19:51:40 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p5P2paTi005499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2011 22:51:36 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Fri, 24 Jun 2011 22:51:25 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.221.46.113]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p5P2nbUg008198; Fri, 24 Jun 2011 22:49:37 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub05.corp.emc.com ([128.221.46.113]) with mapi; Fri, 24 Jun 2011 22:49:37 -0400 From: To: , , , Date: Fri, 24 Jun 2011 22:49:36 -0400 Thread-Topic: SECDIR review of draft-ietf-ftpext2-hosts-02 Thread-Index: AcwyiBUFO2skqoQCSLqk+KSpXVMV4QADvEhgAAyN90AAAphKUAADsoUw Message-ID: References: <01AA9EC92749BF4894AC2B3039EA4A2C1949D137@CH1PRD0302MB131.namprd03.prod.outlook.com> <01AA9EC92749BF4894AC2B3039EA4A2C1949DC3F@CH1PRD0302MB131.namprd03.prod.outlook.com> In-Reply-To: <01AA9EC92749BF4894AC2B3039EA4A2C1949DC3F@CH1PRD0302MB131.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: phethmon@hethmon.com, anthonybryan@gmail.com Subject: Re: [secdir] SECDIR review of draft-ietf-ftpext2-hosts-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 02:51:42 -0000 Thanks again, Robert. The suggested paragraph works for me. Once that is = in, I think we are good on the security review. Best regards, Kathleen -----Original Message----- From: Robert McMurray [mailto:robmcm@microsoft.com]=20 Sent: Friday, June 24, 2011 9:48 PM To: Moriarty, Kathleen; secdir@ietf.org; draft-ietf-ftpext2-hosts.all@tools= .ietf.org; iesg@ietf.org Cc: phethmon@hethmon.com; anthonybryan@gmail.com Subject: RE: SECDIR review of draft-ietf-ftpext2-hosts-02 Thanks, Kathleen. At the protocol level I am only concerned that the security environment is = reset; how the environment is created and reset is implementation-specific.= So my intention was to highlight as a security consideration that an imple= menter should be aware that they might have work to do in this scenario, bu= t the details are up to them. With that in mind, what do you think of this = rewording for that section? "As discussed in section 3.3 of this document, a server implementation MAY = treat a HOST command that was sent after a user has been authenticated as t= hough a REIN command was sent. In this scenario, the server implementation = SHOULD reset the authentication environment, as that would allow for segreg= ation between the security environments for each virtual host on an FTP ser= ver. The implementation details for security environments may vary greatly = based on the requirements of each server implementation and operating syste= m, and those details are outside the scope of the protocol itself. For exam= ple, a virtual host "foo.example.com" on an FTP server might use a specific= username and password list, while the virtual host "bar.example.com" on th= e same FTP server might use a different username and password list. In such= a scenario, resetting the security environment is necessary for the virtua= l servers to appear to behave independently from a client perspective, whil= e the actual server implementation details are irrelevant at the protocol l= evel." Thanks again! Robert -----Original Message----- From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com]=20 Sent: Friday, June 24, 2011 4:53 PM To: Robert McMurray; secdir@ietf.org; draft-ietf-ftpext2-hosts.all@tools.ie= tf.org; iesg@ietf.org Cc: phethmon@hethmon.com; anthonybryan@gmail.com Subject: RE: SECDIR review of draft-ietf-ftpext2-hosts-02 Hi, Robert. Thank you for making the updates. I think the change for section 3.2 looks= good, thanks! As for the security considerations, the ADs may have an opinion here as wel= l. My thought process is that if you are concerned about the environment t= hat the user authenticates into, wouldn't the environment itself be a conce= rn as well? The authentication consideration is to ensure the user gets au= thenticated into the right environment. If there is no segregation availab= le between environments, that would be a security consideration. If that v= aries between OSes, that would be a consideration as well. You might not h= ave to detail it out, but it should be stated as a consideration as this ma= y not be a solution possible in a number of use cases. Thank you, Kathleen From iljitsch@muada.com Mon Jun 27 09:16:07 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C4621F85ED for ; Mon, 27 Jun 2011 09:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8bMsYKwdznM for ; Mon, 27 Jun 2011 09:16:07 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 0E36321F85EC for ; Mon, 27 Jun 2011 09:16:06 -0700 (PDT) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p5RGGewt085252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Jun 2011 18:16:41 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Mon, 27 Jun 2011 18:16:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Donald Eastlake X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 27 Jun 2011 09:23:44 -0700 Cc: draft-ietf-behave-ftp64.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] draft-ietf-behave-ftp64 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 16:16:07 -0000 I've removed the CC to IESG, I think it's easier to first discuss this a = bit more privately. On 5 jun 2011, at 22:44, Donald Eastlake wrote: > I have a bit of a problem with the title ("An FTP ALG for > IPv6-to-IPv4 translation") and the slant of some of the wording. It > claims to be able to describe, as an Application Level Gateway, > various recommendations which are then combined with a separate > existing IPv6-to-IPv4 ALG. It talks about multiple ALGs being > implemented at a single entity that are handling an single FTP > session. This just all seems very odd to me as it isn't very clear > what the interface between these different ALGs all somehow > cooperating on one session is. When you say "separate existing IPv6-to-IPv4 ALG" do you mean the NAT64 = translator? I included a few sentences about other FTP ALGs because I wanted to make = the point that if you put multiple types of functionality in one big = ALG, the side effect of the AUTH command must still be maintained even = if using that command is not allowed by policy by "another ALG". Do you agree that's useful? I guess I need to describe it better. > I believe, in reality, anyone > implementing this will take an existing ALG and modify it as suggested > in the draft. The draft would therefore make more sense if written as > suggested changes to a single ALG rather than as an additional ALG > that is somehow compounded with an existing FTP ALG... Just my > opinion. Not sure how that would look in practice, though. Thanks for the review, Iljitsch= From clonvick@cisco.com Tue Jun 28 12:26:55 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FC011E80F2; Tue, 28 Jun 2011 12:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7tCpitGPc3E; Tue, 28 Jun 2011 12:26:55 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB3A11E807B; Tue, 28 Jun 2011 12:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=clonvick@cisco.com; l=832; q=dns/txt; s=iport; t=1309289214; x=1310498814; h=date:from:to:subject:message-id:mime-version; bh=H8UsYX5U3KE8l7DT2lktTz5RP8VaWLxblR51sHiZcXM=; b=YE7vUW7QrAY1/lZ6WDbuU/FapYfEYZ+VC/aLOZEOxx1O2ZUnLUzH1j2s N05sVbxLyr6IqkneXESxsuNl98wWUjtH5fnCl4VPOILXUZSMvrE9MSaw7 GjFW16U9HoFRfUZHfRmgVO8xzOYi1Jqn9XROqkGBLVoeUhb7fN49o/7YE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFALUqCk6rRDoH/2dsb2JhbABTmEwBjnN3q3WeG4YwBIc0mx0 X-IronPort-AV: E=Sophos;i="4.65,438,1304294400"; d="scan'208";a="387949257" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 28 Jun 2011 19:26:54 +0000 Received: from sjc-cde-032.cisco.com (sjc-cde-032.cisco.com [171.69.29.20]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5SJQsln028198; Tue, 28 Jun 2011 19:26:54 GMT Date: Tue, 28 Jun 2011 12:26:54 -0700 (PDT) From: Chris Lonvick To: draft-gellens-mime-bucket-bis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [secdir] SECDIR review of draft-gellens-mime-bucket-bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 19:26:55 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is very straightforward in that it describes codecs parameters and associated media types. I agree with the conclusions in the security considerations section: The codecs parameter itself does not alter the security considerations of any of the media types with which it is used. Each audio and video media type has its own set of security considerations that continue to apply, regardless of the use of the codecs parameter. Regards, Chris From turners@ieca.com Tue Jun 28 14:27:09 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B4311E811C for ; Tue, 28 Jun 2011 14:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.082 X-Spam-Level: X-Spam-Status: No, score=-101.082 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MILPJkzaUrm8 for ; Tue, 28 Jun 2011 14:27:08 -0700 (PDT) Received: from nm30-vm0.bullet.mail.sp2.yahoo.com (nm30-vm0.bullet.mail.sp2.yahoo.com [98.139.91.238]) by ietfa.amsl.com (Postfix) with SMTP id BD10C11E8113 for ; Tue, 28 Jun 2011 14:27:08 -0700 (PDT) Received: from [98.139.91.66] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 28 Jun 2011 21:27:06 -0000 Received: from [98.139.91.21] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 28 Jun 2011 21:27:06 -0000 Received: from [127.0.0.1] by omp1021.mail.sp2.yahoo.com with NNFMP; 28 Jun 2011 21:27:06 -0000 X-Yahoo-Newman-Id: 50475.9851.bm@omp1021.mail.sp2.yahoo.com Received: (qmail 54762 invoked from network); 28 Jun 2011 21:27:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1309296425; bh=vGvLagplWo42DLjRqxuQP1YsTEKBrojeq6pNpXr1B00=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=XMUihwqq2NuHw3J2Idc9BsGFPFR8s0nyi0kJ9F6VX/7UJIL9R36b2EcbVD6iqIotBJjV81qzT4JPY5wwcLDwKJ7Y4hxYYu3onITBOnDCnCHASU6IqqzYx2wS3oolxPFVgsdJkLL8oa4+N2RG5KizrsRm8sIOIrfKFjCzfs7oeic= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: K2PpVI8VM1nY774JcP0iBUNUvv2_obg3QoJfsf2GUwNTqJJ ef1sW7KBL_keQO2JqQkKPYb9M_2H_1pTNMEIzi.5kgzdU9ryeMc8agHnjjFC E2hzXdXCNBoCK1UcMX365ZxB6.zdhECvQfGQthjN2USmQP1VO2ky0BPFhTYn 4zr_L0JrGWKifTdi.er7bU9GN3GiZ.NNP74GlBZgzLU2XcEi5XMMvToMg8ya NfcZncpCNme2cIB8Iq2HFcVF_98JUV2G5Td48zgJl_99WRZIdRUla3rO0q9x sRSRXk_dZZRQkJlpyjjvNVjV1.vcXPFTw1DITh5P91d7LMqjxKruDy80zbyS R1Qx9Aj3IXjjzKd69gHoOGAsxZ4FiJHHPq3cL6lExBg-- X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.westell.com (turners@96.241.2.113 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 28 Jun 2011 14:27:05 -0700 PDT Message-ID: <4E0A4728.5060506@ieca.com> Date: Tue, 28 Jun 2011 17:27:04 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] IETF 81 Security Directorate Lunch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 21:27:09 -0000 All, I've requested a room for Tuesday at 11:30 for our normal Security Directorate Lunch. As soon as I get a room assigned, I'll let you know. spt From shawn.emery@oracle.com Tue Jun 28 23:40:50 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C38E11E8075; Tue, 28 Jun 2011 23:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAN4TN5106wb; Tue, 28 Jun 2011 23:40:49 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1829E801B; Tue, 28 Jun 2011 23:40:49 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet10.oracle.com (Switch-3.4.4/Switch-3.4.2) with ESMTP id p5T6ekli004517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Jun 2011 06:40:48 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p5T6ej9b018969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jun 2011 06:40:46 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p5T6eeYc024565; Wed, 29 Jun 2011 01:40:40 -0500 Received: from [10.7.250.160] (/10.7.250.160) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 28 Jun 2011 23:40:39 -0700 Message-ID: <4E0AC8E3.1000101@oracle.com> Date: Wed, 29 Jun 2011 00:40:35 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.17) Gecko/20110609 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4E0AC8F0.00A4:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: draft-ietf-ccamp-asymm-bw-bidir-lsps-bis.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 06:40:50 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This standards track draft re-purposes an experimental RFC, 5467, to standards track. 5467 (and this draft) describes a protocol to support bidirectional Label Switched Paths (LSPs) with asymmetric bandwidth. The security considerations section does exist and asserts that there are no additional attacks by adding upstream signaling, which I agree with. General comments: Thank you for referencing the underlying security framework for this draft. Editorial comments: None. Shawn. -- From weiler+secdir@watson.org Thu Jun 30 07:30:23 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C1D11E8184 for ; Thu, 30 Jun 2011 07:30:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqMiIxKhKjzW for ; Thu, 30 Jun 2011 07:30:22 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id C369311E8181 for ; Thu, 30 Jun 2011 07:30:22 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p5UEULCo098678 for ; Thu, 30 Jun 2011 10:30:21 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p5UEULDJ098675 for ; Thu, 30 Jun 2011 10:30:21 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 30 Jun 2011 10:30:21 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 30 Jun 2011 10:30:22 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 14:30:23 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Tobias Gondrom is next in the rotation. For telechat 2011-07-14 Reviewer LC end Draft Richard Barnes T 2011-07-13 draft-ietf-6man-flow-3697bis-05 Dave Cridland T 2011-07-13 draft-ietf-intarea-router-alert-considerations-05 Donald Eastlake T 2011-07-14 draft-ietf-mpls-tp-cc-cv-rdi-05 Shawn Emery T 2011-07-11 draft-ietf-mpls-tp-identifiers-06 Phillip Hallam-Baker T 2011-06-14 draft-ietf-dime-local-keytran-11 David McGrew T 2011-07-08 draft-iesg-rfc1150bis-01 Tim Polk T 2011-06-30 draft-ietf-codec-requirements-04 Vincent Roca T 2011-07-04 draft-ietf-mboned-ssmping-08 Yaron Sheffer T 2011-05-18 draft-ietf-sidr-repos-struct-08 Brian Weis T 2011-07-04 draft-ietf-6man-flow-ecmp-03 Nico Williams T 2011-07-04 draft-ietf-6man-flow-update-06 Tom Yu T 2011-07-04 draft-ietf-mpls-ldp-p2mp-14 Larry Zhu T 2011-07-05 draft-ietf-mpls-tp-linear-protection-07 Glen Zorn T 2011-07-05 draft-ietf-mptcp-congestion-05 For telechat 2011-08-11 Reviewer LC end Draft Derek Atkins T 2011-07-04 draft-ietf-roll-of0-14 Alan DeKok T 2011-07-11 draft-ietf-mpls-mldp-recurs-fec-03 Last calls and special requests: Reviewer LC end Draft Rob Austein 2011-07-18 draft-shiomoto-ccamp-switch-programming-05 Uri Blumenthal 2011-07-13 draft-ietf-6man-node-req-bis-11 Julien Laganier 2011-06-15 draft-ietf-ipfix-configuration-model-09 Matt Lepinski 2011-07-13 draft-burgin-ipsec-suiteb-profile-00 Catherine Meadows R2011-04-13 draft-ietf-speechsc-mrcpv2-24 Russ Mundy 2011-06-30 draft-ietf-karp-design-guide-02 Magnus Nystrom 2011-07-13 draft-polk-local-emergency-rph-namespace-01 Tim Polk 2011-05-11 draft-ietf-vrrp-unified-mib-09 Joe Salowey 2011-05-30 draft-ietf-mpls-lsp-ping-enhanced-dsmap-09 Ondrej Sury 2011-06-30 draft-ietf-sidr-rescerts-provisioning-10 Tina TSOU 2011-04-23 draft-shin-augmented-pake-06 Carl Wallace 2011-05-30 draft-ietf-mpls-p2mp-lsp-ping-17 Carl Wallace 2011-07-21 draft-forte-lost-extensions-06 Sam Weiler 2011-07-20 draft-gutmann-cms-hmac-enc-05 Glen Zorn 2011-06-28 draft-li-pwe3-ms-pw-pon-03