From nobody Thu Aug 1 05:03:00 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B1F12008C for ; Thu, 1 Aug 2019 05:02:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <156466097840.19306.3978607080749978056.idtracker@ietfa.amsl.com> Date: Thu, 01 Aug 2019 05:02:58 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 12:02:59 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-08-08 Reviewer LC end Draft Matthew Miller 2019-07-04 draft-ietf-intarea-frag-fragile-15 Kathleen Moriarty 2019-07-11 draft-ietf-ospf-xaf-te-06 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-16 Magnus Nystrom 2019-06-20 draft-ietf-mmusic-ice-sip-sdp-37 Kyle Rose 2019-07-31 draft-ietf-mpls-rfc8287-len-clarification-02 Rich Salz 2019-07-18 draft-ietf-idr-bgp-extended-messages-35 Last calls: Reviewer LC end Draft Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-31 Roman Danyliw 2019-06-04 draft-ietf-rtgwg-enterprise-pa-multihoming-11 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Aanchal Malhotra 2019-06-26 draft-ietf-ipwave-ipv6-over-80211ocb-51 Catherine Meadows 2019-06-25 draft-ietf-grow-bmp-adj-rib-out-06 Catherine Meadows 2019-04-12 draft-ietf-mmusic-rfc4566bis-36 Matthew Miller 2019-04-08 draft-ietf-core-multipart-ct-03 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Hilarie Orman 2019-08-05 draft-ietf-iasa2-rfc2031bis-05 Derrell Piper 2019-08-01 draft-ietf-mile-jsoniodef-10 Tim Polk 2019-08-01 draft-ietf-acme-star-06 Melinda Shore 2019-08-14 draft-ietf-iasa2-rfc7776bis-02 Valery Smyslov 2019-08-14 draft-ietf-iasa2-rfc5377bis-02 Robert Sparks 2019-08-13 draft-ietf-netmod-artwork-folding-07 Sean Turner 2019-08-12 draft-ietf-rmcat-nada-11 Carl Wallace 2019-08-12 draft-ietf-tls-grease-03 David Waltermire 2019-08-07 draft-ietf-oauth-jwt-introspection-response-05 Samuel Weiler 2019-08-06 draft-ietf-lamps-cms-mix-with-psk-05 Brian Weis 2019-08-05 draft-ietf-oauth-resource-indicators-05 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-12 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Next in the reviewer rotation: Klaas Wierenga Christopher Wood Paul Wouters Liang Xia Taylor Yu Dacheng Zhang Derek Atkins John Bradley Nancy Cam-Winget Shaun Cooley From nobody Thu Aug 1 15:32:33 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 019901201D0; Thu, 1 Aug 2019 08:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1564674827; bh=ohopCDlVWL1V7y3rsplZzACt+Gsri1nxMj/V7B40UP0=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=eTUcYidarqWtRYpSMoqq6FrTSVJstyfTPx6b4uKZb1m2itHI4hvmGiQYNdKSvGYde VMv0NYHc8iWx2D/zbkzyciShLRsPDv4g1rKtRYWTh6L6wq9d7yD5ewsavJ2hG7Tl3f J+iq0w3dvgnO3UbmcfVi5X7Mj88uSLKbKEWPc2CE= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Aug 1 08:53:46 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1589F1201B3; Thu, 1 Aug 2019 08:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1564674826; bh=ohopCDlVWL1V7y3rsplZzACt+Gsri1nxMj/V7B40UP0=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=Hqdyu715xG2Co97b/2QNIsFyftlx3tAN+W2yYzM+1osCeSbBk6fJ43gJ+tpDn6XWy 64IgdsNiQE/dtxHDHHboNMqOtTslBrpHItPRWZj4PZzG2uznrvfvINTXjivAILSgI+ AoGEP13ShgxTsqwFVcSq33kbR8QB0z1drdiSK84w= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D6F1201AA for ; Thu, 1 Aug 2019 08:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfIfDCdaN7Ad for ; Thu, 1 Aug 2019 08:53:42 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB321200CC for ; Thu, 1 Aug 2019 08:53:39 -0700 (PDT) Received: from [88.142.247.155] (helo=[192.168.1.23]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1htDOc-0003dr-5M for new-work@ietf.org; Thu, 01 Aug 2019 15:53:38 +0000 To: new-work@ietf.org From: xueyuan Message-ID: Date: Thu, 1 Aug 2019 23:53:37 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 01 Aug 2019 15:32:31 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Decentralized Identifier Working Group (until 2019-08-31) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 15:53:48 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgRGVjZW50 cmFsaXplZCBJZGVudGlmaWVyIFdvcmtpbmcgR3JvdXA6CiDCoCBodHRwczovL3d3dy53My5vcmcv MjAxOS8wOC9kaWQtd2ctY2hhcnRlci5odG1sCgpBcyBwYXJ0IG9mIGVuc3VyaW5nIHRoYXQgdGhl IGNvbW11bml0eSBpcyBhd2FyZSBvZiBwcm9wb3NlZCB3b3JrCmF0IFczQywgdGhpcyBkcmFmdCBj aGFydGVyIGlzIHB1YmxpYyBkdXJpbmcgdGhlIEFkdmlzb3J5CkNvbW1pdHRlZSByZXZpZXcgcGVy aW9kLgoKVzNDIGludml0ZXMgcHVibGljIGNvbW1lbnRzIHRocm91Z2ggMjAxOS0wOC0zMSBvbiB0 aGUKcHJvcG9zZWQgY2hhcnRlci4gUGxlYXNlIHNlbmQgY29tbWVudHMgdG8KcHVibGljLW5ldy13 b3JrQHczLm9yZywgd2hpY2ggaGFzIGEgcHVibGljIGFyY2hpdmU6CiDCoCBodHRwOi8vbGlzdHMu dzMub3JnL0FyY2hpdmVzL1B1YmxpYy9wdWJsaWMtbmV3LXdvcmsvCgpPdGhlciB0aGFuIGNvbW1l bnRzIHNlbnQgaW4gZm9ybWFsIHJlc3BvbnNlcyBieSBXM0MgQWR2aXNvcnkKQ29tbWl0dGVlIFJl cHJlc2VudGF0aXZlcywgVzNDIGNhbm5vdCBndWFyYW50ZWUgYSByZXNwb25zZSB0bwpjb21tZW50 cy4gSWYgeW91IHdvcmsgZm9yIGEgVzNDIE1lbWJlciBbMV0sIHBsZWFzZSBjb29yZGluYXRlCnlv dXIgY29tbWVudHMgd2l0aCB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZS4g Rm9yCmV4YW1wbGUsIHlvdSBtYXkgd2lzaCB0byBtYWtlIHB1YmxpYyBjb21tZW50cyB2aWEgdGhp cyBsaXN0IGFuZApoYXZlIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlIHJl ZmVyIHRvIGl0IGZyb20gaGlzCm9yIGhlciBmb3JtYWwgcmV2aWV3IGNvbW1lbnRzLgoKSWYgeW91 IHNob3VsZCBoYXZlIGFueSBxdWVzdGlvbnMgb3IgbmVlZCBmdXJ0aGVyIGluZm9ybWF0aW9uLCBw bGVhc2UKY29udGFjdCBXZW5keSBTZWx0emVyLCBXM0MgU3RyYXRlZ3kgTGVhZCwgYXQgPHdzZWx0 emVyQHczLm9yZz4uCgpUaGFuayB5b3UsCgpYdWV5dWFuIEppYSwgVzNDIE1hcmtldGluZyAmIENv bW11bmljYXRpb25zCgpbMV0gaHR0cDovL3d3dy53My5vcmcvQ29uc29ydGl1bS9NZW1iZXIvTGlz dAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV3LXdv cmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Fri Aug 2 12:25:18 2019 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 7456D12014F; Fri, 2 Aug 2019 12:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCu7v0c13lAG; Fri, 2 Aug 2019 12:25:14 -0700 (PDT) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2221200E9; Fri, 2 Aug 2019 12:25:14 -0700 (PDT) Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1htdAt-00014h-RQ; Fri, 02 Aug 2019 13:25:11 -0600 Received: from [166.70.232.207] (helo=rumpleteazer.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1htdAp-0001im-UQ; Fri, 02 Aug 2019 13:25:11 -0600 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x72JNAtl026919; Fri, 2 Aug 2019 13:23:10 -0600 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id x72JN98X026918; Fri, 2 Aug 2019 13:23:09 -0600 Date: Fri, 2 Aug 2019 13:23:09 -0600 Message-Id: <201908021923.x72JN98X026918@rumpleteazer.rhmr.com> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org Cc: draft-ietf-iasa2-rfc2031bis.all@tools.ietf.org X-XM-SPF: eid=1htdAp-0001im-UQ; ; ; mid=<201908021923.x72JN98X026918@rumpleteazer.rhmr.com>; ; ; hst=in01.mta.xmission.com; ; ; ip=166.70.232.207; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX1/SUqi+yB72VuGVA69WC8o8 X-SA-Exim-Connect-IP: 166.70.232.207 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 3384 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 2.3 (0.1%), b_tie_ro: 1.70 (0.1%), parse: 0.57 (0.0%), extract_message_metadata: 3.5 (0.1%), get_uri_detail_list: 1.49 (0.0%), tests_pri_-1000: 2.1 (0.1%), tests_pri_-950: 1.07 (0.0%), tests_pri_-900: 0.93 (0.0%), tests_pri_-90: 23 (0.7%), check_bayes: 22 (0.7%), b_tokenize: 6 (0.2%), b_tok_get_all: 10 (0.3%), b_comp_prob: 1.99 (0.1%), b_tok_touch_all: 2.8 (0.1%), b_finish: 0.52 (0.0%), tests_pri_0: 3341 (98.8%), check_dkim_signature: 0.36 (0.0%), check_dkim_adsp: 3011 (89.0%), poll_dns_idle: 3006 (88.8%), tests_pri_10: 1.89 (0.1%), tests_pri_500: 4.5 (0.1%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: Subject: [secdir] Security review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 19:25:16 -0000 Security review of The IETF-ISOC Relationship draft-ietf-iasa2-rfc2031bis-05 Do not be alarmed. I generated this review of 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 with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Knitz. This is an overview of the ways the IETF and the ISOC are entwined with structural and legal relationships. I believe that changes to the RFC have been required because a new entity, the IETF LLC, is being formed. That slightly changes the way the IETF and ISOC interrelate. Does this affect the security of the Internet (something that might be regarded as largely a mythical concept)? The only problem that comes to mind is that the several organizations might at some future time have philosophical differences that are so deep that the ability of the IETF to publish RFCs would be disrupted. The organization that holds IP is different from the organization that has the financial oversight, and neither is the IP generator, so things might come apart in some unforeseeable future. I can see that the way the boards are structured largely mitigates such worries. Perhaps that is the best that can be done. An important document, the "operating agreement" (Limited Liability Company Agreement of IETF Administration LLC", August 2018), is not available via the reference section of the draft in question. I was able to use Internet search to find a copy. Section 6, "Legal Relationship with ISOC" mentions both the IETF LLC and the IETF Trust. It would greatly help to use subheadings to clarify that these are two separate legal entities. This sentence is a grammatical trainwreck: "It was established by the ISOC/IETF LLC Agreement [OpAgreement] on August 27, 2018, and governs the relationship between the IETF LLC and ISOC." The pronoun "it" refers to the IETF LLC. The second clause has no subject, but if it did, the subject would be "the operating agreement". We also see that "The creation of the IETF LLC has changed the way that the IETF Trust's trustees are selected but did not change the purpose or operation of the Trust. One of the IETF Trust's trustees is appointed by the ISOC's board of trustees." How did it change the way the trustees are selected? Were there previously more or fewer than one trustee appointed by ISOC? Or was there some other change? This sentence, which has probably been there for some time, "ISOC has agreed to provide some funding support for the IETF (ISOC has historically provided the IETF with significant financial support)" sounds odd. What is the different between "some" and "significant"? Should it be "insignifant" and "significant"? "Not much" and "a lot"? Is the differentiation even meaningful now? When did ISOC last affirm its agreement? Does it matter? RFCs generally use American spelling, so at least the uncapitalized uses of "programme" should be changed to "program" in ISOC also supports the IETF standards process more indirectly (e.g., by promoting it in relevant communities) through several programmes. For example, ISOC's Policymakers Programme to the IETF (usually referred to simply as ISOC's policy fellows programme) From nobody Fri Aug 2 12:28:55 2019 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 8440F120192; Fri, 2 Aug 2019 12:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJOD1UpRsV9E; Fri, 2 Aug 2019 12:28:45 -0700 (PDT) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CC28120147; Fri, 2 Aug 2019 12:28:45 -0700 (PDT) Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1htdEK-0003un-Ta; Fri, 02 Aug 2019 13:28:44 -0600 Received: from [166.70.232.207] (helo=rumpleteazer.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1htdEK-0001Gc-3M; Fri, 02 Aug 2019 13:28:44 -0600 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x72JQkRn027597; Fri, 2 Aug 2019 13:26:46 -0600 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id x72JQkZp027596; Fri, 2 Aug 2019 13:26:46 -0600 Date: Fri, 2 Aug 2019 13:26:46 -0600 Message-Id: <201908021926.x72JQkZp027596@rumpleteazer.rhmr.com> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org Cc: draft-ietf-iasa2-rfc2031bis.all@tools.ietf.org X-XM-SPF: eid=1htdEK-0001Gc-3M; ; ; mid=<201908021926.x72JQkZp027596@rumpleteazer.rhmr.com>; ; ; hst=in02.mta.xmission.com; ; ; ip=166.70.232.207; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX1+P73cR72d7MHD5hs9fJ0el X-SA-Exim-Connect-IP: 166.70.232.207 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 569 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 2.6 (0.4%), b_tie_ro: 1.74 (0.3%), parse: 0.84 (0.1%), extract_message_metadata: 4.7 (0.8%), get_uri_detail_list: 1.95 (0.3%), tests_pri_-1000: 3.0 (0.5%), tests_pri_-950: 1.34 (0.2%), tests_pri_-900: 1.12 (0.2%), tests_pri_-90: 25 (4.5%), check_bayes: 24 (4.2%), b_tokenize: 8 (1.4%), b_tok_get_all: 8 (1.4%), b_comp_prob: 3.2 (0.6%), b_tok_touch_all: 2.8 (0.5%), b_finish: 0.59 (0.1%), tests_pri_0: 521 (91.5%), check_dkim_signature: 0.61 (0.1%), check_dkim_adsp: 7 (1.2%), poll_dns_idle: 0.55 (0.1%), tests_pri_10: 2.2 (0.4%), tests_pri_500: 5 (0.9%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Archived-At: Subject: [secdir] Security review of draft-ietf-iasa2-rfc2031bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 19:28:48 -0000 (with corrected subject line) Security review of The IETF-ISOC Relationship draft-ietf-iasa2-rfc2031bis-05 Do not be alarmed. I generated this review of 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 with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Knitz. This is an overview of the ways the IETF and the ISOC are entwined with structural and legal relationships. I believe that changes to the RFC have been required because a new entity, the IETF LLC, is being formed. That slightly changes the way the IETF and ISOC interrelate. Does this affect the security of the Internet (something that might be regarded as largely a mythical concept)? The only problem that comes to mind is that the several organizations might at some future time have philosophical differences that are so deep that the ability of the IETF to publish RFCs would be disrupted. The organization that holds IP is different from the organization that has the financial oversight, and neither is the IP generator, so things might come apart in some unforeseeable future. I can see that the way the boards are structured largely mitigates such worries. Perhaps that is the best that can be done. An important document, the "operating agreement" (Limited Liability Company Agreement of IETF Administration LLC", August 2018), is not available via the reference section of the draft in question. I was able to use Internet search to find a copy. Section 6, "Legal Relationship with ISOC" mentions both the IETF LLC and the IETF Trust. It would greatly help to use subheadings to clarify that these are two separate legal entities. This sentence is a grammatical trainwreck: "It was established by the ISOC/IETF LLC Agreement [OpAgreement] on August 27, 2018, and governs the relationship between the IETF LLC and ISOC." The pronoun "it" refers to the IETF LLC. The second clause has no subject, but if it did, the subject would be "the operating agreement". We also see that "The creation of the IETF LLC has changed the way that the IETF Trust's trustees are selected but did not change the purpose or operation of the Trust. One of the IETF Trust's trustees is appointed by the ISOC's board of trustees." How did it change the way the trustees are selected? Were there previously more or fewer than one trustee appointed by ISOC? Or was there some other change? This sentence, which has probably been there for some time, "ISOC has agreed to provide some funding support for the IETF (ISOC has historically provided the IETF with significant financial support)" sounds odd. What is the different between "some" and "significant"? Should it be "insignifant" and "significant"? "Not much" and "a lot"? Is the differentiation even meaningful now? When did ISOC last affirm its agreement? Does it matter? RFCs generally use American spelling, so at least the uncapitalized uses of "programme" should be changed to "program" in ISOC also supports the IETF standards process more indirectly (e.g., by promoting it in relevant communities) through several programmes. For example, ISOC's Policymakers Programme to the IETF (usually referred to simply as ISOC's policy fellows programme) From nobody Fri Aug 2 13:10:27 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D678F120189; Fri, 2 Aug 2019 13:10:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: netmod@ietf.org, ietf@ietf.org, draft-ietf-netmod-artwork-folding.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Sparks Message-ID: <156477661481.21003.10781222745111642469@ietfa.amsl.com> Date: Fri, 02 Aug 2019 13:10:14 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-netmod-artwork-folding-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 20:10:15 -0000 Reviewer: Robert Sparks Review result: Has Nits Reviewer: Robert Sparks Review result: Has Nits 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 introduces no new security concerns for the Internet. It aims to establish conventions for wrapping long lines in source code sections of RFCs. It does have shell scripts embedded in the Appendix. I see no obvious security issues with those scripts. I strongly suggest this document proceed as Informational and not BCP. It's fine if some documents adopt the convention. Other conventions may work better for other groups. See, for example, the convention described in section 2.1 of RFC4475. (No automated wrap/unwrap scripts have been written for that convention to my knowledge, but it would not be hard to create some.) Nits: In your headers, you anticipate receiving a two digit BCP number. At the moment, the next available BCP number has three digits. (We are well into the 200s). You have header lengths that would need to be adjusted. In 7.2.1 paragraph 5, I think you're saying to fail if any lines in the input document already end with a \. I think you mean to say any lines that you are considering wrapping. If I'm correct, the clarification may also need to be applied in other places where you say "the text content" From nobody Fri Aug 2 13:19:25 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0902212018B; Fri, 2 Aug 2019 13:19:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Catherine Meadows via Datatracker To: Cc: grow@ietf.org, draft-ietf-grow-bmp-adj-rib-out.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Catherine Meadows Message-ID: <156477714899.20990.10992539485582022650@ietfa.amsl.com> Date: Fri, 02 Aug 2019 13:19:09 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-grow-bmp-adj-rib-out-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 20:19:09 -0000 Reviewer: Catherine Meadows Review result: Not Ready This draft describes describes a modification of BGP Monitoring Protocol to allow it access to the Adj-RIB-Out Routing Information Bases. It already has access to the Adj-RIB-In. According to RFC4271 these are defined as follows: ”The Adj-RIBs-In contains unprocessed routing information that has been advertised to the local BGP speaker by its peers" and "The Adj-RIBs-Out contains the routes for advertisement to specific peers by means of the local speaker’s UPDATE messages.” The procedure by which BMP sends Adj-RIBS-Out is similar to that which by which it sends Adj-RIBS-In. The Security Considerations Section consists of the following statement: It is not believed that this document adds any additional security considerations. This is not enough. First, you need to say additional security considerations beyond what. This can best be done by referencing one or more RFCs. In this case it would be RFC 7854, and perhaps RFC 4271. e.g. This document does not add any additional security considerations beyond those already covered RFC 7854. Secondly, you need to say why it doesn’t introduce any new security considerations. In both Adj-RIBS-In and Out cases the information sent is routing information. Would there be any new security considerations involved in sharing routing information sent in UPDATE messages vs. advertisements? If not, why not? From nobody Fri Aug 2 13:19:32 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F15512019B; Fri, 2 Aug 2019 13:19:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz via Datatracker To: Cc: idr@ietf.org, draft-ietf-idr-bgp-extended-messages.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Rich Salz Message-ID: <156477715825.20942.4335500049855564504@ietfa.amsl.com> Date: Fri, 02 Aug 2019 13:19:18 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-idr-bgp-extended-messages-35 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 20:19:22 -0000 Reviewer: Rich Salz Review result: Ready This is the secdir review, intended for the security AD's. Others should treat this as normal last-call comments. This describes a BGP extension code to increase the size of BGP messages. It nicely explains deployment issues (if a BGP node doesn't understand the extension), and security issues. The extension is disallowed for two operations, although only one has a rationale; it was left to reader to intuit that KEEPALIVE doesn't need the longer size. I suggest making that explicit. That is a nit. Looks good; ship it. From nobody Fri Aug 2 14:04:57 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED667120147; Fri, 2 Aug 2019 14:04:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kyle Rose via Datatracker To: Cc: mpls@ietf.org, ietf@ietf.org, draft-ietf-mpls-rfc8287-len-clarification.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Kyle Rose Message-ID: <156477989693.20922.10639864462240787352@ietfa.amsl.com> Date: Fri, 02 Aug 2019 14:04:56 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-mpls-rfc8287-len-clarification-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 21:04:57 -0000 Reviewer: Kyle Rose Review result: Ready 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 a straightforward update for implementation clarity and has neither security nor privacy implications. From nobody Fri Aug 2 14:34:20 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5273120168; Fri, 2 Aug 2019 14:34:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Catherine Meadows via Datatracker To: Cc: ietf@ietf.org, draft-ietf-mmusic-rfc4566bis.all@ietf.org, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Catherine Meadows Message-ID: <156478165290.20958.13051270492203409535@ietfa.amsl.com> Date: Fri, 02 Aug 2019 14:34:12 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-mmusic-rfc4566bis-36 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 21:34:13 -0000 Reviewer: Catherine Meadows Review result: Ready I generated this review of 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 with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document updates RFC4566 on the Session Description Protocol, SDP. The Security Considerations Section is well-written and well-thought out, and it updates the RFC4566 security considerations when appropriate. I consider this document READY. From nobody Fri Aug 2 14:53:15 2019 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 4D66112013B; Fri, 2 Aug 2019 14:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlvlixKi0umr; Fri, 2 Aug 2019 14:53:00 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964A8120059; Fri, 2 Aug 2019 14:53:00 -0700 (PDT) Received: from MacBook-Pro.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x72LqvIW021951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 2 Aug 2019 17:52:58 -0400 To: Catherine Meadows , secdir@ietf.org Cc: ietf@ietf.org, draft-ietf-mmusic-rfc4566bis.all@ietf.org, mmusic@ietf.org References: <156478165290.20958.13051270492203409535@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <6b29002e-c486-f1e4-dabe-04e6e5fe4428@alum.mit.edu> Date: Fri, 2 Aug 2019 17:52:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <156478165290.20958.13051270492203409535@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mmusic-rfc4566bis-36 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 21:53:03 -0000 Catherine, On 8/2/19 5:34 PM, Catherine Meadows via Datatracker wrote: > Reviewer: Catherine Meadows > Review result: Ready > > I generated this review of 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 > with the intent of improving security requirements and considerations > in IETF drafts. Comments not addressed in last call may be included > in AD reviews during the IESG review. Document editors and WG chairs > should treat these comments just like any other last call comments. > > This document updates RFC4566 on the Session Description Protocol, SDP. The > Security Considerations Section is well-written and well-thought out, and it > updates the RFC4566 security considerations when appropriate. I consider this > document READY. Thank you! Paul From nobody Mon Aug 5 06:31:10 2019 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 C729A1201EA; Mon, 5 Aug 2019 06:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oxC0WwVmpIK; Mon, 5 Aug 2019 06:31:00 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 184D91201E5; Mon, 5 Aug 2019 06:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=MIIlA1VhOqPgDvskuGpe9jBp1IUL5ZR7nItyFUpliBQ=; b=CU3o8jikqYACoRzq9f79Pp6Pw0 k/KLqvkc+MxvENMjQ8vHCjBgUnUifYZxJUA9CdP7dcsR0vjFJHpkuA9jdYDluzf/XPpXKAY4juVEo F7u+wgitGdCLv8LRBsn8nHsx2aLR3VT1JjoJKQr5WsVwLVEgCI11ThFeeuLZ1BN5n6r+Vw5wKMsVT zH+yJzpkwM3UVsVqfCLDxdZpe7y0kQjmP7fhsD1HKQOiq1sQZah69GEc0+prM96s0iQR4eJbloT1j 8u3Pg+/hsQf4a65Je2PIfXgAudozb++ow9CzXvtBodIl4gPIAwPp4yE9j08veIJ0+9B0xARqKuFDr o3sJBleg==; Received: from [82.138.51.4] (port=49984 helo=buildpc) by direct.host-care.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.92) (envelope-from ) id 1hud4O-0004KI-TW; Mon, 05 Aug 2019 09:30:38 -0400 From: "Valery Smyslov" To: Cc: , , Date: Mon, 5 Aug 2019 16:30:06 +0300 Message-ID: <001801d54b91$ec706e30$c5514a90$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AdVLkMxSV3gfWI0DR7aknVDwBBktKg== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [secdir] Secdir Last Call review of draft-ietf-iasa2-rfc5377bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 13:31:02 -0000 Reviewer: Valery Smyslov Review result: Ready 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 describes the desired outbound rights to be granted in IETF contributions. It is an update for RFC 5377 with the only change to its content that the reference to IASA is removed. The document doesn't describe any protocol, it only describes part of IETF process. For this reason the document has no direct impact on the security of IETF protocols. Although one can imagine some attacks on IETF process that can indirectly affect the security of IETF protocols, I believe they are out of scope of this document. Small typo in the Abstract: missing space before the last sentence. From nobody Mon Aug 5 12:31:04 2019 Return-Path: <0100016c63432c70-5f5c500b-ed4b-407a-ac9c-dc3631a9bac2-000000@amazonses.watsen.net> 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 071291200C5; Mon, 5 Aug 2019 12:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL67Uu8uHxjl; Mon, 5 Aug 2019 12:30:47 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1744120048; Mon, 5 Aug 2019 12:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1565033442; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=MIa1rijkblopES+qh5UhSADGDShf7ppBDXXBiaI63hc=; b=G5i8PVpqxMOR0OI+T6098Hcad3PxSH3vDk/j1guLnQ7vRbeQJyBkq/EBq8e4ndhM VQjt61FWnTiIqvpxxLndgODEYM3RqXGfJk9a2UjrWfoHqEqQLDjDCnPQdIkFO4JxcVU 45p5C7qr1P5MuUFyGBci00yup0lFAj+UCyrOoDmo= From: Kent Watsen Message-ID: <0100016c63432c70-5f5c500b-ed4b-407a-ac9c-dc3631a9bac2-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F666228C-C399-4535-A1A2-AC8B9803A80A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 5 Aug 2019 19:30:42 +0000 In-Reply-To: <156477661481.21003.10781222745111642469@ietfa.amsl.com> Cc: secdir@ietf.org, ietf@ietf.org, "netmod@ietf.org" , draft-ietf-netmod-artwork-folding.all@ietf.org To: Robert Sparks References: <156477661481.21003.10781222745111642469@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.08.05-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [secdir] [netmod] Secdir last call review of draft-ietf-netmod-artwork-folding-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 19:30:50 -0000 --Apple-Mail=_F666228C-C399-4535-A1A2-AC8B9803A80A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Robert, I'm glad that you reviewed this draft, as I envision backend Datatracker = integration may be desired (as we discussed in the Code Sprint before). > On Aug 2, 2019, at 4:10 PM, Robert Sparks via Datatracker = wrote: >=20 > Reviewer: Robert Sparks > Review result: Has Nits >=20 > Reviewer: Robert Sparks > Review result: Has Nits >=20 > 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. >=20 > This document introduces no new security concerns for the Internet. > It aims to establish conventions for wrapping long lines in source = code=20 > sections of RFCs. >=20 > It does have shell scripts embedded in the Appendix. I see no obvious > security issues with those scripts. >=20 > I strongly suggest this document proceed as Informational and not BCP.=20= > It's fine if some documents adopt the convention. Other conventions = may > work better for other groups. See, for example, the = convention > described in section 2.1 of RFC4475. (No automated wrap/unwrap scripts > have been written for that convention to my knowledge, but it would > not be hard to create some.) The BCP status was recommended by the WG. I'll defer my own opinion at = this time. Regarding , I think that you're actually making a case for = why this should be a BCP ;) FWIW, the NETMOD WG (and it's sister WG, NETCONF) have a long history of = using XML-based inclusions in RFCs. > Nits:=20 >=20 > In your headers, you anticipate receiving a two digit BCP number. At = the > moment, the next available BCP number has three digits. (We are well > into the 200s). You have header lengths that would need to be = adjusted. Good catch. this has been fixed in my local copy. > In 7.2.1 paragraph 5, I think you're saying to fail if any lines in = the > input document already end with a \. I think you mean to say any lines > that you are considering wrapping. If I'm correct, the clarification = may > also need to be applied in other places where you say "the text = content" Updated. My local copy now reads: Scan the text content to ensure no existing lines already end with = a backslash ('\') character, as this could lead to an ambiguous = result. If such a line is found, and its width is less than the desired = maximum, then it SHOULD be flagged for forced folding (folding even though unnecessary). If the folding implementation doesn't support forced foldings, it MUST exit. The symmetric text in Section 8.2.1 already followed this form. Thanks, Kent // as co-author --Apple-Mail=_F666228C-C399-4535-A1A2-AC8B9803A80A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Robert,

I'm glad = that you reviewed this draft, as I envision backend Datatracker = integration may be desired (as we discussed in the Code Sprint = before).


On Aug = 2, 2019, at 4:10 PM, Robert Sparks via Datatracker <noreply@ietf.org> = wrote:

Reviewer: Robert Sparks
Review result: Has = Nits

Reviewer: Robert Sparks
Review result: Has Nits

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 introduces no new security concerns for the = Internet.
It aims to establish conventions for wrapping = long lines in source code
sections of RFCs.

It does have shell scripts embedded in the = Appendix. I see no obvious
security issues with those = scripts.

I strongly suggest this document = proceed as Informational and not BCP.
It's fine if some = documents adopt the convention. Other conventions may
work = better for other groups. See, for example, the <allOneLine> = convention
described in section 2.1 of RFC4475. (No = automated wrap/unwrap scripts
have been written for that = convention to my knowledge, but it would
not be hard to = create some.)

The BCP status was recommended by the WG. =  I'll defer my own opinion at this time.

Regarding <allOneLine>, I think that you're = actually making a case for why this should be a BCP   =  ;)

FWIW, the NETMOD WG (and = it's sister WG, NETCONF) have a long history of using XML-based = inclusions in RFCs.




Nits:

In your headers, you anticipate receiving a two digit BCP = number. At the
moment, the next available BCP number has = three digits. (We are well
into the 200s). You have header = lengths that would need to be adjusted.

Good = catch. this has been fixed in my local copy.


In = 7.2.1 paragraph 5, I think you're saying to fail if any lines in the
input document already end with a \. I think you mean to say = any lines
that you are considering wrapping. If I'm = correct, the clarification may
also need to be applied in = other places where you say "the text content"

Updated.  My = local copy now reads:

    =   Scan the text content to ensure no existing lines already end = with a
      backslash ('\') character, as this = could lead to an ambiguous result.
    =   If such a line is found, and its width is less than the = desired maximum,
      then it SHOULD = be flagged for forced folding (folding even though
  =     unnecessary). If the folding implementation doesn't = support forced
      foldings, it MUST = exit.</t>

The symmetric text in = Section 8.2.1 already followed this form.



Thanks,
Kent // as = co-author




= --Apple-Mail=_F666228C-C399-4535-A1A2-AC8B9803A80A-- From nobody Thu Aug 8 08:23:27 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D361120041 for ; Thu, 8 Aug 2019 08:23:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <156527780625.7574.18344903871817831739.idtracker@ietfa.amsl.com> Date: Thu, 08 Aug 2019 08:23:26 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 15:23:26 -0000 Btw, I just send a dozen of emails asking people whether they are able to do the assignments they have been assigned to or not, and whether they should be marked as being unavailable for reviews for some period of time. It would be much better if you feel that you cannot do reviews now, to go to the datatracker and mark yourself unavailable. You do not need to have any specific reason for it, but we do have quite a lot of reviewers in our rotation so skipping few who are too busy is no problem for rotation, but missed reviews are. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-08-08 Reviewer LC end Draft Matthew Miller 2019-07-04 draft-ietf-intarea-frag-fragile-15 Kathleen Moriarty 2019-07-11 draft-ietf-ospf-xaf-te-06 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-16 Magnus Nystrom 2019-06-20 draft-ietf-mmusic-ice-sip-sdp-37 For telechat 2019-08-22 Reviewer LC end Draft Derek Atkins 2019-08-15 draft-ietf-opsec-urpf-improvements-03 Last calls: Reviewer LC end Draft Nancy Cam-Winget 2019-08-15 draft-ietf-manet-dlep-lid-extension-05 Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-31 Roman Danyliw 2019-06-04 draft-ietf-rtgwg-enterprise-pa-multihoming-12 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Aanchal Malhotra 2019-06-26 draft-ietf-ipwave-ipv6-over-80211ocb-51 Matthew Miller 2019-04-08 draft-ietf-core-multipart-ct-03 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Derrell Piper 2019-08-01 draft-ietf-mile-jsoniodef-10 Tim Polk 2019-08-01 draft-ietf-acme-star-06 Melinda Shore 2019-08-14 draft-ietf-iasa2-rfc7776bis-02 Sean Turner 2019-08-12 draft-ietf-rmcat-nada-11 Carl Wallace 2019-08-12 draft-ietf-tls-grease-03 David Waltermire 2019-08-07 draft-ietf-oauth-jwt-introspection-response-05 Samuel Weiler 2019-08-06 draft-ietf-lamps-cms-mix-with-psk-06 Brian Weis 2019-08-05 draft-ietf-oauth-resource-indicators-05 Christopher Wood 2019-08-30 draft-klensin-idna-unicode-review-02 Paul Wouters 2019-08-30 draft-klensin-idna-rfc5891bis-04 Liang Xia 2019-08-20 draft-ietf-6man-segment-routing-header-22 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-12 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Next in the reviewer rotation: Shaun Cooley Roman Danyliw Alan DeKok Linda Dunbar Donald Eastlake Shawn Emery Stephen Farrell Daniel Franke Daniel Gillmor Tobias Gondrom From nobody Thu Aug 8 16:53:42 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7524E120154; Thu, 8 Aug 2019 16:53:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Melinda Shore via Datatracker To: Cc: draft-ietf-iasa2-rfc7776bis.all@ietf.org, ietf@ietf.org, iasa20@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Melinda Shore Message-ID: <156530839229.7502.10596578919129972914@ietfa.amsl.com> Date: Thu, 08 Aug 2019 16:53:12 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-iasa2-rfc7776bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 23:53:25 -0000 Reviewer: Melinda Shore Review result: Ready This document updates IETF anti-harassment procedures to reflect organizational changes to the IETF (specifically, the replacement of the IAOC with the IETF LLC, and the replacement of the IETF Administrative Director with the IETF LLC Executive Director). Additionally, it updates the text with respect to ombudsteam-initiated recall processes, but it does not change make changes to the processes themselves. The document is clearly written and unambiguous, and there are no new security considerations. The document is ready for publication. From nobody Fri Aug 9 01:38:57 2019 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 B9EAC1200E0; Fri, 9 Aug 2019 01:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cUEzqoRdSM6; Fri, 9 Aug 2019 01:38:54 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F4E1200B1; Fri, 9 Aug 2019 01:38:50 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id x798cmLb007828; Fri, 9 Aug 2019 09:38:48 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1FA592203A; Fri, 9 Aug 2019 09:38:48 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id 0ACC322032; Fri, 9 Aug 2019 09:38:48 +0100 (BST) Received: from LAPTOPK7AS653V (120.105.162.213.dyn.plus.net [213.162.105.120] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x798ckux028872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 9 Aug 2019 09:38:47 +0100 Reply-To: From: "Adrian Farrel" To: "'Melinda Shore'" Cc: , References: <156530839229.7502.10596578919129972914@ietfa.amsl.com> In-Reply-To: <156530839229.7502.10596578919129972914@ietfa.amsl.com> Date: Fri, 9 Aug 2019 09:38:45 +0100 Organization: Old Dog Consulting Message-ID: <033001d54e8d$dc1756d0$94460470$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIZvPfG13oUrk7QGd63Vy27kTw3baZpoXbg Content-Language: en-gb X-Originating-IP: 213.162.105.120 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24836.003 X-TM-AS-Result: No--3.601-10.0-31-10 X-imss-scan-details: No--3.601-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24836.003 X-TMASE-Result: 10--3.600900-10.000000 X-TMASE-MatchedRID: zGP2F0O7j/uWfDtBOz4q23FPUrVDm6jtQfblIp3oBdEutoY2UtFqGAix ljkQIWPH1e1Y2Bbm0DCxJZlbR4Xa9gMwOZUXOlJ48KljBsEXXSWOF2tyaUHtw1hs8uimgHNCiDX csfD78rnzIKpPT3XrZvgQJQHmJkh1Cq25NjI+7s1uyDGIvvwW0stEPnVvPlFkI0YrtQLsSUzdzT SUA4s8XtylpSt40vAKMtootpa5vg+/WXZS/HqJ2lOm2gN+noms2bNx1HEv7HAqtq5d3cxkNSb0j EEK2sSIjRtIv+mOdW9hoMPnPwHRYY/gVDUU+nsHWZLEAuMCD71CHytxRRqF0q2zTUOJWMApcxR8 87Z4U29VZ7sE42exF2IbgT35V5pQp8i26iGCN+fD/c2Y8mxrik1Z+dSdugwvVNdRfR1NB08= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-iasa2-rfc7776bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 08:38:56 -0000 Thanks, Melinda. Best, Adrian -----Original Message----- From: Melinda Shore via Datatracker =20 Sent: 09 August 2019 00:53 To: secdir@ietf.org Cc: draft-ietf-iasa2-rfc7776bis.all@ietf.org; ietf@ietf.org; = iasa20@ietf.org Subject: Secdir last call review of draft-ietf-iasa2-rfc7776bis-02 Reviewer: Melinda Shore Review result: Ready This document updates IETF anti-harassment procedures to reflect = organizational changes to the IETF (specifically, the replacement of the IAOC with the = IETF LLC, and the replacement of the IETF Administrative Director with the = IETF LLC Executive Director). Additionally, it updates the text with respect to ombudsteam-initiated recall processes, but it does not change make = changes to the processes themselves. The document is clearly written and = unambiguous, and there are no new security considerations. The document is ready for publication. From nobody Fri Aug 9 09:49:36 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD86B120110; Fri, 9 Aug 2019 09:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1565368346; bh=Rh6CxxkbdPr8+meRiy/6b2q6zmImWFJ0yoDZTJVWOJA=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=gYQ7JPqcKfikKT973y4uiblxfsOVkIJJkBWfP+uUoMJqYa6hXAhZxkKN7BhtC2kWK xuuieqnJets9OOo2+eMqRAFdxXJJO2HAfhARImT3hGOdcWp3JKjSnEtEGJH2WSHSxy eTKsnrU/O9sAaFn/9zOi1LqD5Q2RMFpdUB3GX2lA= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Aug 9 09:32:19 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FE7120133; Fri, 9 Aug 2019 09:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1565368339; bh=Rh6CxxkbdPr8+meRiy/6b2q6zmImWFJ0yoDZTJVWOJA=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=RkDNzXhgABfnPzJLzJCRDa4b7pRORSQQcDXtqbxXuSeu4joYG33UHIcS6SB5snjZK X+CVYmWTDYuJx/8tm/on50O1uoze8Z/R0QcNxMSrH503SuzYVSBZ5XDStouMmXqON/ fo0qPWw9XUWikbFI1Mj+zvDUuPad4z/kZmhOE25M= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9EA12016D for ; Fri, 9 Aug 2019 09:32:09 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: MIME-Version: 1.0 Message-ID: <156536832917.15651.16397332802221197323.idtracker@ietfa.amsl.com> Date: Fri, 09 Aug 2019 09:32:09 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 09 Aug 2019 09:49:35 -0700 Subject: [secdir] [new-work] WG Review: Concise Binary Object Representation Maintenance and Extensions (cbor) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 16:32:38 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) WG in the Applications and Real-Time Area of the IETF is undergoing rechartering. The IESG has not made any determination 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 2019-08-19. Concise Binary Object Representation Maintenance and Extensions (cbor) ----------------------------------------------------------------------- Current status: Active WG Chairs: Francesca Palombini Jim Schaad Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Adam Roach Alexey Melnikov Barry Leiba Mailing list: Address: cbor@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/cbor Archive: https://www.ietf.org/mail-archive/web/cbor/current/maillist.html Group page: https://datatracker.ietf.org/group/cbor/ Charter: https://datatracker.ietf.org/doc/charter-ietf-cbor/ Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 8259) data interchange format to include binary data and an extensibility model, using a binary representation format that is easy to parse correctly. It has been picked up by a number of IETF efforts (e.g., CORE, ANIMA GRASP) as a message format. The CBOR working group will update RFC 7049 to deal with existing errata. Security issues and clarifications may be addressed, but changes to the document will ensure backward compatibility for widespread deployed codebases. The resulting document will be targeted at becoming an Internet Standard. Similar to the way ABNF (RFC 5234/7405) can be used to describe the set of valid messages in a text representation, it is useful for protocol specifications to use a description format for the data in CBOR-encoded messages. The Concise Data Definition Language (CDDL) is such a description technique that has already been used in CORE, ANIMA, CDNI, and efforts outside the IETF. CDDL has been published as RFC 8610. While this specification has been completed, several new features were raised during the update process that were not included, in order not to delay publication, and to allow publication in the Standards Track. One example of such a feature is the ability to combine multiple CDDL files together using a mechanism other than manually concatenating them together for processing. The working group will collect these features as well as other features that are raised by users of CDDL, evaluate their utility and add to a second edition of the specification where warranted. The working group will define the approach to further evolving CDDL as a sequence of editions, which might also add further extension points, probably as part of the introduction of the next edition of the CDDL base specification. The body of existing specifications that make use of CDDL is considered precious, and the WG will set out not to damage their value. The working group will evaluate the necessity of providing advice and guidance for developers using CBOR and CDDL. It is currently expected that this would be done using a Wiki of some type. This work would not be expected to be published by the IETF as an RFC. There are a number of additional CBOR tagged types and CBOR related media type specifications that are currently adopted by the working group, are work items in other working groups, or exist as individual submissions. Additionally, there are expected to be other such documents that will come to the attention of the working group. In some cases, the working group will be asked to adopt and publish these proposals. The working group will evaluate such requests individually and decide about adoption and milestones in that event. Proposals that are deemed to be out of scope for the working group, e.g. because they are too narrow purpose specifications, may still be published as individual submission or in another groups if there is a specific need. The CBOR group will review these proposals on request. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Aug 12 13:27:50 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B843C122617; Mon, 12 Aug 2019 13:27:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Nancy Cam-Winget via Datatracker To: Cc: draft-ietf-manet-dlep-lid-extension.all@ietf.org, manet@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Nancy Cam-Winget Message-ID: <156564165569.17882.915608325158791837@ietfa.amsl.com> Date: Mon, 12 Aug 2019 13:27:35 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-manet-dlep-lid-extension-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 20:27:36 -0000 Reviewer: Nancy Cam-Winget Review result: Has Issues SECDIR review of draft-ietf-manet-dlep-lid-extension-05 Reviewer: Nancy Cam-Winget Review result: Ready with questions (issues?) 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 defines extensions to the Data Link Exchange Protocol (DLEP) to enable modems to advertise the status of wireless links that are not reachable beyond a device on the Layer 2 domain. The extension focuses on the inclusion of IPv4 or IPv6 address(es) to DLEP when the modems provide Layer 3 connectivity. As this is not my area of domain expertise, I have the following questions: * It seems that WANs could include NATs but I see no consideration for how to treat the IP addresses in the presence of NAT. Is this not an issue? I think some mention of this should be included. * Section 2.1: What happens if Link Identifiers span multiple MAC Addresses or if they are reused? What does it mean for a link identifier to be reused (per session? or ever?) There is a reference to the destination MUST NOT be recycled, but I am not sure what recycled means in this context? What happens if they are reused? A note either here, or in the security considerations should describe these conditions. * Section 2.2: what happens if "link identifiers" is negotiated but no link identifiers are provided? * Security (no privacy considerations?): given that this draft is now including IP addresses, it seems that there is potential to determine a network topology and perhaps identification of a network used to mount attacks. I do see that RFC 8175 doesn't have privacy considerations, but given that this is now at the IP layer it may be good to provide one? From nobody Mon Aug 12 17:41:32 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FFC1212CE; Mon, 12 Aug 2019 15:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1565648180; bh=7V6Gs5L9Zx+ky395cH/JEreuqwUypx0yT/R+bQ/N/Uo=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=EvVE/xP1be1Z3Cyhswrow8wz+RYL4hL9ibdWcAjaVPfLR0tvi8sHMLrU51fVjVmB8 MdXwCbzEfEQLtLETdYKowDiilMUWR26bS0fXaKo/Qp89QU/e+eXeP60jycDxB632DV 55L9uDqdvUVPwQJD3LTYcFp+ALaHi0K+octSQ9rM= X-Mailbox-Line: From new-work-bounces@ietf.org Mon Aug 12 15:16:16 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CB3120D84; Mon, 12 Aug 2019 15:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1565648176; bh=7V6Gs5L9Zx+ky395cH/JEreuqwUypx0yT/R+bQ/N/Uo=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=KOnfWKbFPCPjwZbai/ARHHM1ZS6P+pnJgj96xF2Jc6b8CU4l6Tj9EG/q1tnW/euIg rstLm7loHMz7J53UkI8PsDuLcC5DxQ7ViBppFHbObbuacRAIOa8GOVIer7XgbOOBw6 3xpbOM4PoZ7XyYVl+TumqePdBoTcyUYYYQ1yrKBE= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA5E120F92 for ; Mon, 12 Aug 2019 15:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FszpS1IvQk1q for ; Mon, 12 Aug 2019 15:16:10 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8279E120FE0 for ; Mon, 12 Aug 2019 10:16:54 -0700 (PDT) Received: from 228.120.30.93.rev.sfr.net ([93.30.120.228] helo=[192.168.1.23]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hxDwC-00022r-Oy; Mon, 12 Aug 2019 17:16:52 +0000 From: Coralie Mercier Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 12 Aug 2019 19:16:52 +0200 Message-Id: To: new-work@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Mon, 12 Aug 2019 17:41:31 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Timed Text Working Group (until 2019-09-10) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 22:16:23 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Timed Text Working Group: https://www.w3.org/2019/08/ttwg-proposed-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2019-09-10 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Atsushi Shimono, Team Contact . Thank you, Coralie Mercier, Head of W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Marketing & Communications - https://www.w3.org mailto:coralie@w3.org +337 810 795 22 https://www.w3.org/People/Coralie/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Aug 12 18:08:32 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5942120033; Mon, 12 Aug 2019 18:08:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner via Datatracker To: Cc: rmcat@ietf.org, draft-ietf-rmcat-nada.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Sean Turner Message-ID: <156565849881.20488.4580765481520503258@ietfa.amsl.com> Date: Mon, 12 Aug 2019 18:08:18 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-rmcat-nada-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 01:08:19 -0000 Reviewer: Sean Turner Review result: Has Nits Hi! I'm no congestion control expert so nothing in the main body jumped out at me. I did take a little time to review some security considerations for other congestion control RFCs and just wanted to make sure the same kind of information is getting addressed. I indicated the result of this review as "has nits" because there is a pretty good chance I am just suggesting some editorial tweaks. The security considerations rightly points out that this mechanism is susceptible to the same kind of attacks as TCP (e.g., hijack, replacement) and what mitigations to use (i.e., integrity protection of the RTCP feedback messages). But, what is missing is what happens if these attacks succeed: DoS or in the worst case congestion collapse? So, maybe instead of: As such, it is vulnerable to attacks where feedback messages are hijacked, replaces, or intentionally injected with misleading information, similar to those that can affect TCP. Maybe: As such, it is vulnerable to attacks where feedback messages are hijacked, replaces, or intentionally injected with misleading information resulting in denial of service, similar to those that can affect TCP. Also, unless I've completely misread this paragraph it seems like you are talking about two things: 1) it's just like TCP, and 2) "The modification of sending rate ...". So, maybe split the paragraph along those lines. Further questions: 1. Are there any concerns related to a greedy receiver who wants to gobble up more than its fair share of network bandwidth? 2. Seems like maybe you also need to refer to the RTP/RTCP security considerations because it seems like security primarily needs to be considered in the context of a specific transport protocol and its authentication mechanisms. Cheers, spt From nobody Tue Aug 13 00:57:30 2019 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 5794C120091; Tue, 13 Aug 2019 00:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R36mZicGgru8; Tue, 13 Aug 2019 00:57:11 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id E2A16120074; Tue, 13 Aug 2019 00:57:07 -0700 (PDT) Received: from MacBook-Pro-5.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 737FE1B0015C; Tue, 13 Aug 2019 08:56:59 +0100 (BST) Message-ID: <5D526D4A.5010304@erg.abdn.ac.uk> Date: Tue, 13 Aug 2019 08:56:58 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Sean Turner CC: Sean Turner via Datatracker , secdir@ietf.org, rmcat@ietf.org, draft-ietf-rmcat-nada.all@ietf.org, ietf@ietf.org References: <156565849881.20488.4580765481520503258@ietfa.amsl.com> In-Reply-To: <156565849881.20488.4580765481520503258@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] [rmcat] Secdir last call review of draft-ietf-rmcat-nada-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 07:57:14 -0000 See below: On 13/08/2019, 02:08, Sean Turner via Datatracker wrote: > Reviewer: Sean Turner > Review result: Has Nits > > Hi! I'm no congestion control expert so nothing in the main body jumped out at > me. I did take a little time to review some security considerations for other > congestion control RFCs and just wanted to make sure the same kind of > information is getting addressed. I indicated the result of this review as > "has nits" because there is a pretty good chance I am just suggesting some > editorial tweaks. > > The security considerations rightly points out that this mechanism is > susceptible to the same kind of attacks as TCP (e.g., hijack, replacement) and > what mitigations to use (i.e., integrity protection of the RTCP feedback > messages). But, what is missing is what happens if these attacks succeed: DoS > or in the worst case congestion collapse? So, maybe instead of: > > As such, it is vulnerable to attacks where feedback > messages are hijacked, replaces, or intentionally injected with > misleading information, similar to those that can affect TCP. > > Maybe: > > As such, it is vulnerable to attacks where feedback > messages are hijacked, replaces, or intentionally injected with > misleading information resulting in denial of service, similar > to those that can affect TCP. > > Also, unless I've completely misread this paragraph it seems like you are > talking about two things: 1) it's just like TCP, and 2) "The modification of > sending rate ...". So, maybe split the paragraph along those lines. > > Further questions: > > 1. Are there any concerns related to a greedy receiver who wants to gobble up > more than its fair share of network bandwidth? > > 2. Seems like maybe you also need to refer to the RTP/RTCP security > considerations because it seems like security primarily needs to be considered > in the context of a specific transport protocol and its authentication > mechanisms. > > Cheers, > > spt I also think that text (or similar) would also be valuable in the security considerations section. Gorry From nobody Tue Aug 13 07:37:53 2019 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 BE7D2120889 for ; Tue, 13 Aug 2019 07:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqeCWezYTJKu for ; Tue, 13 Aug 2019 07:37:44 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F299D12088F for ; Tue, 13 Aug 2019 07:37:43 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id m2so15527582qkd.10 for ; Tue, 13 Aug 2019 07:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=X8OM5H+1v1W7uzx0us5gamjGJ3utDvZJZ3scolJYXQY=; b=g7zXRDYSiy8sJvyqmCxeLuPMIRtM50gbG3MlIPwbRlIK+U3ZjgTAfRYrJY5i7+Nrk7 TjwhLgJaX6aA9oraBzVMnn71xRRVq4PuVJ+yd2do90R6/rg2cwhs6B31jrZhx777JB1M 46w5AH3GAu3n9RF3/MzBAO0q9IZRae4HhDhFw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-transfer-encoding; bh=X8OM5H+1v1W7uzx0us5gamjGJ3utDvZJZ3scolJYXQY=; b=NiejxjT1k7VRpd3WpJ8ty12eC1ezAO2NQZDmZNljiQEpF7Ncc4kr8vDQqipwC7mg7X Rv2bnHESOhmW6rQJfotVyRfuE3stjw9YlJ0eaAgqORHEV4310x0Kp2PpFn7DvFGKwdWn Rd8krj1SLLZSXPZr3mIi8EtKojJ0OT6uPuhW0W2lyZjFDejy+mNrbJrCdDmsamoUv6XS cTezSU77ACgjnzd4Av/2X3N2/UNyhwqmQe2zZqbEU2AWPKnt0XlbASI7y5i0swlbXNoF ufGX0+EFVhssUS3nlY9tnzZIm/fVh3WzoPgyU13db7Mp6PIM9NI27MQVPY8MYocqBsjj F1Xw== X-Gm-Message-State: APjAAAW40q0ewnBLgKbaAgLNBVz7Y3CuZOM9m2FGqdCFI9t/6ufsMZ0D RrV/Y+rZnEM5t1jsLZaKfytaoQ== X-Google-Smtp-Source: APXvYqzaiawExX46RKT6jqlVcEhaw5oJQZTAL8RicjpVLwbV/t0vrqOTGFfPyywwJZCnUXEyXKF5KA== X-Received: by 2002:ae9:c303:: with SMTP id n3mr33672776qkg.372.1565707062997; Tue, 13 Aug 2019 07:37:42 -0700 (PDT) Received: from [192.168.1.5] (110.sub-174-242-87.myvzw.com. [174.242.87.110]) by smtp.googlemail.com with ESMTPSA id o18sm5310684qtt.4.2019.08.13.07.37.32 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 13 Aug 2019 07:37:42 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.7.6.170621 Date: Tue, 13 Aug 2019 10:37:34 -0400 From: Carl Wallace To: , , Message-ID: Thread-Topic: secdir review of draft-ietf-tls-grease Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-tls-grease X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 14:37:52 -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 a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values. Aside from a nit/question, the document is ready. The question relates to language in section 2. which states: "The values allocated above are thus no longer available for use as TLS or DTLS [RFC6347] version numbers." Should this draft be marked as updating 6347 and 8446 as a result? At present it is Informational and does not update any other specifications. From nobody Tue Aug 13 08:52:34 2019 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 8F6341200FA for ; Tue, 13 Aug 2019 08:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzP4WjmESZnH for ; Tue, 13 Aug 2019 08:52:29 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E83120273 for ; Tue, 13 Aug 2019 08:52:29 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id j15so13222111qtl.13 for ; Tue, 13 Aug 2019 08:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jSFF+SmVZBRyN4TdQJT+4Hz9oKz5tg8Jkygdw6mZumo=; b=MwFcVS2hMxZUssfoBc0b3g8AfdxaTWsmmleh/uC5UAR+kw3JiLdJVDqRR6VRikkVuH jXeyIk4gfHazAT0jJHdhn+zXKRixATt5XhHvpqyuoQI9q1FI3UAeQv2X3u2E0rGmtcV3 pelFhz19jGPTUbBGEUnOpSG6agL7dKM5GDQXw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jSFF+SmVZBRyN4TdQJT+4Hz9oKz5tg8Jkygdw6mZumo=; b=h5m73vynPcQw16Nt4A/KDkQpTSoh7iiOXGhYOkmCuMt2T8Xg4paF6gVO7X7Qm9nCC1 M82DI3mvp3WDPOubSUYK7aU3sj5MCuE6vbodAKqPnmqULL0R0CL4q9YCMo708oIyt2a6 gvogG0DoRqYFLugpvF745Wx55HF6RQvHis645vXCEGbkAzoATazI+6GGWcgQKYF1OJyo /RkWyjoC3xKK2rJ7fm3RMP53aFY4o4vfGBT0O5LZdutJRUYasxUK9zYJX6uC1wZNQoks NpIF+4ZY3oDwyZw7OROFp+DZ1v0DC6UDGL7KNNLq7hk5/F9WkoZPc6BL1Dho0l9zF3IC gQUg== X-Gm-Message-State: APjAAAXbcIbu4fUFatnjjtIm6dptFjKTVdygS2PqPWfEh+ehfJmFBghy XmUXPoyjZcpi8zMjiD+1qBcHWQ== X-Google-Smtp-Source: APXvYqyndEdffyyY27HkJX/aC9G4tB33kddBT0LZCG6DZ/BOCL2tDAAXif24bUZ7UBJ4cj+tCzFKrg== X-Received: by 2002:ac8:7402:: with SMTP id p2mr13785663qtq.182.1565711548708; Tue, 13 Aug 2019 08:52:28 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id k25sm60601035qta.78.2019.08.13.08.52.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Aug 2019 08:52:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: Date: Tue, 13 Aug 2019 11:52:27 -0400 Cc: The IESG , secdir@ietf.org, draft-ietf-tls-grease.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1BF964FE-2217-4063-B8F5-1FAC1FE050E5@sn3rd.com> References: To: Carl Wallace X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tls-grease X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 15:52:33 -0000 > On Aug 13, 2019, at 10:37, Carl Wallace = wrote: >=20 > 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. >=20 > This document describes a mechanism to prevent extensibility failures = in > the TLS ecosystem. It reserves a set of TLS protocol values that may = be > advertised to ensure peers correctly handle unknown values. Aside from = a > nit/question, the document is ready. >=20 > The question relates to language in section 2. which states: "The = values > allocated above are thus no longer available for use as TLS or DTLS > [RFC6347] version numbers." Should this draft be marked as updating = 6347 > and 8446 as a result? At present it is Informational and does not = update > any other specifications. I tend to think that an updates header is not required. RFCs that = allocate and reserve code points do not need to update the RFC that = originally created them. For example, RFC5764/RFC7983 reserve a block = of TLS ContentType space and neither of the those drafts updated the = base TLS spec. spt From nobody Tue Aug 13 09:00:39 2019 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 BB08F12083B for ; Tue, 13 Aug 2019 09:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVkNhstVvij1 for ; Tue, 13 Aug 2019 09:00:28 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21EF0120800 for ; Tue, 13 Aug 2019 09:00:28 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id k13so9551192qtm.12 for ; Tue, 13 Aug 2019 09:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t0/1qYwZGMUAh4uBbizkQMj0HccrI54ubgMuwuTYfFY=; b=ZZGkzn6+jIPtjSso6t04RJE3NhySk8Ezox5SPsgKuVHDYbntqnx+XO95N/sr6IcKbd YrmrFAaAEaPZ0EjxpI17/582gr5rJUWBr8EORa0z0CqAsySQ0kR7gdQXi76SX1hbvlr7 WNKUijn9l5HGi9sMDgbXRBqr+kgW7rZ0hJnm4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t0/1qYwZGMUAh4uBbizkQMj0HccrI54ubgMuwuTYfFY=; b=TfJt/BCTjQtWcVGqianEOSQSiX50S+TnPjzGZJ1YQ5Tk15AP0OX3WzY/zpMJ1o2jR2 hyNr4JLYLokcHGdRCZg1VkXoCnyNawuthHDtPGIx+40+Qf2FhlpdQOJcUGPUPGZvIvjE UlLjgGMYVzvecEe36/4rRUJ8DL7irf0CGXIySF34YwgEoW6CPLpiJ2W6e627ebDK09o7 46yKz7XlXPQEcihCKHUZt+GmzvjjSJQBbdraBKtlNgvFGDOHRLAZRKek3A3AlfH5UU43 WtjND4Y49elf3n8CS3sCfo54aiAl3/0KOIWoQrpGyCJ7kCITOOUlAVlMe85f+o9D1RXg X+Rg== X-Gm-Message-State: APjAAAUjyxU2q6UGtii3H72SN89XQmPdj6Rmh6aRP3XN4vYYQm586Yox hDMi7B75p+6gkWUuIzer+hHFENL+NblMPl57rk3mY9Kn X-Google-Smtp-Source: APXvYqy0oJAfsD/uGmcNClEfZkPxqIhhDkFOw4rgrqhzSivCWu3H5P3q8xXh+xnSgmOJNPn7gje7p+zcwCHw8Mygy3c= X-Received: by 2002:ac8:7094:: with SMTP id y20mr6979583qto.140.1565712027148; Tue, 13 Aug 2019 09:00:27 -0700 (PDT) MIME-Version: 1.0 References: <1BF964FE-2217-4063-B8F5-1FAC1FE050E5@sn3rd.com> In-Reply-To: <1BF964FE-2217-4063-B8F5-1FAC1FE050E5@sn3rd.com> From: Carl Wallace Date: Tue, 13 Aug 2019 12:00:15 -0400 Message-ID: To: Sean Turner Cc: The IESG , secdir@ietf.org, draft-ietf-tls-grease.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000331a08059001bd15" Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tls-grease X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 16:00:37 -0000 --000000000000331a08059001bd15 Content-Type: text/plain; charset="UTF-8" OK. Impacting the version number stream was a new thing to my eye. Seemed worth asking. On Tue, Aug 13, 2019 at 11:52 AM Sean Turner wrote: > > > On Aug 13, 2019, at 10:37, Carl Wallace > 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 describes a mechanism to prevent extensibility failures in > > the TLS ecosystem. It reserves a set of TLS protocol values that may be > > advertised to ensure peers correctly handle unknown values. Aside from a > > nit/question, the document is ready. > > > > The question relates to language in section 2. which states: "The values > > allocated above are thus no longer available for use as TLS or DTLS > > [RFC6347] version numbers." Should this draft be marked as updating 6347 > > and 8446 as a result? At present it is Informational and does not update > > any other specifications. > > I tend to think that an updates header is not required. RFCs that > allocate and reserve code points do not need to update the RFC that > originally created them. For example, RFC5764/RFC7983 reserve a block of > TLS ContentType space and neither of the those drafts updated the base TLS > spec. > > spt > > --000000000000331a08059001bd15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK. Impacting the version number stream was a new thing to= my eye. Seemed worth asking.

On Tue, Aug 13, 2019 at 11:52 AM Sean Turner = <sean@sn3rd.com&= gt; wrote:

> On Aug 13, 2019, at 10:37, Carl Wallace <carl@redhoundsoftware.com> wrot= e:
>
> I have reviewed this document as part of the security directorate'= s
> ongoing effort to review all IETF documents being processed by the IES= G.
> These comments were written primarily for the benefit of the security = area
> directors.=C2=A0 Document editors and WG chairs should treat these com= ments
> just like any other last call comments.
>
> This document describes a mechanism to prevent extensibility failures = in
> the TLS ecosystem.=C2=A0 It reserves a set of TLS protocol values that= may be
> advertised to ensure peers correctly handle unknown values. Aside from= a
> nit/question, the document is ready.
>
> The question relates to language in section 2. which states: "The= values
> allocated above are thus no longer available for use as TLS or DTLS > [RFC6347] version numbers." Should this draft be marked as updati= ng 6347
> and 8446 as a result? At present it is Informational and does not upda= te
> any other specifications.

I tend to think that an updates header is not required.=C2=A0 RFCs that all= ocate and reserve code points do not need to update the RFC that originally= created them.=C2=A0 For example, RFC5764/RFC7983 reserve a block of TLS Co= ntentType space and neither of the those drafts updated the base TLS spec.<= br>
spt

--000000000000331a08059001bd15-- From nobody Tue Aug 13 10:57:04 2019 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 3D9A0120145; Tue, 13 Aug 2019 10:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs6fYFy-YK90; Tue, 13 Aug 2019 10:57:01 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B3612013A; Tue, 13 Aug 2019 10:57:01 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7DHuu3Z007269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Aug 2019 13:56:59 -0400 Date: Tue, 13 Aug 2019 12:56:56 -0500 From: Benjamin Kaduk To: Carl Wallace Cc: Sean Turner , The IESG , secdir@ietf.org, draft-ietf-tls-grease.all@ietf.org Message-ID: <20190813175655.GO88236@kduck.mit.edu> References: <1BF964FE-2217-4063-B8F5-1FAC1FE050E5@sn3rd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tls-grease X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 17:57:03 -0000 It's definitely worth asking, so thank you. The version number space here seems particularly unique, in that it's not maintained in a registry and in general each "codepoint" in the space will have its own dedicated protocol and protocol document. So in that sense any act on the version number space cannot be tied down to a single protocol version's document, and is instead part of the broader ecosystem for the family of protocols. -Ben On Tue, Aug 13, 2019 at 12:00:15PM -0400, Carl Wallace wrote: > OK. Impacting the version number stream was a new thing to my eye. Seemed > worth asking. > > On Tue, Aug 13, 2019 at 11:52 AM Sean Turner wrote: > > > > > > On Aug 13, 2019, at 10:37, Carl Wallace > > 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 describes a mechanism to prevent extensibility failures in > > > the TLS ecosystem. It reserves a set of TLS protocol values that may be > > > advertised to ensure peers correctly handle unknown values. Aside from a > > > nit/question, the document is ready. > > > > > > The question relates to language in section 2. which states: "The values > > > allocated above are thus no longer available for use as TLS or DTLS > > > [RFC6347] version numbers." Should this draft be marked as updating 6347 > > > and 8446 as a result? At present it is Informational and does not update > > > any other specifications. > > > > I tend to think that an updates header is not required. RFCs that > > allocate and reserve code points do not need to update the RFC that > > originally created them. For example, RFC5764/RFC7983 reserve a block of > > TLS ContentType space and neither of the those drafts updated the base TLS > > spec. > > > > spt > > > > From nobody Wed Aug 14 20:40:14 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE40120F46; Wed, 14 Aug 2019 20:39:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liang Xia via Datatracker To: Cc: draft-ietf-6man-segment-routing-header.all@ietf.org, ipv6@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Liang Xia Message-ID: <156584039497.2287.2516898029582755543@ietfa.amsl.com> Date: Wed, 14 Aug 2019 20:39:55 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-6man-segment-routing-header-22 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 03:39:55 -0000 Reviewer: Liang Xia Review result: Has Issues Some nits: 1. title of Section 4.3.2: /FIB Entry is a Local Interface/FIB Entry Is A Local Interface 2. title of Section 5.2: /SR Domain as a single system with delegation among components/SR Domain as A Single System with Delegation among Components 3. Section 2.1.1: /There are two types of padding TLVs, pad1 and padN, the following applies to both/There are two types of Padding TLVs, pad1 and padN, the following applies to both 4. Section 2.1.2: "Alignment requirement: 8n". What is 8n? For better readability, can you give a more clear clarification text? 5. Section 4.1: /HMAC TLV may be set according to Section 7./HMAC TLV may be set according to Section 2.1.2./? 6. Section 4.3: have a "*" before every item of "A FIB entry..." ? 1 issue: The Security Considerations Section mainly clarifies the security protection based on the strict SR Domain boundary protection paradigm, and the considerations of some identified attacks. They are valuable, but maybe not complete in scope. I noticed 2 SR related security consideration drafts (draft-perkins-sr-security-00 and draft-li-spring-srv6-security-consideration-00), which are trying to summarize all the possible vulnerabilities in SR network. I personally suggests the authors to review them and consider how to reference or incorporate the valuable considerations from them. From nobody Thu Aug 15 02:33:03 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3D912003F for ; Thu, 15 Aug 2019 02:33:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <156586158196.15824.11346722280311622060.idtracker@ietfa.amsl.com> Date: Thu, 15 Aug 2019 02:33:01 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 09:33:02 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-08-22 Reviewer LC end Draft Derek Atkins 2019-08-15 draft-ietf-opsec-urpf-improvements-03 Phillip Hallam-Baker 2019-08-06 draft-ietf-lamps-cms-mix-with-psk-06 Last calls: Reviewer LC end Draft Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-31 Roman Danyliw 2019-06-04 draft-ietf-rtgwg-enterprise-pa-multihoming-12 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Linda Dunbar 2019-08-28 draft-ietf-cdni-request-routing-extensions-05 Donald Eastlake 2019-08-28 draft-ietf-pce-stateful-path-protection-08 Shawn Emery 2019-08-28 draft-ietf-pce-lsp-control-request-07 Stephen Farrell 2019-08-28 draft-ietf-pce-stateful-hpce-11 Daniel Franke 2019-08-28 draft-ietf-pce-stateful-pce-auto-bandwidth-10 Daniel Gillmor 2019-08-27 draft-ietf-lsr-isis-rfc5306bis-04 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Tobias Gondrom 2019-08-26 draft-ietf-curdle-ssh-curves-09 Aanchal Malhotra 2019-06-26 draft-ietf-ipwave-ipv6-over-80211ocb-52 Kathleen Moriarty 2019-07-11 draft-ietf-ospf-xaf-te-06 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-17 Magnus Nystrom 2019-06-20 draft-ietf-mmusic-ice-sip-sdp-39 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Derrell Piper 2019-08-01 draft-ietf-mile-jsoniodef-10 Tim Polk 2019-08-01 draft-ietf-acme-star-06 David Waltermire 2019-08-07 draft-ietf-oauth-jwt-introspection-response-05 Brian Weis 2019-08-05 draft-ietf-oauth-resource-indicators-05 Christopher Wood 2019-08-30 draft-klensin-idna-unicode-review-02 Paul Wouters 2019-08-30 draft-klensin-idna-rfc5891bis-04 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-12 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Next in the reviewer rotation: Steve Hanna Dan Harkins Russ Housley Christian Huitema Leif Johansson Benjamin Kaduk Charlie Kaufman Scott Kelly Stephen Kent Tero Kivinen From nobody Thu Aug 15 19:02:28 2019 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 8F49D120105; Thu, 15 Aug 2019 19:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEVUgukBdvee; Thu, 15 Aug 2019 19:02:11 -0700 (PDT) Received: from Mail1.Yoyodyne.COM (mail1.yoyodyne.com [IPv6:2604:4ec0:3::7]) by ietfa.amsl.com (Postfix) with SMTP id 3E463120103; Thu, 15 Aug 2019 19:02:07 -0700 (PDT) Received: from [10.0.4.2] ([24.5.60.91]) by Mail1.Yoyodyne.COM via Internet for (and others); Thu, 15 Aug 2019 19:02:06 PDT From: Derrell Piper Content-Type: multipart/signed; boundary="Apple-Mail=_EA62446C-B4ED-447A-A15C-4D448D6EF8C7"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <6BAF40A3-4FC3-44D6-8C25-CDAC41DF0EE8@electric-loft.org> Date: Thu, 15 Aug 2019 19:02:05 -0700 To: draft-ietf-mile-jsoniodef.all@ietf.org, secdir@ietf.org, ietf@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [secdir] Secdir Last Call assignment: draft-ietf-mile-jsoniodef X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 02:02:13 -0000 --Apple-Mail=_EA62446C-B4ED-447A-A15C-4D448D6EF8C7 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Reviewer: Derrell Piper Review result: Ready 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 simply a JSON schema definition for IODEF RFC7970 and introduces no new security concerns. --Apple-Mail=_EA62446C-B4ED-447A-A15C-4D448D6EF8C7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCkkw ggTpMIID0aADAgECAgRMDowbMA0GCSqGSIb3DQEBCwUAMIG0MRQwEgYDVQQKEwtFbnRydXN0Lm5l dDFAMD4GA1UECxQ3d3d3LmVudHJ1c3QubmV0L0NQU18yMDQ4IGluY29ycC4gYnkgcmVmLiAobGlt aXRzIGxpYWIuKTElMCMGA1UECxMcKGMpIDE5OTkgRW50cnVzdC5uZXQgTGltaXRlZDEzMDEGA1UE AxMqRW50cnVzdC5uZXQgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgKDIwNDgpMB4XDTExMTExMTE1 MjU1MVoXDTIxMTExMTIzMjc1MFowgaUxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJ bmMuMTkwNwYDVQQLEzB3d3cuZW50cnVzdC5uZXQvQ1BTIGlzIGluY29ycG9yYXRlZCBieSByZWZl cmVuY2UxHzAdBgNVBAsTFihjKSAyMDEwIEVudHJ1c3QsIEluYy4xIjAgBgNVBAMTGUVudHJ1c3Qg Q2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpYPyALmJw k4z2GWJLrTZYlw5O/p2PAC4//myCDUGGIyPWk82D/o9D4eLrbSgbEbsB+uuATnNe3lrFqjozsYve eNIk+9EUvZRNkl+YNFn/2IY2HHe4YWJWWPuAVQ8DKYR96NCzpt/1Irgkv+QDrHksTX5aqBIPAfjN EJPPLRyzdGuH277CsWcjDujjxxDFAzi3yAVFoIvsJBXdyxw4X2aZCLP315HcX5cHYtxBnI7RxjX2 U6d3rmgUNaRnEz5JjW6+nyCjn6h3Gbw4u1XTYM6g/q+33EwZmpNz6Je+BT9/d/JppfedXvTg+A6w Ivs+qDYabkTEj6Rq1baljNyc87AHAgMBAAGjggEOMIIBCjAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0T AQH/BAgwBgEB/wIBADAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmVu dHJ1c3QubmV0MDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9jcmwuZW50cnVzdC5uZXQvMjA0OGNh LmNybDA7BgNVHSAENDAyMDAGBFUdIAAwKDAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5lbnRydXN0 Lm5ldC9ycGEwHQYDVR0OBBYEFEeQpKEKQyC/0HRUuJT6xHu1thwFMB8GA1UdIwQYMBaAFFXkgdER gL7YibkIozH5oSQJFrlwMA0GCSqGSIb3DQEBCwUAA4IBAQBRNMJxm4DOQpk8ZWRM0mdOp4ztTrBK BziTwUc5VbZR0WIBIGejvX4gL5Rhj8Y3/xbcABb9RUBAfkGHHIxhIyf12Jj9JTA7oavzcvrNMJ20 wrbKtOLFeUu0cFCRuxdhT0dWMJ0Z3g8bPbWd7Gu7hjIYZ5/Fhc/Hw3duZwZ1t0CpyLtuhIhJhaSO Zez4sXqT0VvgLb0AXWhWd9zzoHrnx23FqW620NhJlH6CTDbMH+JptP6NT5Xr/uGFFJhkVnYDhHx6 wMjd4KBhnYvnbYbSdamln6CWcEXVwBk2ioUtrIHjYEFYxEd7jqvZEtAu20Z5KHvMK67Tgqp0Cqgy kXqbEa+bMIIFWDCCBECgAwIBAgIQEd9X2KIWvBwAAAAATDO9SzANBgkqhkiG9w0BAQsFADCBpTEL MAkGA1UEBhMCVVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xOTA3BgNVBAsTMHd3dy5lbnRydXN0 Lm5ldC9DUFMgaXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTEfMB0GA1UECxMWKGMpIDIwMTAg RW50cnVzdCwgSW5jLjEiMCAGA1UEAxMZRW50cnVzdCBDbGFzcyAxIENsaWVudCBDQTAeFw0xODEx MTMyMjAxMzBaFw0xOTExMTMyMjMxMjdaMIGfMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAsTLkVudHJ1c3QgQ2xhc3MgMSBJZGVudGl0eSBDZXJ0aWZpY2F0aW9uIFNlcnZp Y2UxHjAcBgNVBAMMFWRkcEBlbGVjdHJpYy1sb2Z0Lm9yZzEkMCIGCSqGSIb3DQEJARYVZGRwQGVs ZWN0cmljLWxvZnQub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA04HrzV6j2isr QECHjetWFZ771HycrJfmWjXghDOMbHhotvv+Fget4HTze2EPnMtcSxT36MILnmpEDhzXZzMHnom6 M6eqo7QK17Mn1bE9oeOeNiCH0LbHwuqpYQ0EgXul5wwngHN5asgabILySG0ecF+Utuf7+yH8+Ufc OMlLe0MRONJhNCeeGDZiRkG5TrysslzBw/KsGE5w9/DIrPLDZZB1XK2hbmq8RusV9UYPB9zZhETo IOrdaoo0yIDa3e7o8RkmU3cjQxbksNmEuw0lKEnPMmku6vpXgYk/y0TmFmyoyt6hjl8SNWjVMWDs ZQS5Jh/68alzEtidEkxF0KHIwQIDAQABo4IBhjCCAYIwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDBCBgNVHSAEOzA5MDcGC2CGSAGG+mwKAQQBMCgwJgYIKwYB BQUHAgEWGmh0dHA6Ly93d3cuZW50cnVzdC5uZXQvcnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwuZW50cnVzdC5uZXQvY2xhc3MxY2EuY3JsMGoGCCsGAQUFBwEBBF4wXDAjBggrBgEFBQcw AYYXaHR0cDovL29jc3AuZW50cnVzdC5uZXQwNQYIKwYBBQUHMAKGKWh0dHA6Ly9haWEuZW50cnVz dC5uZXQvMjA0OGNsYXNzMXNoYTIuY2VyMCAGA1UdEQQZMBeBFWRkcEBlbGVjdHJpYy1sb2Z0Lm9y ZzAfBgNVHSMEGDAWgBRHkKShCkMgv9B0VLiU+sR7tbYcBTAdBgNVHQ4EFgQU+J5uDdWXcSluFwxv Z2FeWBJX+HYwCQYDVR0TBAIwADANBgkqhkiG9w0BAQsFAAOCAQEAA5tIRug94hPDaWBEb9Tl/poX gTZjtCtVStEvz7Rs0FL6OqoeBJZhvyrgCvHbIzqMP+VU+7aLs+1DSSkekaCKj80bYFpZ+4qqpZHz AWy80jVdu+N8+GW9zKXNEcOEa3Fm8Wpl2P3agIRygKxAAa/gvqd263C7VeYaS0JX85a/dR1BItHP D/3F4Pe36QO7Te1/EXv+CScdAHR84grEtX6rwGFqzipUBAR2UfpTyBk422X+6t63nUT5FK5xYPgL 0SPHct0cvEosPGaDprzHBfVJQHVvgj0XC2b8zHy/g6tiboB2o0x/x4JQnA1+Yr1dtOmPpTPqeud6 tturBV8skRB2yDGCA/EwggPtAgEBMIG6MIGlMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNRW50cnVz dCwgSW5jLjE5MDcGA1UECxMwd3d3LmVudHJ1c3QubmV0L0NQUyBpcyBpbmNvcnBvcmF0ZWQgYnkg cmVmZXJlbmNlMR8wHQYDVQQLExYoYykgMjAxMCBFbnRydXN0LCBJbmMuMSIwIAYDVQQDExlFbnRy dXN0IENsYXNzIDEgQ2xpZW50IENBAhAR31fYoha8HAAAAABMM71LMA0GCWCGSAFlAwQCAQUAoIIC BzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA4MTYwMjAyMDZa MC8GCSqGSIb3DQEJBDEiBCA6uq2LEgzXPkvUWrGNt7JDPT0qM10gPko7rVEjI22OPjCBywYJKwYB BAGCNxAEMYG9MIG6MIGlMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjE5MDcG A1UECxMwd3d3LmVudHJ1c3QubmV0L0NQUyBpcyBpbmNvcnBvcmF0ZWQgYnkgcmVmZXJlbmNlMR8w HQYDVQQLExYoYykgMjAxMCBFbnRydXN0LCBJbmMuMSIwIAYDVQQDExlFbnRydXN0IENsYXNzIDEg Q2xpZW50IENBAhAR31fYoha8HAAAAABMM71LMIHNBgsqhkiG9w0BCRACCzGBvaCBujCBpTELMAkG A1UEBhMCVVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xOTA3BgNVBAsTMHd3dy5lbnRydXN0Lm5l dC9DUFMgaXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTEfMB0GA1UECxMWKGMpIDIwMTAgRW50 cnVzdCwgSW5jLjEiMCAGA1UEAxMZRW50cnVzdCBDbGFzcyAxIENsaWVudCBDQQIQEd9X2KIWvBwA AAAATDO9SzANBgkqhkiG9w0BAQEFAASCAQBvIz8UQueixz+OeGY08dCFDpnYrZ75/NlWbizQk6sw 2+GVmQ2qDBRYShCmMb8AZCxmpsqTfivsl5Io1rokg+tr8h83N9YUBMUX9NZZeI5fv+UOIGFMDnX/ DAVJ0CNgAcZFJj19gL+qBuBllz84Z5Ix5H5VgiVYvKECd/0A+HQDnUv+T0n7dAybXUV5t3kcaM87 OH0mtWqGj2qKDvTPCZPFGPOqCd0wkmtR7uTVwJqLLJ5VRwERnJA71zfwXHKG2qhnSahcnzLsylRf gTWq08n1VvBUD0gwuvZraMW2XAJ8eFhdOrDBhoIL5BTML9JRWIQeqSJzI+hc4KqEsZ6dSJ0gAAAA AAAA --Apple-Mail=_EA62446C-B4ED-447A-A15C-4D448D6EF8C7-- From nobody Fri Aug 16 06:00:06 2019 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 585271200A1; Fri, 16 Aug 2019 05:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKHdKUf7zNCc; Fri, 16 Aug 2019 05:59:44 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9CA120089; Fri, 16 Aug 2019 05:59:43 -0700 (PDT) Received: from [129.192.10.3] (helo=[10.149.1.218]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hybpT-0003Na-0J; Fri, 16 Aug 2019 14:59:39 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <5D526D4A.5010304@erg.abdn.ac.uk> Date: Fri, 16 Aug 2019 14:59:37 +0200 Cc: secdir@ietf.org, rmcat@ietf.org, draft-ietf-rmcat-nada.all@ietf.org, IETF Content-Transfer-Encoding: quoted-printable Message-Id: <8EB353C0-FC34-4514-8283-0D1654EE48DD@kuehlewind.net> References: <156565849881.20488.4580765481520503258@ietfa.amsl.com> <5D526D4A.5010304@erg.abdn.ac.uk> To: G Fairhurst , Sean Turner X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1565960383;fc1f65c5; X-HE-SMSGID: 1hybpT-0003Na-0J Archived-At: Subject: Re: [secdir] [rmcat] Secdir last call review of draft-ietf-rmcat-nada-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 12:59:47 -0000 Hi Sean, hi Gorry, Thanks for your review and feedback. Please see below. > On 13. Aug 2019, at 09:56, Gorry Fairhurst = wrote: >=20 > See below: >=20 > On 13/08/2019, 02:08, Sean Turner via Datatracker wrote: >> Reviewer: Sean Turner >> Review result: Has Nits >>=20 >> Hi! I'm no congestion control expert so nothing in the main body = jumped out at >> me. I did take a little time to review some security considerations = for other >> congestion control RFCs and just wanted to make sure the same kind of >> information is getting addressed. I indicated the result of this = review as >> "has nits" because there is a pretty good chance I am just suggesting = some >> editorial tweaks. >>=20 >> The security considerations rightly points out that this mechanism is >> susceptible to the same kind of attacks as TCP (e.g., hijack, = replacement) and >> what mitigations to use (i.e., integrity protection of the RTCP = feedback >> messages). But, what is missing is what happens if these attacks = succeed: DoS >> or in the worst case congestion collapse? So, maybe instead of: >>=20 >> As such, it is vulnerable to attacks where feedback >> messages are hijacked, replaces, or intentionally injected with >> misleading information, similar to those that can affect TCP. >>=20 >> Maybe: >>=20 >> As such, it is vulnerable to attacks where feedback >> messages are hijacked, replaces, or intentionally injected with >> misleading information resulting in denial of service, similar >> to those that can affect TCP. >>=20 >> Also, unless I've completely misread this paragraph it seems like you = are >> talking about two things: 1) it's just like TCP, and 2) "The = modification of >> sending rate ...". So, maybe split the paragraph along those lines. I think this is actually based on text that we used for scream (now = RFC8298) which is another congestion control developed in rmcat. I think = we refined that text also based on a SEC (or GEN?) review comment at = that time and people were at the end satisfied with it. However, your = proposed change above could surely be integrated and I leave it to the = authors if they want to refine the text further.=20 >>=20 >> Further questions: >>=20 >> 1. Are there any concerns related to a greedy receiver who wants to = gobble up >> more than its fair share of network bandwidth? This is a very general point for all congestion control schemes, and for = rmcat it is also discussed in draft-ietf-rmcat-cc-requirements (which is = sitting in the RFC editor queue for a while as part of the 238 = cluster=E2=80=A6). I personally don=E2=80=99t see too much value in = discussing this here once again (given the generic nature of the problem = and very unclear definition of =E2=80=9Cfair=E2=80=9D). >>=20 >> 2. Seems like maybe you also need to refer to the RTP/RTCP security >> considerations because it seems like security primarily needs to be = considered >> in the context of a specific transport protocol and its = authentication >> mechanisms. Hm, also not sure here because, while this congestion control scheme is = developed for RTP/RTCP, it's defined in a more generic way and there are = actually no real dependencies on a specific protocol. >>=20 >> Cheers, >>=20 >> spt > I also think that text (or similar) would also be valuable in the = security considerations section. >=20 Gorry: Can you further explain what part this comment related to? Thanks! Mirja > Gorry >=20 From nobody Fri Aug 16 07:54:38 2019 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 58C22120232; Fri, 16 Aug 2019 07:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RO7h8cgrZVOG; Fri, 16 Aug 2019 07:54:21 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B44120086; Fri, 16 Aug 2019 07:54:21 -0700 (PDT) Received: from [130.209.247.112] (port=49713 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1hydcL-0004V4-W7; Fri, 16 Aug 2019 15:54:18 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Colin Perkins In-Reply-To: <8EB353C0-FC34-4514-8283-0D1654EE48DD@kuehlewind.net> Date: Fri, 16 Aug 2019 15:54:07 +0100 Cc: Gorry Fairhurst , Sean Turner , secdir@ietf.org, rmcat@ietf.org, draft-ietf-rmcat-nada.all@ietf.org, IETF Content-Transfer-Encoding: quoted-printable Message-Id: <2EB42977-16EF-46AA-B1E8-EA4C420FA51A@csperkins.org> References: <156565849881.20488.4580765481520503258@ietfa.amsl.com> <5D526D4A.5010304@erg.abdn.ac.uk> <8EB353C0-FC34-4514-8283-0D1654EE48DD@kuehlewind.net> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.3445.104.11) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [secdir] [rmcat] Secdir last call review of draft-ietf-rmcat-nada-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 14:54:25 -0000 Hi, > On 16 Aug 2019, at 13:59, Mirja Kuehlewind = wrote: >=20 > Hi Sean, hi Gorry, >=20 > Thanks for your review and feedback. Please see below. >=20 >> On 13. Aug 2019, at 09:56, Gorry Fairhurst = wrote: >>=20 >> See below: >>=20 >> On 13/08/2019, 02:08, Sean Turner via Datatracker wrote: >>> Reviewer: Sean Turner >>> Review result: Has Nits >>>=20 >>> Hi! I'm no congestion control expert so nothing in the main body = jumped out at >>> me. I did take a little time to review some security considerations = for other >>> congestion control RFCs and just wanted to make sure the same kind = of >>> information is getting addressed. I indicated the result of this = review as >>> "has nits" because there is a pretty good chance I am just = suggesting some >>> editorial tweaks. >>>=20 >>> The security considerations rightly points out that this mechanism = is >>> susceptible to the same kind of attacks as TCP (e.g., hijack, = replacement) and >>> what mitigations to use (i.e., integrity protection of the RTCP = feedback >>> messages). But, what is missing is what happens if these attacks = succeed: DoS >>> or in the worst case congestion collapse? So, maybe instead of: >>>=20 >>> As such, it is vulnerable to attacks where feedback >>> messages are hijacked, replaces, or intentionally injected with >>> misleading information, similar to those that can affect TCP. >>>=20 >>> Maybe: >>>=20 >>> As such, it is vulnerable to attacks where feedback >>> messages are hijacked, replaces, or intentionally injected with >>> misleading information resulting in denial of service, similar >>> to those that can affect TCP. >>>=20 >>> Also, unless I've completely misread this paragraph it seems like = you are >>> talking about two things: 1) it's just like TCP, and 2) "The = modification of >>> sending rate ...". So, maybe split the paragraph along those lines. >=20 > I think this is actually based on text that we used for scream (now = RFC8298) which is another congestion control developed in rmcat. I think = we refined that text also based on a SEC (or GEN?) review comment at = that time and people were at the end satisfied with it. However, your = proposed change above could surely be integrated and I leave it to the = authors if they want to refine the text further.=20 >=20 >>>=20 >>> Further questions: >>>=20 >>> 1. Are there any concerns related to a greedy receiver who wants to = gobble up >>> more than its fair share of network bandwidth? >=20 > This is a very general point for all congestion control schemes, and = for rmcat it is also discussed in draft-ietf-rmcat-cc-requirements = (which is sitting in the RFC editor queue for a while as part of the 238 = cluster=E2=80=A6). I personally don=E2=80=99t see too much value in = discussing this here once again (given the generic nature of the problem = and very unclear definition of =E2=80=9Cfair=E2=80=9D). >=20 >>>=20 >>> 2. Seems like maybe you also need to refer to the RTP/RTCP security >>> considerations because it seems like security primarily needs to be = considered >>> in the context of a specific transport protocol and its = authentication >>> mechanisms. >=20 > Hm, also not sure here because, while this congestion control scheme = is developed for RTP/RTCP, it's defined in a more generic way and there = are actually no real dependencies on a specific protocol. For both this and the GenART review, it should maybe point to = draft-ietf-avtcore-cc-feedback-message-04 as an example mechanism to = carry congestion feedback. The security considerations in that draft = highlight some of these issues, and point to the RTP security mechanisms = needed to secure the feedback. Colin >>>=20 >>> Cheers, >>>=20 >>> spt >> I also think that text (or similar) would also be valuable in the = security considerations section. >>=20 >=20 > Gorry: Can you further explain what part this comment related to? >=20 > Thanks! > Mirja >=20 >=20 >=20 >> Gorry >>=20 >=20 --=20 Colin Perkins https://csperkins.org/ From nobody Fri Aug 16 09:46:33 2019 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 46A831200F4; Fri, 16 Aug 2019 09:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Of+QzBiz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ESbLMYzS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KgSydd2lB_1; Fri, 16 Aug 2019 09:46:21 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9614112080A; Fri, 16 Aug 2019 09:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7912; q=dns/txt; s=iport; t=1565973977; x=1567183577; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=viwF8u8G3IIDe1c97ffQEwoWPqzBLgp8Vq7usiVoJUM=; b=Of+QzBizV1cZS+rcJEjDj5DIjmPdEsb43GaccW9Cvu6jKtN2AXb71CaJ 5cKAIxb/Smu09fo3OfCCu4EJW5wf4lzAtZUAH0VsB8GksUUOzNZJ9GeFI xuDsaOFw2TukXTs2qhrUAmS09xihoZLCHkGJopuWydrC9h7M58AmqMQrx c=; IronPort-PHdr: =?us-ascii?q?9a23=3AOyNS1ha1Gp0wTYuu+hs8UNT/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8Kav6biU9BdZCSXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAAD53FZd/4MNJK1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVgIBAQEBCwGBRFADbVUgBAsqhB+DRwOKdoJbl2OBQoEQA1Q?= =?us-ascii?q?JAQEBDAEBGxICAQGEPwIXgwMjNwYOAgUBAQQBAQECAQYEbYUnDIVKAQEBAQI?= =?us-ascii?q?BEhERDAEBKQ4BDwIBCA4KAgIRFQICAjAVEAIEAQ0FIoMAAYFqAw4PAZ8ZAoE?= =?us-ascii?q?4iGBzgTKCegEBBYUGGIIUAwaBDCgBi2gXgUA/gREnH4JMPoN/XCiCTDKCJo5?= =?us-ascii?q?kMZtYZwkCgh2GZI1PG4IxhzCKRYQcjVeHYZAmAgQCBAUCDgEBBYFmIoFYcBV?= =?us-ascii?q?lAYJBgkIMF4NPhRSFP3KBKY15AQE?= X-IronPort-AV: E=Sophos;i="5.64,393,1559520000"; d="scan'208";a="308640533" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Aug 2019 16:46:16 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x7GGkGUW004848 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Aug 2019 16:46:16 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 16 Aug 2019 11:46:15 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 16 Aug 2019 11:46:15 -0500 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 16 Aug 2019 11:46:14 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DEPdNytYhkVw1h5GrIiMhCTxzrVvU0+DauZtQmIf5A34WUyTgrzTx/6XV/RsmU+oy0gZ87reDwzqo4cdC/0lqNIQeVC95SmOE/iqojB2VV6TDJhBT0co4xzk54y7heeqwnLFFRY/Dt4rOTwIBViLqBgEXh/nM9FvrvjwKiUtAZyQv42/FNdLTXvrDhe+fH7ogeMNXBkUltfZWPfcGBqVggNeW+4OD3kaO8EFU2Q5ycMNlx/BSkE1S/4S7kmr9Spt1tu4yQMnR8HyNnQdjT58QNa5NlaTtIpcZ/zu3Pe4u/9+xTbOkT4TApVOLaR/tStNL+6TN3BGk4m5ufPrpKLG7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=viwF8u8G3IIDe1c97ffQEwoWPqzBLgp8Vq7usiVoJUM=; b=TT+JXG9J0VLXER/RGNqry67hMkzYyH1g2Ez2Ytuij+AdgFh/t+cg1K751KM4Nzej2nbcxesJzXZLQP2ZNOQl5IqkuM2LIRGKCehCiHS9HQuEaf9sujPNH7mnABZ9kfb1UyEOw7mXXQhGtUkJklGH8oXZsEDAKH+nnNcR3n0GOaSF0/770PCT7ifU4GiOxulw4KQbhGmJt+2gwyHyUKeBRifZW0wi87ir+uDKgGNHC8u/jkQWncKU9T24e/NnwTMtAwM5P1ZMzmjL6ztjfQZNa4FUpXJBBWGP/ZODmWbjDnXPT8GGXyeZ8e+10XFAg3199RTOIWq0DCyKyJqSy+u7sw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=viwF8u8G3IIDe1c97ffQEwoWPqzBLgp8Vq7usiVoJUM=; b=ESbLMYzSTOAgY4jWPmqgT26ySxgMTMItJ8UD0JHSXPP48c7n9z6wCfRQiJnXuSvn2SMXPO6/ybh+1WQBN5Byoc8teJzmfHSlKywSZgN90CF6iAS1BrCOU1L6q40J7vPVIsucsgSayvub3zjCf2FrJaz8XGTpT3Hf2vGF0dtnK74= Received: from CY4PR11MB1559.namprd11.prod.outlook.com (10.172.72.140) by CY4PR11MB1400.namprd11.prod.outlook.com (10.169.254.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.16; Fri, 16 Aug 2019 16:46:13 +0000 Received: from CY4PR11MB1559.namprd11.prod.outlook.com ([fe80::53:33f3:ea63:7f72]) by CY4PR11MB1559.namprd11.prod.outlook.com ([fe80::53:33f3:ea63:7f72%3]) with mapi id 15.20.2157.022; Fri, 16 Aug 2019 16:46:13 +0000 From: "Xiaoqing Zhu (xiaoqzhu)" To: Colin Perkins , Mirja Kuehlewind CC: Gorry Fairhurst , Sean Turner , "secdir@ietf.org" , "rmcat@ietf.org" , "draft-ietf-rmcat-nada.all@ietf.org" , IETF Thread-Topic: [rmcat] Secdir last call review of draft-ietf-rmcat-nada-11 Thread-Index: AQHVUXOlEGdHcdwXkkGy8eFbeJEvyKb4tnUAgAULjoCAAB/9gP//y4AA Date: Fri, 16 Aug 2019 16:46:13 +0000 Message-ID: <865425B9-FF34-45F6-89C4-2C2D79741382@cisco.com> References: <156565849881.20488.4580765481520503258@ietfa.amsl.com> <5D526D4A.5010304@erg.abdn.ac.uk> <8EB353C0-FC34-4514-8283-0D1654EE48DD@kuehlewind.net> <2EB42977-16EF-46AA-B1E8-EA4C420FA51A@csperkins.org> In-Reply-To: <2EB42977-16EF-46AA-B1E8-EA4C420FA51A@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1c.0.190812 authentication-results: spf=none (sender IP is ) smtp.mailfrom=xiaoqzhu@cisco.com; x-originating-ip: [2001:420:1402:1250:5f1:23c7:f2d9:d83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7cee6ce4-c5c5-4e78-7499-08d72269401f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR11MB1400; x-ms-traffictypediagnostic: CY4PR11MB1400: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0131D22242 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(376002)(39860400002)(366004)(346002)(199004)(189003)(316002)(102836004)(53936002)(186003)(58126008)(478600001)(5660300002)(71200400001)(305945005)(66446008)(7736002)(71190400001)(66556008)(229853002)(486006)(33656002)(76116006)(91956017)(54906003)(66476007)(6512007)(6436002)(6306002)(6506007)(86362001)(64756008)(966005)(36756003)(6486002)(53546011)(476003)(81166006)(2616005)(4326008)(446003)(14454004)(6116002)(2906002)(8936002)(76176011)(66946007)(6246003)(46003)(110136005)(25786009)(11346002)(81156014)(8676002)(99286004)(256004)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB1400; H:CY4PR11MB1559.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 9G5eEOg1tyeJyJ3p62NE9je+1hREdICBozm40PmvNw7OZNuH5R4bYrCHWDHJVf4U6UL6mFFqyYqUd5VYTQbFdMkeFWmABqmjDYQsBS+DrZuuNeH8NA+TmXcUX4qA++ZEgdTV3lUW4pfaysRqsDw/VvdFCZaJagAUcSmyx2vJk3vLv0AlpCkFVXaFNGVizbO+Kpo+x1wo7YfTsPkrsGPvS8kWPSZXWz5GHjHHpqaPPEb9NMVx7q6ANEjY7zbHMKdij7XuFIG8smdUNEBCHd3VupJ/KBrlB6HRvZ5963FqdLSbK9CnRxKHtTDMhbE360xEr4grGGrJAlivjbzdspID5oBr1mJe7nSe6EhxBIDjRPKoJ/t7YFz9cw8SKoHWaAlw8X8GXpF/xd+EqIDNUFbHTe6QOV5GGDyMRJ4sbw3b6lY= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7cee6ce4-c5c5-4e78-7499-08d72269401f X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2019 16:46:13.7858 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XibhuGt/kXeZJJsrRqksaxxNalG/8ozmHHzBXG1bEgCZNCIdKgUQSsaOjsCx6oemGuvu5Ik0ve1YwbtRLO9ztw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1400 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [secdir] [rmcat] Secdir last call review of draft-ietf-rmcat-nada-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 16:46:25 -0000 SGksIA0KDQpUaGFua3MgdG8gU2VhbiBhbmQgR29ycnkgZm9yIHlvdXIgcmV2aWV3IGNvbW1lbnRz LiAgQW5kIHRoYW5rcyB0byBNaXJqYSBhbmQgQ29saW4gZm9yIGNoaW1pbmcgaW4gd2l0aCB5b3Vy IGlucHV0cyBhbmQgc3VnZ2VzdGlvbnMuIA0KDQpCZWxvdyBhcmUgbXkgcGxhbm5lZCBhY3Rpb25z IGZvciByZXZpc2luZyB0aGUgZHJhZnQsIHNvIHRoYXQgdGhleSBjYW4gYWRkcmVzcyB0aGUgb3Jp Z2luYWwgc2V0IG9mIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMgZnJvbSBTZWFuICh3aGlsZSB0YWtp bmcgaW50byBhY2NvdW50IGlucHV0cyBmcm9tIEdvcnJ5L01pcmphL0NvbGluKQ0KDQoqIFN1Z2dl c3Rpb25zIGZvciByZXZpc2VkIHRleHQgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zOiAg d2lsbCBiZSBoYXBweSB0byByZXZpc2UgYWNjb3JkaW5nbHkuIFdpbGwgYWxzbyBzcGxpdCB1cCB0 aGUgdGV4dCBpbnRvIHR3byBwYXJhZ3JhcGhzIGNvcnJlc3BvbmRpbmcgdG8gdGhlIHR3byBwb2lu dHMuIA0KKiBRdWVzdGlvbiAxIG9uIGNvbmNlcm5zIHJlbGF0ZWQgdG8gZ3JlZWR5IHJlY2VpdmVy czogIGFzIGEgZ2VuZXJhbCBmYWlybmVzcyBjb25jZXJuIChmb3IgbW9zdCBjb25nZXN0aW9uIGNv bnRyb2wgc2NoZW1lcykgdGhpcyBpcyBkaXNjdXNzZWQgaW4gZ3JlYXRlciBkZXRhaWwgaW4gdGhl IGNjLXJlcXVpcmVtZW50cyBkcmFmdC4gIFRoZSBkcmFmdCBjdXJyZW50IG9ubHkgY2l0ZXMgdGhl IGNjLXJlcXVpcmVtZW50cyBkcmFmdCBpbiB0aGUgaW50cm8uIFdlIGNhbiBhZGQgc29tZSBtb3Jl IHRleHQgdG8gaGlnaGxpZ2h0IHNldmVyYWwgc2FsaWVudCByZXF1aXJlbWVudHMgKGUuZy4sIHN0 YWJpbGl0eSwgZmFpcm5lc3MpIGFzIGV4YW1wbGUuIA0KKiBRdWVzdGlvbiAyIG9uIFJUUC9SVENQ IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zOiAgcGVyIENvbGluJ3Mgc3VnZ2VzdGlvbiwgd2lsbCBh ZGQgYSByZWZlcmVuY2UgYW5kIHBvaW50IHRvIHRoZSBjYy1mZWVkYmFjay1tZXNzYWdlIGRyYWZ0 IGZvciBmdXJ0aGVyIGRpc2N1c3Npb25zIG9uIHNlY3VyaXR5IG1lY2hhbmlzbXMuIA0KDQpHb3Jy eSAtLSBJIHVuZGVyc3Rvb2QgeW91ciBjb21tZW50cyBhcyByZWZlcnJpbmcgdG8gdGhlIHRleHQg c3VnZ2VzdGlvbnMgYnkgU2Vhbi4gIFBsZWFzZSBsZXQgdXMga25vdyBpZiB0aGF0J3Mgbm90IHRo ZSBjYXNlIG9yIGlmIHRoZSBhYm92ZSBwbGFubmVkIGNoYW5nZXMgbWlzcyBvdXQgYW55IHBvaW50 cyB5b3UnZCBsaWtlIHRvIGhpZ2hsaWdodC4NCg0KQmVzdCwNClhpYW9xaW5nIA0KDQrvu79PbiA4 LzE2LzE5LCA5OjU0IEFNLCAiQ29saW4gUGVya2lucyIgPGNzcEBjc3BlcmtpbnMub3JnPiB3cm90 ZToNCg0KICAgIEhpLA0KICAgIA0KICAgID4gT24gMTYgQXVnIDIwMTksIGF0IDEzOjU5LCBNaXJq YSBLdWVobGV3aW5kIDxpZXRmQGt1ZWhsZXdpbmQubmV0PiB3cm90ZToNCiAgICA+IA0KICAgID4g SGkgU2VhbiwgaGkgR29ycnksDQogICAgPiANCiAgICA+IFRoYW5rcyBmb3IgeW91ciByZXZpZXcg YW5kIGZlZWRiYWNrLiBQbGVhc2Ugc2VlIGJlbG93Lg0KICAgID4gDQogICAgPj4gT24gMTMuIEF1 ZyAyMDE5LCBhdCAwOTo1NiwgR29ycnkgRmFpcmh1cnN0IDxnb3JyeUBlcmcuYWJkbi5hYy51az4g d3JvdGU6DQogICAgPj4gDQogICAgPj4gU2VlICBiZWxvdzoNCiAgICA+PiANCiAgICA+PiBPbiAx My8wOC8yMDE5LCAwMjowOCwgU2VhbiBUdXJuZXIgdmlhIERhdGF0cmFja2VyIHdyb3RlOg0KICAg ID4+PiBSZXZpZXdlcjogU2VhbiBUdXJuZXINCiAgICA+Pj4gUmV2aWV3IHJlc3VsdDogSGFzIE5p dHMNCiAgICA+Pj4gDQogICAgPj4+IEhpISBJJ20gbm8gY29uZ2VzdGlvbiBjb250cm9sIGV4cGVy dCBzbyBub3RoaW5nIGluIHRoZSBtYWluIGJvZHkganVtcGVkIG91dCBhdA0KICAgID4+PiBtZS4g IEkgZGlkIHRha2UgYSBsaXR0bGUgdGltZSB0byByZXZpZXcgc29tZSBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyBmb3Igb3RoZXINCiAgICA+Pj4gY29uZ2VzdGlvbiBjb250cm9sIFJGQ3MgYW5kIGp1 c3Qgd2FudGVkIHRvIG1ha2Ugc3VyZSB0aGUgc2FtZSBraW5kIG9mDQogICAgPj4+IGluZm9ybWF0 aW9uIGlzIGdldHRpbmcgYWRkcmVzc2VkLiAgSSBpbmRpY2F0ZWQgdGhlIHJlc3VsdCBvZiB0aGlz IHJldmlldyBhcw0KICAgID4+PiAiaGFzIG5pdHMiIGJlY2F1c2UgdGhlcmUgaXMgYSBwcmV0dHkg Z29vZCBjaGFuY2UgSSBhbSBqdXN0IHN1Z2dlc3Rpbmcgc29tZQ0KICAgID4+PiBlZGl0b3JpYWwg dHdlYWtzLg0KICAgID4+PiANCiAgICA+Pj4gVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHJp Z2h0bHkgcG9pbnRzIG91dCB0aGF0IHRoaXMgbWVjaGFuaXNtIGlzDQogICAgPj4+IHN1c2NlcHRp YmxlIHRvIHRoZSBzYW1lIGtpbmQgb2YgYXR0YWNrcyBhcyBUQ1AgKGUuZy4sIGhpamFjaywgcmVw bGFjZW1lbnQpIGFuZA0KICAgID4+PiB3aGF0IG1pdGlnYXRpb25zIHRvIHVzZSAoaS5lLiwgaW50 ZWdyaXR5IHByb3RlY3Rpb24gb2YgdGhlIFJUQ1AgZmVlZGJhY2sNCiAgICA+Pj4gbWVzc2FnZXMp LiAgQnV0LCB3aGF0IGlzIG1pc3NpbmcgaXMgd2hhdCBoYXBwZW5zIGlmIHRoZXNlIGF0dGFja3Mg c3VjY2VlZDogRG9TDQogICAgPj4+IG9yIGluIHRoZSB3b3JzdCBjYXNlIGNvbmdlc3Rpb24gY29s bGFwc2U/ICBTbywgbWF5YmUgaW5zdGVhZCBvZjoNCiAgICA+Pj4gDQogICAgPj4+ICAgQXMgc3Vj aCwgaXQgaXMgdnVsbmVyYWJsZSB0byBhdHRhY2tzIHdoZXJlIGZlZWRiYWNrDQogICAgPj4+ICAg bWVzc2FnZXMgYXJlIGhpamFja2VkLCByZXBsYWNlcywgb3IgaW50ZW50aW9uYWxseSBpbmplY3Rl ZCB3aXRoDQogICAgPj4+ICAgbWlzbGVhZGluZyBpbmZvcm1hdGlvbiwgc2ltaWxhciB0byB0aG9z ZSB0aGF0IGNhbiBhZmZlY3QgVENQLg0KICAgID4+PiANCiAgICA+Pj4gTWF5YmU6DQogICAgPj4+ IA0KICAgID4+PiAgIEFzIHN1Y2gsIGl0IGlzIHZ1bG5lcmFibGUgdG8gYXR0YWNrcyB3aGVyZSBm ZWVkYmFjaw0KICAgID4+PiAgIG1lc3NhZ2VzIGFyZSBoaWphY2tlZCwgcmVwbGFjZXMsIG9yIGlu dGVudGlvbmFsbHkgaW5qZWN0ZWQgd2l0aA0KICAgID4+PiAgIG1pc2xlYWRpbmcgaW5mb3JtYXRp b24gcmVzdWx0aW5nIGluIGRlbmlhbCBvZiBzZXJ2aWNlLCBzaW1pbGFyDQogICAgPj4+ICAgdG8g dGhvc2UgdGhhdCBjYW4gYWZmZWN0IFRDUC4NCiAgICA+Pj4gDQogICAgPj4+IEFsc28sIHVubGVz cyBJJ3ZlIGNvbXBsZXRlbHkgbWlzcmVhZCB0aGlzIHBhcmFncmFwaCBpdCBzZWVtcyBsaWtlIHlv dSBhcmUNCiAgICA+Pj4gdGFsa2luZyBhYm91dCB0d28gdGhpbmdzOiAxKSBpdCdzIGp1c3QgbGlr ZSBUQ1AsIGFuZCAyKSAiVGhlIG1vZGlmaWNhdGlvbiBvZg0KICAgID4+PiBzZW5kaW5nIHJhdGUg Li4uIi4gIFNvLCBtYXliZSBzcGxpdCB0aGUgcGFyYWdyYXBoIGFsb25nIHRob3NlIGxpbmVzLg0K ICAgID4gDQogICAgPiBJIHRoaW5rIHRoaXMgaXMgYWN0dWFsbHkgYmFzZWQgb24gdGV4dCB0aGF0 IHdlIHVzZWQgZm9yIHNjcmVhbSAobm93IFJGQzgyOTgpIHdoaWNoIGlzIGFub3RoZXIgY29uZ2Vz dGlvbiBjb250cm9sIGRldmVsb3BlZCBpbiBybWNhdC4gSSB0aGluayB3ZSByZWZpbmVkIHRoYXQg dGV4dCBhbHNvIGJhc2VkIG9uIGEgU0VDIChvciBHRU4/KSByZXZpZXcgY29tbWVudCBhdCB0aGF0 IHRpbWUgYW5kIHBlb3BsZSB3ZXJlIGF0IHRoZSBlbmQgc2F0aXNmaWVkIHdpdGggaXQuIEhvd2V2 ZXIsIHlvdXIgcHJvcG9zZWQgY2hhbmdlIGFib3ZlIGNvdWxkIHN1cmVseSBiZSBpbnRlZ3JhdGVk IGFuZCBJIGxlYXZlIGl0IHRvIHRoZSBhdXRob3JzIGlmIHRoZXkgd2FudCB0byByZWZpbmUgdGhl IHRleHQgZnVydGhlci4gDQogICAgPiANCiAgICA+Pj4gDQogICAgPj4+IEZ1cnRoZXIgcXVlc3Rp b25zOg0KICAgID4+PiANCiAgICA+Pj4gMS4gQXJlIHRoZXJlIGFueSBjb25jZXJucyByZWxhdGVk IHRvIGEgZ3JlZWR5IHJlY2VpdmVyIHdobyB3YW50cyB0byBnb2JibGUgdXANCiAgICA+Pj4gbW9y ZSB0aGFuIGl0cyBmYWlyIHNoYXJlIG9mIG5ldHdvcmsgYmFuZHdpZHRoPw0KICAgID4gDQogICAg PiBUaGlzIGlzIGEgdmVyeSBnZW5lcmFsIHBvaW50IGZvciBhbGwgY29uZ2VzdGlvbiBjb250cm9s IHNjaGVtZXMsIGFuZCBmb3Igcm1jYXQgaXQgaXMgYWxzbyBkaXNjdXNzZWQgaW4gZHJhZnQtaWV0 Zi1ybWNhdC1jYy1yZXF1aXJlbWVudHMgKHdoaWNoIGlzIHNpdHRpbmcgaW4gdGhlIFJGQyBlZGl0 b3IgcXVldWUgZm9yIGEgd2hpbGUgYXMgcGFydCBvZiB0aGUgMjM4IGNsdXN0ZXLigKYpLiBJIHBl cnNvbmFsbHkgZG9u4oCZdCBzZWUgdG9vIG11Y2ggdmFsdWUgaW4gZGlzY3Vzc2luZyB0aGlzIGhl cmUgb25jZSBhZ2FpbiAoZ2l2ZW4gdGhlIGdlbmVyaWMgbmF0dXJlIG9mIHRoZSBwcm9ibGVtIGFu ZCB2ZXJ5IHVuY2xlYXIgZGVmaW5pdGlvbiBvZiDigJxmYWly4oCdKS4NCiAgICA+IA0KICAgID4+ PiANCiAgICA+Pj4gMi4gU2VlbXMgbGlrZSBtYXliZSB5b3UgYWxzbyBuZWVkIHRvIHJlZmVyIHRv IHRoZSBSVFAvUlRDUCBzZWN1cml0eQ0KICAgID4+PiBjb25zaWRlcmF0aW9ucyBiZWNhdXNlIGl0 IHNlZW1zIGxpa2Ugc2VjdXJpdHkgcHJpbWFyaWx5IG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQNCiAg ICA+Pj4gaW4gdGhlIGNvbnRleHQgb2YgYSBzcGVjaWZpYyB0cmFuc3BvcnQgcHJvdG9jb2wgYW5k IGl0cyBhdXRoZW50aWNhdGlvbg0KICAgID4+PiBtZWNoYW5pc21zLg0KICAgID4gDQogICAgPiBI bSwgYWxzbyBub3Qgc3VyZSBoZXJlIGJlY2F1c2UsIHdoaWxlIHRoaXMgY29uZ2VzdGlvbiBjb250 cm9sIHNjaGVtZSBpcyBkZXZlbG9wZWQgZm9yIFJUUC9SVENQLCBpdCdzIGRlZmluZWQgaW4gYSBt b3JlIGdlbmVyaWMgd2F5IGFuZCB0aGVyZSBhcmUgYWN0dWFsbHkgbm8gcmVhbCBkZXBlbmRlbmNp ZXMgb24gYSBzcGVjaWZpYyBwcm90b2NvbC4NCiAgICANCiAgICBGb3IgYm90aCB0aGlzIGFuZCB0 aGUgR2VuQVJUIHJldmlldywgaXQgc2hvdWxkIG1heWJlIHBvaW50IHRvIGRyYWZ0LWlldGYtYXZ0 Y29yZS1jYy1mZWVkYmFjay1tZXNzYWdlLTA0IGFzIGFuIGV4YW1wbGUgbWVjaGFuaXNtIHRvIGNh cnJ5IGNvbmdlc3Rpb24gZmVlZGJhY2suIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiB0 aGF0IGRyYWZ0IGhpZ2hsaWdodCBzb21lIG9mIHRoZXNlIGlzc3VlcywgYW5kIHBvaW50IHRvIHRo ZSBSVFAgc2VjdXJpdHkgbWVjaGFuaXNtcyBuZWVkZWQgdG8gc2VjdXJlIHRoZSBmZWVkYmFjay4N CiAgICANCiAgICBDb2xpbg0KICAgIA0KICAgIA0KICAgIA0KICAgID4+PiANCiAgICA+Pj4gQ2hl ZXJzLA0KICAgID4+PiANCiAgICA+Pj4gc3B0DQogICAgPj4gSSBhbHNvIHRoaW5rIHRoYXQgdGV4 dCAob3Igc2ltaWxhcikgd291bGQgYWxzbyBiZSB2YWx1YWJsZSBpbiB0aGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgc2VjdGlvbi4NCiAgICA+PiANCiAgICA+IA0KICAgID4gR29ycnk6IENhbiB5 b3UgZnVydGhlciBleHBsYWluIHdoYXQgcGFydCB0aGlzIGNvbW1lbnQgcmVsYXRlZCB0bz8NCiAg ICA+IA0KICAgID4gVGhhbmtzIQ0KICAgID4gTWlyamENCiAgICA+IA0KICAgID4gDQogICAgPiAN CiAgICA+PiBHb3JyeQ0KICAgID4+IA0KICAgID4gDQogICAgDQogICAgDQogICAgDQogICAgLS0g DQogICAgQ29saW4gUGVya2lucw0KICAgIGh0dHBzOi8vY3NwZXJraW5zLm9yZy8NCiAgICANCiAg ICANCiAgICANCiAgICANCiAgICANCg0K From nobody Sat Aug 17 01:29:50 2019 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 D97D6120108; Sat, 17 Aug 2019 01:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgZQJBdENK5n; Sat, 17 Aug 2019 01:29:31 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 36092120105; Sat, 17 Aug 2019 01:29:30 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id CEB551B0028A; Sat, 17 Aug 2019 09:29:18 +0100 (BST) Message-ID: <5D57BADD.8080508@erg.abdn.ac.uk> Date: Sat, 17 Aug 2019 09:29:17 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Xiaoqing Zhu (xiaoqzhu)" CC: Colin Perkins , Mirja Kuehlewind , Sean Turner , "secdir@ietf.org" , "rmcat@ietf.org" , "draft-ietf-rmcat-nada.all@ietf.org" , IETF References: <156565849881.20488.4580765481520503258@ietfa.amsl.com> <5D526D4A.5010304@erg.abdn.ac.uk> <8EB353C0-FC34-4514-8283-0D1654EE48DD@kuehlewind.net> <2EB42977-16EF-46AA-B1E8-EA4C420FA51A@csperkins.org> <865425B9-FF34-45F6-89C4-2C2D79741382@cisco.com> In-Reply-To: <865425B9-FF34-45F6-89C4-2C2D79741382@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] [rmcat] Secdir last call review of draft-ietf-rmcat-nada-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2019 08:29:34 -0000 Yes. I'm happy with this approach in response to my feedback. Specifically, providing extra text in the security requirements to highlight each of these (generic) CC topics - if needed, with pointers to other documents where these are discussed more. Gorry On 16/08/2019, 17:46, Xiaoqing Zhu (xiaoqzhu) wrote: > Hi, > > Thanks to Sean and Gorry for your review comments. And thanks to Mirja and Colin for chiming in with your inputs and suggestions. > > Below are my planned actions for revising the draft, so that they can address the original set of comments and questions from Sean (while taking into account inputs from Gorry/Mirja/Colin) > > * Suggestions for revised text in the Security Considerations: will be happy to revise accordingly. Will also split up the text into two paragraphs corresponding to the two points. > * Question 1 on concerns related to greedy receivers: as a general fairness concern (for most congestion control schemes) this is discussed in greater detail in the cc-requirements draft. The draft current only cites the cc-requirements draft in the intro. We can add some more text to highlight several salient requirements (e.g., stability, fairness) as example. > * Question 2 on RTP/RTCP security considerations: per Colin's suggestion, will add a reference and point to the cc-feedback-message draft for further discussions on security mechanisms. > > Gorry -- I understood your comments as referring to the text suggestions by Sean. Please let us know if that's not the case or if the above planned changes miss out any points you'd like to highlight. > > Best, > Xiaoqing > > On 8/16/19, 9:54 AM, "Colin Perkins" wrote: > > Hi, > > > On 16 Aug 2019, at 13:59, Mirja Kuehlewind wrote: > > > > Hi Sean, hi Gorry, > > > > Thanks for your review and feedback. Please see below. > > > >> On 13. Aug 2019, at 09:56, Gorry Fairhurst wrote: > >> > >> See below: > >> > >> On 13/08/2019, 02:08, Sean Turner via Datatracker wrote: > >>> Reviewer: Sean Turner > >>> Review result: Has Nits > >>> > >>> Hi! I'm no congestion control expert so nothing in the main body jumped out at > >>> me. I did take a little time to review some security considerations for other > >>> congestion control RFCs and just wanted to make sure the same kind of > >>> information is getting addressed. I indicated the result of this review as > >>> "has nits" because there is a pretty good chance I am just suggesting some > >>> editorial tweaks. > >>> > >>> The security considerations rightly points out that this mechanism is > >>> susceptible to the same kind of attacks as TCP (e.g., hijack, replacement) and > >>> what mitigations to use (i.e., integrity protection of the RTCP feedback > >>> messages). But, what is missing is what happens if these attacks succeed: DoS > >>> or in the worst case congestion collapse? So, maybe instead of: > >>> > >>> As such, it is vulnerable to attacks where feedback > >>> messages are hijacked, replaces, or intentionally injected with > >>> misleading information, similar to those that can affect TCP. > >>> > >>> Maybe: > >>> > >>> As such, it is vulnerable to attacks where feedback > >>> messages are hijacked, replaces, or intentionally injected with > >>> misleading information resulting in denial of service, similar > >>> to those that can affect TCP. > >>> > >>> Also, unless I've completely misread this paragraph it seems like you are > >>> talking about two things: 1) it's just like TCP, and 2) "The modification of > >>> sending rate ...". So, maybe split the paragraph along those lines. > > > > I think this is actually based on text that we used for scream (now RFC8298) which is another congestion control developed in rmcat. I think we refined that text also based on a SEC (or GEN?) review comment at that time and people were at the end satisfied with it. However, your proposed change above could surely be integrated and I leave it to the authors if they want to refine the text further. > > > >>> > >>> Further questions: > >>> > >>> 1. Are there any concerns related to a greedy receiver who wants to gobble up > >>> more than its fair share of network bandwidth? > > > > This is a very general point for all congestion control schemes, and for rmcat it is also discussed in draft-ietf-rmcat-cc-requirements (which is sitting in the RFC editor queue for a while as part of the 238 cluster…). I personally don’t see too much value in discussing this here once again (given the generic nature of the problem and very unclear definition of “fair”). > > > >>> > >>> 2. Seems like maybe you also need to refer to the RTP/RTCP security > >>> considerations because it seems like security primarily needs to be considered > >>> in the context of a specific transport protocol and its authentication > >>> mechanisms. > > > > Hm, also not sure here because, while this congestion control scheme is developed for RTP/RTCP, it's defined in a more generic way and there are actually no real dependencies on a specific protocol. > > For both this and the GenART review, it should maybe point to draft-ietf-avtcore-cc-feedback-message-04 as an example mechanism to carry congestion feedback. The security considerations in that draft highlight some of these issues, and point to the RTP security mechanisms needed to secure the feedback. > > Colin > > > > >>> > >>> Cheers, > >>> > >>> spt > >> I also think that text (or similar) would also be valuable in the security considerations section. > >> > > > > Gorry: Can you further explain what part this comment related to? > > > > Thanks! > > Mirja > > > > > > > >> Gorry > >> > > > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > > From nobody Sat Aug 17 04:30:25 2019 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 A5C961200D5; Sat, 17 Aug 2019 04:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rolzsOjFgAIn; Sat, 17 Aug 2019 04:30:09 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id A3B2C120020; Sat, 17 Aug 2019 04:30:08 -0700 (PDT) Received: from [192.168.0.7] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 237161B00083; Sat, 17 Aug 2019 12:29:56 +0100 (BST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Gorry Fairhurst Mime-Version: 1.0 (1.0) Date: Sat, 17 Aug 2019 12:29:08 +0100 Message-Id: References: <156565849881.20488.4580765481520503258@ietfa.amsl.com> <5D526D4A.5010304@erg.abdn.ac.uk> <8EB353C0-FC34-4514-8283-0D1654EE48DD@kuehlewind.net> <2EB42977-16EF-46AA-B1E8-EA4C420FA51A@csperkins.org> <865425B9-FF34-45F6-89C4-2C2D79741382@cisco.com> <5D57BADD.8080508@erg.abdn.ac.uk> In-Reply-To: <5D57BADD.8080508@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk, "Xiaoqing Zhu (xiaoqzhu)" Cc: "draft-ietf-rmcat-nada.all@ietf.org" , IETF , "secdir@ietf.org" , "rmcat@ietf.org" , Mirja Kuehlewind , Colin Perkins , Sean Turner X-Mailer: iPad Mail (16F156) Archived-At: Subject: Re: [secdir] [rmcat] Secdir last call review of draft-ietf-rmcat-nada-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2019 11:30:12 -0000 To be clear, see notes below. Sent from my iPad > On 17 Aug 2019, at 09:29, Gorry Fairhurst wrote: >=20 >=20 > Yes. I'm happy with this approach in response to my feedback. Specifically= , providing extra text in the security requirements to highlight each of the= se (generic) CC topics - if needed, with pointers to other documents where t= hese are discussed more. >=20 > Gorry >=20 >> On 16/08/2019, 17:46, Xiaoqing Zhu (xiaoqzhu) wrote: >> Hi, >>=20 >> Thanks to Sean and Gorry for your review comments. And thanks to Mirja a= nd Colin for chiming in with your inputs and suggestions. >>=20 >> Below are my planned actions for revising the draft, so that they can add= ress the original set of comments and questions from Sean (while taking into= account inputs from Gorry/Mirja/Colin) >>=20 >> * Suggestions for revised text in the Security Considerations: will be h= appy to revise accordingly. Will also split up the text into two paragraphs c= orresponding to the two points. I liked the idea of noting the CC implications in the Security Consideration= s, we have done so before, and a brief additional text with refs to another= RFC should suffice. >> * Question 1 on concerns related to greedy receivers: as a general fairn= ess concern (for most congestion control schemes) this is discussed in great= er detail in the cc-requirements draft. The draft current only cites the cc= -requirements draft in the intro. We can add some more text to highlight sev= eral salient requirements (e.g., stability, fairness) as example. Proving a brief summary and citing in the sec considerations seems good to m= e. >> * Question 2 on RTP/RTCP security considerations: per Colin's suggestion= , will add a reference and point to the cc-feedback-message draft for furthe= r discussions on security mechanisms. >>=20 >> Gorry -- I understood your comments as referring to the text suggestions b= y Sean. Please let us know if that's not the case or if the above planned c= hanges miss out any points you'd like to highlight. Yes and some mention of possible attack on receiver-supplied info, although a= gain my preference would be identify issue and provide a ref to another RFC= , rather than detailed discussion. This is not a new issue. >> Best, >> Xiaoqing >>=20 >> =EF=BB=BFOn 8/16/19, 9:54 AM, "Colin Perkins" wrote: >>=20 >> Hi, >>=20 >>> On 16 Aug 2019, at 13:59, Mirja Kuehlewind wrote: >>>=20 >>> Hi Sean, hi Gorry, >>>=20 >>> Thanks for your review and feedback. Please see below. >>>=20 >>>> On 13. Aug 2019, at 09:56, Gorry Fairhurst wrote= : >>>>=20 >>>> See below: >>>>=20 >>>>> On 13/08/2019, 02:08, Sean Turner via Datatracker wrote: >>>>> Reviewer: Sean Turner >>>>> Review result: Has Nits >>>>>=20 >>>>> Hi! I'm no congestion control expert so nothing in the main body jumpe= d out at >>>>> me. I did take a little time to review some security considerations f= or other >>>>> congestion control RFCs and just wanted to make sure the same kind of >>>>> information is getting addressed. I indicated the result of this revi= ew as >>>>> "has nits" because there is a pretty good chance I am just suggesting s= ome >>>>> editorial tweaks. >>>>>=20 >>>>> The security considerations rightly points out that this mechanism is >>>>> susceptible to the same kind of attacks as TCP (e.g., hijack, replacem= ent) and >>>>> what mitigations to use (i.e., integrity protection of the RTCP feedba= ck >>>>> messages). But, what is missing is what happens if these attacks succ= eed: DoS >>>>> or in the worst case congestion collapse? So, maybe instead of: >>>>>=20 >>>>> As such, it is vulnerable to attacks where feedback >>>>> messages are hijacked, replaces, or intentionally injected with >>>>> misleading information, similar to those that can affect TCP. >>>>>=20 >>>>> Maybe: >>>>>=20 >>>>> As such, it is vulnerable to attacks where feedback >>>>> messages are hijacked, replaces, or intentionally injected with >>>>> misleading information resulting in denial of service, similar >>>>> to those that can affect TCP. >>>>>=20 >>>>> Also, unless I've completely misread this paragraph it seems like you a= re >>>>> talking about two things: 1) it's just like TCP, and 2) "The modificat= ion of >>>>> sending rate ...". So, maybe split the paragraph along those lines. >>>=20 >>> I think this is actually based on text that we used for scream (now RFC8= 298) which is another congestion control developed in rmcat. I think we refi= ned that text also based on a SEC (or GEN?) review comment at that time and p= eople were at the end satisfied with it. However, your proposed change above= could surely be integrated and I leave it to the authors if they want to re= fine the text further. >>>=20 >>>>>=20 >>>>> Further questions: >>>>>=20 >>>>> 1. Are there any concerns related to a greedy receiver who wants to go= bble up >>>>> more than its fair share of network bandwidth? >>>=20 >>> This is a very general point for all congestion control schemes, and for= rmcat it is also discussed in draft-ietf-rmcat-cc-requirements (which is si= tting in the RFC editor queue for a while as part of the 238 cluster=E2=80=A6= ). I personally don=E2=80=99t see too much value in discussing this here onc= e again (given the generic nature of the problem and very unclear definition= of =E2=80=9Cfair=E2=80=9D). >>>=20 >>>>>=20 >>>>> 2. Seems like maybe you also need to refer to the RTP/RTCP security >>>>> considerations because it seems like security primarily needs to be co= nsidered >>>>> in the context of a specific transport protocol and its authentication= >>>>> mechanisms. >>>=20 >>> Hm, also not sure here because, while this congestion control scheme is d= eveloped for RTP/RTCP, it's defined in a more generic way and there are actu= ally no real dependencies on a specific protocol. >>=20 >> For both this and the GenART review, it should maybe point to draft-ie= tf-avtcore-cc-feedback-message-04 as an example mechanism to carry congestio= n feedback. The security considerations in that draft highlight some of thes= e issues, and point to the RTP security mechanisms needed to secure the feed= back. >>=20 >> Colin >>=20 >>=20 >>=20 >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> spt >>>> I also think that text (or similar) would also be valuable in the secur= ity considerations section. >>>=20 >>> Gorry: Can you further explain what part this comment related to? >>>=20 >>> Thanks! >>> Mirja >>>=20 >>>=20 >>>=20 >>>> Gorry >>=20 >>=20 >>=20 >> -- Colin Perkins >> https://csperkins.org/ >>=20 >>=20 >>=20 From nobody Sun Aug 18 17:33:02 2019 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 5F84F12012D; Sun, 18 Aug 2019 17:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kmHS2R8wOHO; Sun, 18 Aug 2019 17:32:41 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA724120052; Sun, 18 Aug 2019 17:32:41 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id n9so109677pgc.1; Sun, 18 Aug 2019 17:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pAv0nHfvRc4YWW4/vSj2VoUfB1CYtGduyFqjjl+OQJY=; b=rwzuk8zyjLuosWDnD3621Lit7bg3/133cK60TFSjA2Qe0uvf/NopC9n9BaUQnvBQ26 o00VRUePwLoQzj5WSB+oE89uUnUxDPnu6Wd8lOoRUwFtQ3khBiq4LKdcRe1BFyxhVAcr vCTJgh6dqF3Gj8wj3z1isqWXUeKBqNYaGTEHZond8aNfRFgWGu5Pd+yl0+LQe5V4sSAg /RY9aP3S582qoNvFizP62FOZByfhQmbuZ6Qsto21v6BWKjAuSyfUNqNHqJoAcOhhvPK9 R0j9fiGxP9GCvR5CJTgalgpti8mfRH8SvgZKuTca4hEBuBAwaTLxVrOt/uFCIySDBYGS +PEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pAv0nHfvRc4YWW4/vSj2VoUfB1CYtGduyFqjjl+OQJY=; b=Cc+N1ecBPyG1z/QuXEb6TnrbhStSPUagem6jH107FibBE4vdMezscJwZxq8v//i21p zudbI7nSQ39apPLcD3zqkMWY875KykAhlxSQUDwBPjbfqE9oS4O06wT0Yo7nGlnOgKlk PaB5Sm1NVtb4bifIxeeAWdvV3OFlIkmIuZvsrEwTbSxb7LEQn3kLQBQ5CjqcGf2lokAZ +L75OvMD1317PaBTtuUjkgx820a5Tfv/GjxQUqwdoCN7MzIjHcJmL4qIHm5f0h4R08Jp MEG2BbgN61o43PK21RXM5VI21JmkeCIMC/sM96IsnRg3LZq7ZVowOmxEYE8XyYIXrB/g GpFg== X-Gm-Message-State: APjAAAVUxyp6h/bzNyj0BRPwMqOqfM4HMTgY4NIcUUqjfd04jEXZTFi+ wjC1MKfyJTWXxWU19G7CLBAqBh02jN7EwyIfU2A= X-Google-Smtp-Source: APXvYqzseGBuXGWJkPmsdmlSiPyrcYiIpe3BG6bQ1QLHRrFZqDjs8OWAcL2JjQzfPup9tTb9Tu+8xRvJBqZ34AZT+A4= X-Received: by 2002:a17:90a:35e3:: with SMTP id r90mr18460354pjb.34.1566174760178; Sun, 18 Aug 2019 17:32:40 -0700 (PDT) MIME-Version: 1.0 References: <156564165569.17882.915608325158791837@ietfa.amsl.com> In-Reply-To: <156564165569.17882.915608325158791837@ietfa.amsl.com> From: Stan Ratliff Date: Sun, 18 Aug 2019 20:32:29 -0400 Message-ID: To: Nancy Cam-Winget Cc: secdir@ietf.org, draft-ietf-manet-dlep-lid-extension.all@ietf.org, MANET IETF , ietf@ietf.org Content-Type: multipart/alternative; boundary="0000000000003c981a05906d7a6b" Archived-At: Subject: Re: [secdir] [manet] Secdir last call review of draft-ietf-manet-dlep-lid-extension-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 00:32:44 -0000 --0000000000003c981a05906d7a6b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello. Thank you for the review and comments. Responses inline. On Mon, Aug 12, 2019 at 4:28 PM Nancy Cam-Winget via Datatracker < noreply@ietf.org> wrote: > Reviewer: Nancy Cam-Winget > Review result: Has Issues > > SECDIR review of draft-ietf-manet-dlep-lid-extension-05 > > Reviewer: Nancy Cam-Winget > Review result: Ready with questions (issues?) > > I have reviewed this document as part of the security directorate's=C3=8A > ongoing effort to review all IETF documents being processed by the=C3=8A > IESG.=C3=8A=C3=8AThese comments were written primarily for the benefit of= the=C3=8A > security area directors.=C3=8A=C3=8ADocument editors and WG chairs should= treat=C3=8A > these comments just like any other last call comments. > > This document defines extensions to the Data Link Exchange Protocol (DLEP= ) > to > enable modems to advertise the status of wireless links that are not > reachable > beyond a device on the Layer 2 domain. The extension focuses on the > inclusion > of IPv4 or IPv6 address(es) to DLEP when the modems provide Layer 3 > connectivity. > > As this is not my area of domain expertise, I have the following question= s: > * It seems that WANs could include NATs but I see no consideration for ho= w > to > treat the IP addresses in the presence of NAT. Is this not an issue? I > think > some mention of this should be included. > IP addresses that are contained in DLEP LID are assumed to be on the public side of any NAT (that is, post-NAT for egress traffic, pre-NAT for ingress traffic). We can work on including this assumption in the draft. > > * Section 2.1: What happens if Link Identifiers span multiple MAC > Addresses or > if they are reused? What does it mean for a link identifier to be reused > (per > session? or ever?) There is a reference to the destination MUST NOT be > recycled, but I am not sure what recycled means in this context? What > happens > if they are reused? A note either here, or in the security consideration= s > should describe these conditions. > Link identifiers MUST NOT span MAC addresses, nor can they be reused. This is what the text refers to when it discusses "recycling" LIDs.Having said that, we will work on strengthening the language. > > * Section 2.2: what happens if "link identifiers" is negotiated but no li= nk > identifiers are provided? > If identifiers are negotiated, and then not used, there is no impact to operation. The LID was introduced as a way for radio modems to introduce destinations that it knows about, but that it does not specifically manage from a Layer1/Layer2 perspective. > > * Security (no privacy considerations?): given that this draft is now > including > IP addresses, it seems that there is potential to determine a network > topology > and perhaps identification of a network used to mount attacks. I do see > that > RFC 8175 doesn't have privacy considerations, but given that this is now > at the > IP layer it may be good to provide one? > The notion of IP address vectors is in RFC 8175. The IP address(es) represent the unicast IP addresses of the destination specified, or potentially a Multicast address to be carried over the RF. IMO, the introduction of LIDs and their IP addresses does not increase the potential security exposure over and above the RFC 8175 flows that can contiain IP addressing information. I hope this addresses your concerns. Please let me know if additional discussion is needed. Regards, Stan > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --0000000000003c981a05906d7a6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello. Thank you for the review and comments. Respons= es inline.


On Mon, Aug 12, 2019 at 4:28 PM Nancy Cam-Winget v= ia Datatracker <noreply@ietf.org= > wrote:
Reviewer: Nancy Cam-Winget
Review result: Has Issues

SECDIR review of draft-ietf-manet-dlep-lid-extension-05

Reviewer: Nancy Cam-Winget
Review result: Ready with questions (issues?)

I have reviewed this document as part of the security directorate's=C3= =8A
ongoing effort to review all IETF documents being processed by the=C3=8A IESG.=C3=8A=C3=8AThese comments were written primarily for the benefit of t= he=C3=8A
security area directors.=C3=8A=C3=8ADocument editors and WG chairs should t= reat=C3=8A
these comments just like any other last call comments.

This document defines extensions to the Data Link Exchange Protocol (DLEP) = to
enable modems to advertise the status of wireless links that are not reacha= ble
beyond a device on the Layer 2 domain. The extension focuses on the inclusi= on
of IPv4 or IPv6 address(es) to DLEP when the modems provide Layer 3
connectivity.

As this is not my area of domain expertise, I have the following questions:=
* It seems that WANs could include NATs but I see no consideration for how = to
treat the IP addresses in the presence of NAT.=C2=A0 Is this not an issue?= =C2=A0 =C2=A0I think
some mention of this should be included.

IP addresses that are contained in DLEP LID are assumed to be on the publ= ic side of any NAT (that is, post-NAT for egress traffic, pre-NAT for ingre= ss traffic). We can work on including this assumption in the draft.=C2=A0
=C2=A0

* Section 2.1: What happens if Link Identifiers span multiple MAC Addresses= or
if they are reused?=C2=A0 What does it mean for a link identifier to be reu= sed (per
session? or ever?)=C2=A0 There is a reference to the destination MUST NOT b= e
recycled, but I am not sure what recycled means in this context?=C2=A0 What= happens
if they are reused?=C2=A0 A note either here, or in the security considerat= ions
should describe these conditions.

Link = identifiers MUST NOT span MAC addresses, nor can they be reused. This is wh= at the text refers to when it discusses "recycling" LIDs.Having s= aid that, we will work on strengthening the language.=C2=A0
=C2= =A0

* Section 2.2: what happens if "link identifiers" is negotiated b= ut no link
identifiers are provided?

If identifier= s are negotiated, and then not used, there is no impact to operation. The L= ID was introduced as a way for radio modems to introduce destinations that = it knows about, but that it does not specifically manage from a Layer1/Laye= r2 perspective.=C2=A0
=C2=A0

* Security (no privacy considerations?): given that this draft is now inclu= ding
IP addresses, it seems that there is potential to determine a network topol= ogy
and perhaps identification of a network used to mount attacks.=C2=A0 I do s= ee that
RFC 8175 doesn't have privacy considerations, but given that this is no= w at the
IP layer it may be good to provide one?

The notion of IP address vectors is in RFC 8175. The IP address(es) repres= ent the unicast IP addresses of the destination specified, or potentially a= Multicast address to be carried over the RF. IMO, the introduction of LIDs= and their IP addresses does not increase the potential security exposure o= ver and above the RFC 8175 flows that can contiain IP addressing informatio= n.=C2=A0

I hope this addresses your concerns. Plea= se let me know if additional discussion is needed.=C2=A0

Regards,
Stan




_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--0000000000003c981a05906d7a6b-- From nobody Sun Aug 18 17:48:00 2019 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 BE0B712009C; Sun, 18 Aug 2019 17:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4-0rDTyzc4U; Sun, 18 Aug 2019 17:47:57 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C6112007A; Sun, 18 Aug 2019 17:47:53 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id z51so105015edz.13; Sun, 18 Aug 2019 17:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=a2K/lBsJD799OmfrYgEUyE560WiB/D1XGsNRBrp5Vfo=; b=SkeTXefx2kPdYqQ9kz54gzKWgYqkcvSczAW5aqNr4Of5I2daXOh8Q0EKFHX/gvceY2 PCFLdInetWEDJKAHn5dbyiBi+p6BAe9Y3k/VtBHNuj8VxqM6DRa5k2nNI0hFrWPv/pyg QYpPRTIxlvYSjvYFVt4necC3scSe+cmvqJYxgimf1blTgZrn38j7Sip+pLv0+DlpG4B2 sjrsLKXxqCubdUPg5xGWxGl1fp1wAXmfUNWRRvuS4cMvTU9hmXxOYcACa+g/JNhpkBUt YhHXuBCtuEfqMpig8goqAWgiKg75zgSIfPunnjAGE+5UvG3oGl7x80gn3FnslpEx9QZx UtZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=a2K/lBsJD799OmfrYgEUyE560WiB/D1XGsNRBrp5Vfo=; b=C1p5TykQHq5BDTNeTIFb5pnc8T/QBe7BqrFxNiI1yvJt3mNCxk7NMJkY8FmtOPJ01r g+RIxQRTC24mK55TFcoewrleNFW0nxH45C1zyNGRzm2V3KQppfMSxHte4yDy2stfbxtW 8phzsop1klYuEsuRf7u04spNOa8xzGdko80sSbEDCoK1TLVHFu3am1rWMYcnWMGJF3Je QhcP2CXin7fdeyScebmSGH27+CKo8yIXE1SP55yMf6PW2AGGPQuYUKVt4GNSIMO7rrJM +YceLHZ4HYN673sw0OnsY2I7luNM5qoqMpTMx/fp3cmDPmYgG9GCMOZnb7GdtKZ8iXOb Ufdg== X-Gm-Message-State: APjAAAV1gW/ydEE6HkdjiNkEt7k1lbtGKcLIy6RnpPc32rQxsCdAJysO PteiXcjSa3KOBYwxweWc0b9A69TqRY75v3lmNu3MoNIi X-Google-Smtp-Source: APXvYqwJeBVBB1z84j/OF8NyKIMKJnWWvLzpmx2JZ0FpXaoO+0emxTzNSbsiMrqs96dxrAgLU93fVsy5+Xe55P5vj3M= X-Received: by 2002:a50:a48a:: with SMTP id w10mr22820761edb.1.1566175671900; Sun, 18 Aug 2019 17:47:51 -0700 (PDT) MIME-Version: 1.0 From: Shawn Emery Date: Sun, 18 Aug 2019 18:47:40 -0600 Message-ID: To: secdir@ietf.org, draft-ietf-pce-lsp-control-request.all@ietf.org Cc: Shawn Emery Content-Type: multipart/alternative; boundary="000000000000945e8605906db0c9" Archived-At: Subject: [secdir] Review of draft-ietf-pce-lsp-control-request-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 00:47:59 -0000 --000000000000945e8605906db0c9 Content-Type: text/plain; charset="UTF-8" Reviewer: Shawn M. Emery Review result: Ready 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 specifies an extension to the Path Computation Element communication Protocol (PCE) that allows a PCE to request control of Label Switched Paths (LSPs). The security considerations section does exist and discusses a new DoS vector that this draft creates. The attack involves sending control requests for delegate control of all of its LSPs to the Path Computation Client (PCC). The proposed solution is to set a threshold rate of the delegation requests for the PCC per PCE. I agree with the proposed solution, though I don't know if guidance can be provided on what these thresholds would be per environment. The section goes on to refer to RFC 8231 to justify that the PCP extension should be deployed with authenticated and encrypted sessions in TLS using RFC 8253. I agree with this prescription as well else an attacker would now be able to take control over all local LSPs with this extension. I think that this should at least be stated if an attacker is able to compromise a PCE. General comments: None. Editorial comments: s/sends PCRpt/sends a PCRpt/ s/also specify/also specifies/ s/all its/all of its/ s/If threshold/If the threshold/ s/explicitly set aside/explicitly excluded/ Shawn. -- --000000000000945e8605906db0c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reviewer: Shawn M. EmeryReview result= :=C2=A0Ready
=
I have reviewed this document as part of the security direct= orate's
ongoing effort to review all=C2=A0IETF<= /span>=C2=A0documents being processed by the IESG.
These comments were written p= rimarily 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 specifies an extension to the Path Computation Element communi= cation
Protocol (PCE) that allows a PC= E to request control of Label Switched Paths (LSPs).

The security considerations section does e= xist and discusses a new DoS vector
th= at this draft creates.=C2=A0 The attack involves sending control requests f= or delegate
control of all of its LSPs= to the Path Computation Client (PCC).=C2=A0 The proposed
solution is to set a threshold rate of the delegation= requests for the PCC per PCE.
I agree= with the proposed solution, though I don't know if guidance can be pro= vided
on what these thresholds would b= e per environment.

The section goes on to refer to RFC 8231 to justify = that the PCP extension=C2=A0should<= /div>
be de= ployed with authenticated and encrypted sessions in TLS using RFC 8253.
I= agree with this=C2=A0prescription = as well else an attacker would now be able to take
control over all loc= al LSPs with this extension.=C2=A0 I think that this should at least be
s= tated if an attacker is able to compromise a PCE.

General commen= ts:

None.

Editorial comments:

s/sends PCRpt/sends a PCRpt/
s/also specify/also specifies/
s/all its/all of its/
s/<= span style=3D"font-size:small">If threshold/If the threshold/
s/exp= licitly set aside/explicitly excluded/
Shawn.
--
<= /div> --000000000000945e8605906db0c9-- From nobody Mon Aug 19 22:44:50 2019 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 8776E1200EC; Mon, 19 Aug 2019 22:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgSQpJqhxWNl; Mon, 19 Aug 2019 22:44:40 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0EAD1200CC; Mon, 19 Aug 2019 22:44:39 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id s21so9677589ioa.1; Mon, 19 Aug 2019 22:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PPC9NQFizlMsPI56G4CwH84q6M4X0Jbxi7CsfdBaeew=; b=ltkcHA0rqRAslhF62tnEpjW2L5+ZLR7O3bWzHETdzVkQISVsy6i2pK+Mye74SgljTK tMv5Ow+XtjGnhueQ9EMGUB4XVeOkq9AeNK6nHxLm9FZQnN1Ced+a/r79Mb64k4ZmI0FU AMZa7sxAygoLtVqCRRrAk0wO5ElUsGAKIHj0a7wo1A5PbXdkE0fJOADBITGaisTx0u3u h5J5x6JLyNIg1S0XpmEoIMIhB1KOX+xbasWj6wB+7gG1s6V/8H0pVQl4oWCkeMwL2305 aTUFDNjDSDE3+eCRzWITLvW3c9nUW+1E/eQ4pLhPCpFtdM/3FGMi+CT3PSuuiYibxrDP ofxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PPC9NQFizlMsPI56G4CwH84q6M4X0Jbxi7CsfdBaeew=; b=Ilowp4gb63v30LEo1rMtbk0uSpSiO6SWOyiB4eD7MJhFNIKvENMK0a41pj6S8AkW1l ptaTPDaGTyqOYPtDz5Uz/fUUNkD7eFvenbdOy+f30iPOtdPvq03i18ClwPnKwIoYWia6 cTyPSciwds6KVAsk9U7GAw7VwhFYRJz1L8P2lcOiQ5bgNYogsKjKnShWcx/YpJralOYr k80OPEKmlop44EGxFOXDWNHo/5Wghtfw7Aqm6mvRmyh/MSvwfI6ztXRQzGNhmAWi0zda fvJkuDr08lHM6pgMjbg9qvN4ys8UDtIkYESA2GxCJOVvbLA0IgqX7tuuD6wJo2v9HUfC uc3g== X-Gm-Message-State: APjAAAW8xtpvgBUd0cgLfRanddFM6abrnb93i+djYVqizEiBXPiBFvYp 4YciqStPcfzWARoxpw5xTHCz9YmIfG901gY6tLE= X-Google-Smtp-Source: APXvYqzLEOoOIMieHRlyb+U5J0bPO86vyTb2y9KgsOQzjd7zEob0pi29vKEnjdhtczr8PI/E+GTXF+6vYiZK4jz7+qY= X-Received: by 2002:a5d:890d:: with SMTP id b13mr27967654ion.124.1566279879089; Mon, 19 Aug 2019 22:44:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dhruv Dhody Date: Tue, 20 Aug 2019 11:14:02 +0530 Message-ID: To: Shawn Emery Cc: secdir , draft-ietf-pce-lsp-control-request.all@ietf.org, Shawn Emery , pce@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Review of draft-ietf-pce-lsp-control-request-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 05:44:42 -0000 Hi Shawn, Thanks for your security review and comments. On Mon, Aug 19, 2019 at 6:17 AM Shawn Emery wrote: > > Reviewer: Shawn M. Emery > Review result: Ready > > 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 specifies an extension to the Path Computation Element communication > Protocol (PCE) that allows a PCE to request control of Label Switched Paths (LSPs). > > The security considerations section does exist and discusses a new DoS vector > that this draft creates. The attack involves sending control requests for delegate > control of all of its LSPs to the Path Computation Client (PCC). The proposed > solution is to set a threshold rate of the delegation requests for the PCC per PCE. > I agree with the proposed solution, though I don't know if guidance can be provided > on what these thresholds would be per environment. > As you noted the document does not provide default for the threshold as it dependent on the deployment/environment. The same is true for RFC 8231. > The section goes on to refer to RFC 8231 to justify that the PCP extension should > be deployed with authenticated and encrypted sessions in TLS using RFC 8253. > I agree with this prescription as well else an attacker would now be able to take > control over all local LSPs with this extension. I think that this should at least be > stated if an attacker is able to compromise a PCE. > The security consideration includes "...either by spoofing messages or by compromising the PCE itself". > General comments: > > None. > > Editorial comments: > > s/sends PCRpt/sends a PCRpt/ > s/also specify/also specifies/ > s/all its/all of its/ > s/If threshold/If the threshold/ > s/explicitly set aside/explicitly excluded/ > Thanks for these, request authors to handle them. Thanks! Dhruv > Shawn. > -- From nobody Tue Aug 20 13:19:21 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EC5120086; Tue, 20 Aug 2019 13:19:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Phillip Hallam-Baker via Datatracker To: Cc: spasm@ietf.org, draft-ietf-lamps-cms-mix-with-psk.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Phillip Hallam-Baker Message-ID: <156633236010.354.17330616899278153955@ietfa.amsl.com> Date: Tue, 20 Aug 2019 13:19:20 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-lamps-cms-mix-with-psk-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 20:19:20 -0000 Reviewer: Phillip Hallam-Baker Review result: Ready We need the capability, the text is readable and there is a formal proof. What more could we ask for? The document provides a mechanism for protecting encrypted data by constructing a symmetric key from the combination of a key agreement value constructed in the normal fashion and a shared secret. This construction provides protection against quantum cryptanalysis. Application of the scheme is outside the scope of the document and is likely to be challenging as the scheme has to rely on the shared secret not being exposed in any form vulnerable to quantum cryptanalysis. From nobody Wed Aug 21 04:42:13 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FB912091F; Wed, 21 Aug 2019 04:42:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty via Datatracker To: Cc: lsr@ietf.org, ietf@ietf.org, draft-ietf-ospf-xaf-te.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Kathleen Moriarty Message-ID: <156638772406.25805.16453148781314116651@ietfa.amsl.com> Date: Wed, 21 Aug 2019 04:42:04 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ospf-xaf-te-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 11:42:04 -0000 Reviewer: Kathleen Moriarty Review result: Has Nits I apologize for the very late review. I see you are already working on Roman's discuss, so perhaps this nit could be addressed still. In the security considerations section, the following text is included: As such, no new security threats are introduced beyond the considerations in OSPFv2 [RFC2328], OSPFv3 [RFC5340], and [RFC5786]. However, new considerations follow and as such, the above statement isn't entirely accurate. I do agree that no security is provided in these protocols, and that is not new, but new information is exposed. Perhaps saying additional considerations follow would be better than saying "no new security threats are introduced". Thank you, Kathleen From nobody Wed Aug 21 05:07:12 2019 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 E7811120119; Wed, 21 Aug 2019 05:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=LEjLnnEP; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MqrzTmMU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fydO0VbgkifI; Wed, 21 Aug 2019 05:07:09 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B101200F8; Wed, 21 Aug 2019 05:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1946; q=dns/txt; s=iport; t=1566389229; x=1567598829; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZTRl+3FOCoyb0pYU6qotISN+bPIBsy7Wf0I+DRBpw7w=; b=LEjLnnEPldEe9JrHofjgQs8EcmDzkubNTmeDEhO53b2kt/rpwCyeiFkW oGwNoTPh2xZuvd40Xn/POW+1W00qxpXesCr3JZRVxhtGuyo5/ywS9JBBN +zBMu1buQiZfIgi1MBir6YYZQ6y0mBuAoozyNy96gCfsTD+V9LYzH/SHk 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AjdKmmhzhUNZQfpnXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YRGN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A+GsHbIQKUh?= =?us-ascii?q?YEjcsMmAl1CcWIBGXwLeXhaGoxG8ERHFI=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAAAsM11d/40NJK1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGBRCQsA4FCIAQLKoQfg0cDhFKGKppBgS6BJAN?= =?us-ascii?q?UCQEBAQwBAS0CAQGEPwIXgkUjNAkOAgUBAQQBAQMBBgRthScMhUsCBBIREQw?= =?us-ascii?q?BATcBDwIBCBoCJgICAjAVEAIEAQ0FIoMAgWsDHQECn0ACgTiIYXOBMoJ7AQE?= =?us-ascii?q?FhRgYghYJgQwoAYtoGIF/gTgfgkw+hESDCzKCJo8XnEIJAoIdkESDdRuYRo1?= =?us-ascii?q?bmA4CBAIEBQIOAQEFgVA4gVhwFWUBgkGCQoNyilNygSmLfgEB?= X-IronPort-AV: E=Sophos;i="5.64,412,1559520000"; d="scan'208";a="398802441" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Aug 2019 12:07:08 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x7LC78gM027305 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Aug 2019 12:07:08 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 21 Aug 2019 07:07:07 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 21 Aug 2019 08:07:06 -0400 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 21 Aug 2019 07:07:06 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QI1PWfT8o2p/12KgcAFJNGjfNLCmwClS+j/oyXbyjF3S4PX9DnD5Wjj/Z+kDssGNh62HkRsk1RT9ARQpeH5FyQLvJjALjoaNdp7n+wE+3jRYY+NOSq3stmNIq9XPFF7OVsn0tesG9i9gTBwzYurisvhlcdCKEFPOEubqGwGRgnCzUw7DMPckhg3tA5C0BaIgYSbDURp9npujRBjSch9NROmDKf06oulbpwmOIZ2nfJzFvnkthXpWQp9S6OvmAtIEhcxL+4dCFKBLqWHqxRciZRzwNFeS+d3inhyC7VB0+6k5+ZoeQPpru60OXZu2T7PUNSnRhKzdsILG22FPbL1D8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZTRl+3FOCoyb0pYU6qotISN+bPIBsy7Wf0I+DRBpw7w=; b=eK0fT43irQFyHxrkYhmFTUoVnaTqUhl/T2eW9GbUSNuY1NWCd7V3UtjRE7ORszO7VS7D3yQqCEw8pJMJ6jnP1gMIw9u5N2WEfkdQq+6dgCg9GIUXrBYZLkB1DrHUy6PI5G/RKCjuHmbmSpXrP+XmCifDe+A11loM8dyTDFuBqZ7xlvVuUVWJ87JYghW9bc3KIqLUm+Abhej0f5rYcdZmtrAaoS3OKp0z967xMezK/urxfOc61l5Sfi0/GgkJIFec1Zp+eVx7FYAOzi/pJ+LRDs76Yz36/77khSkAjPrnnUdKpV11SI/2EbV4RBwOO8DIrz26BMyWqUle3iIMsIs2Pg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZTRl+3FOCoyb0pYU6qotISN+bPIBsy7Wf0I+DRBpw7w=; b=MqrzTmMUQwlEt9Vq7It8amcMyIxbHywoHOHnlIKmFTxAwaj+cRf5Cpp2WEunbM8VaVQFtytLD//JZv0RfTY7RxkAvEaViouXX7EiDMeqAqmUjgW3rVD9EDcHFn+o/YlozjzgCRnHyrZcrK6vqMQEMcUkBJk/Ak5cEtcEya6QcrQ= Received: from MN2PR11MB4221.namprd11.prod.outlook.com (52.135.38.14) by MN2PR11MB3568.namprd11.prod.outlook.com (20.178.251.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.18; Wed, 21 Aug 2019 12:07:05 +0000 Received: from MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::859c:f271:3be2:74e0]) by MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::859c:f271:3be2:74e0%3]) with mapi id 15.20.2178.020; Wed, 21 Aug 2019 12:07:05 +0000 From: "Acee Lindem (acee)" To: Kathleen Moriarty , "secdir@ietf.org" CC: "lsr@ietf.org" , "ietf@ietf.org" , "draft-ietf-ospf-xaf-te.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-ospf-xaf-te-07 Thread-Index: AQHVWBV9HutM5zDlckOJcOKXimRCFacFPqoA Date: Wed, 21 Aug 2019 12:07:04 +0000 Message-ID: <0B17F3B3-401E-47CC-AA68-61EAE5DFEF23@cisco.com> References: <156638772406.25805.16453148781314116651@ietfa.amsl.com> In-Reply-To: <156638772406.25805.16453148781314116651@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; x-originating-ip: [2001:420:c0c4:1007::de] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 008c42f8-b7a9-416f-b7e9-08d72630152b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3568; x-ms-traffictypediagnostic: MN2PR11MB3568: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(396003)(39860400002)(376002)(136003)(199004)(189003)(6506007)(66946007)(66556008)(102836004)(316002)(54906003)(2906002)(11346002)(110136005)(186003)(8936002)(81166006)(81156014)(478600001)(25786009)(8676002)(4326008)(6246003)(53936002)(5660300002)(229853002)(86362001)(14454004)(33656002)(6116002)(6436002)(486006)(6486002)(7736002)(2501003)(46003)(99286004)(6512007)(2616005)(476003)(14444005)(256004)(76176011)(446003)(64756008)(305945005)(66476007)(36756003)(76116006)(66446008)(71200400001)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3568; H:MN2PR11MB4221.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: gylG9VjPDLiscdT+lurd8z8NyR7fBZIUyf6CMg2O4F057MToXK9YYO5KkRNkwUF0nqCHaZFXrq6g3najcTe8Vqcg6cTiK34z3p44lkHlxFwrcymDbGeScOuOsamA2fV6yXP7qYqGpD2oMcS+GihACx9ejnJDOUONhypZ1Im3uwIcUWGm+59ff6YNiIw1xMOTqyxlfj7gUrsOnYBjcCYxJ5+t+DNEhJaOtSiXI+ZNd6rW+ZqovQgUUXkK5rw/6ruQ3ruY2yUpIqpthrrHxom1eqJ5GnpcYtFGNvlb1lwvYJCN1wZMTRJ5BXn3vAcZePFu/igW6Uw2qSzjOmh1uORzkYNKYZSD9P85fZoNYtnUbU59ytabwLpctpo7O7ol3pVibgOTxTH4fSNB8Liz+v3SxDA7mpMMJGGrkKCkvJQMOTA= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <1EB9B8948E6D3C4EBB7ED9C96963E3A8@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 008c42f8-b7a9-416f-b7e9-08d72630152b X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 12:07:04.9927 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LCuOMfVESEnkuZH7jhtEolw3cwzTv2vrr0VLhYhwDQPRf+S/EId7LxOTeW3CeEGs X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3568 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ospf-xaf-te-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 12:07:11 -0000 SGkuIEthdGhsZWVuLCANCg0K77u/T24gOC8yMS8xOSwgNzo0MiBBTSwgIkthdGhsZWVuIE1vcmlh cnR5IHZpYSBEYXRhdHJhY2tlciIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgUmV2 aWV3ZXI6IEthdGhsZWVuIE1vcmlhcnR5DQogICAgUmV2aWV3IHJlc3VsdDogSGFzIE5pdHMNCiAg ICANCiAgICBJIGFwb2xvZ2l6ZSBmb3IgdGhlIHZlcnkgbGF0ZSByZXZpZXcuICBJIHNlZSB5b3Ug YXJlIGFscmVhZHkgd29ya2luZyBvbiBSb21hbidzDQogICAgZGlzY3Vzcywgc28gcGVyaGFwcyB0 aGlzIG5pdCBjb3VsZCBiZSBhZGRyZXNzZWQgc3RpbGwuDQogICAgDQogICAgSW4gdGhlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24sIHRoZSBmb2xsb3dpbmcgdGV4dCBpcyBpbmNsdWRl ZDoNCiAgICANCiAgICAgICBBcyBzdWNoLCBubyBuZXcNCiAgICAgICBzZWN1cml0eSB0aHJlYXRz IGFyZSBpbnRyb2R1Y2VkIGJleW9uZCB0aGUgY29uc2lkZXJhdGlvbnMgaW4gT1NQRnYyDQogICAg ICAgW1JGQzIzMjhdLCBPU1BGdjMgW1JGQzUzNDBdLCBhbmQgW1JGQzU3ODZdLg0KICAgIA0KICAg IEhvd2V2ZXIsIG5ldyBjb25zaWRlcmF0aW9ucyBmb2xsb3cgYW5kIGFzIHN1Y2gsIHRoZSBhYm92 ZSBzdGF0ZW1lbnQgaXNuJ3QNCiAgICBlbnRpcmVseSBhY2N1cmF0ZS4gIEkgZG8gYWdyZWUgdGhh dCBubyBzZWN1cml0eSBpcyBwcm92aWRlZCBpbiB0aGVzZSBwcm90b2NvbHMsDQogICAgYW5kIHRo YXQgaXMgbm90IG5ldywgYnV0IG5ldyBpbmZvcm1hdGlvbiBpcyBleHBvc2VkLiAgUGVyaGFwcyBz YXlpbmcgYWRkaXRpb25hbA0KICAgIGNvbnNpZGVyYXRpb25zIGZvbGxvdyB3b3VsZCBiZSBiZXR0 ZXIgdGhhbiBzYXlpbmcgIm5vIG5ldyBzZWN1cml0eSB0aHJlYXRzIGFyZQ0KICAgIGludHJvZHVj ZWQiLg0KDQpBcyBkb2N1bWVudCBzaGVwaGVyZCBhbmQgTFNSIFdHIENvLUNoYWlyLCBJIGRpc2Fn cmVlLiBUaGVyZSBpcyBubyBuZXcgaW5mb3JtYXRpb24gZXhwb3NlZC4gVGhpcyBkcmFmdCBzaW1w bHkgZW5hYmxlcyB0aGUgVEUgZW5kcG9pbnRzIGZyb20gYm90aCBJUHY0IGFuZCBJUHY2IHRvIGJl IGFkdmVydGlzZWQgaW4gZWl0aGVyIE9TUEZ2MiBvciBPU1BGdjMgcmF0aGVyIHRoYW4gcmVsZWdh dGluZyBhZHZlcnRpc2VtZW50IG9mIElQdjQgVEUgaW5mb3JtYXRpb24gdG8gT1NQRnYyIGFuZCBJ UHY2IFRFIGluZm9ybWF0aW9uIHRvIE9TUEZ2My4gSWYgYW55dGhpbmcsIGl0IGltcHJvdmVzIHNl Y3VyaXR5IGJ5IHJlZHVjaW5nIHRoZSBzdXJmYWNlIGFyZWEgZm9yIGF0dGFja3MgdG8gYSBzaW5n bGUgcHJvdG9jb2wgcmF0aGVyIHRoYW4gYm90aCBwcm90b2NvbHMuIA0KDQpUaGFua3MsDQpBY2Vl DQogICAgDQogICAgVGhhbmsgeW91LA0KICAgIEthdGhsZWVuDQogICAgDQogICAgDQoNCg== From nobody Wed Aug 21 06:30:10 2019 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 1817B120052; Wed, 21 Aug 2019 06:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fxa4O1hyf8MP; Wed, 21 Aug 2019 06:29:56 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2BC12002F; Wed, 21 Aug 2019 06:29:56 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id c7so2055645otp.1; Wed, 21 Aug 2019 06:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NynLwmPnaXt2Rj9xZJj3v5VODKFP0oFG48Ye2jshID8=; b=OPge0Uk9gzlLlYZ93jzOZ/AGb0F32ysVl+FSKvHpb0H6aAC5AWpAY4X+heHnAQwgze 448fbY7aD77s2r7RJXqtvWUJ537o0GjW/p7Vd9EJsL2UQ/oLOTvAkcCVkWYLPhJPGUI7 16COHQ0txr1MSNr7g2M7oPk+cejQbCEcqinq5ETUJ1DhOAf+zmUKGSy7fZivJpueuaCf j0VHE1Yjh2ngVIwRN6ld8sl7tg8BIBTF7mnVMJSb1G861ju2liHTF4zI66wRLcjSFU59 Z1raUnXtWDlWGN7wsNYzF+3Q1ccvC5JxkHHhG+X49bdBEcAnayVEdYNnQiy6ZL2GM3Ag KVfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NynLwmPnaXt2Rj9xZJj3v5VODKFP0oFG48Ye2jshID8=; b=cSIGm8PzVbNSKIaiKVB3cUk5m3Po78cYWr0h0q9lHgDVUpUGSk7f6Ydwtd4vw7MDM6 jbIGc5SUnO06Vx4JItg+02auzWAMIhGkhc2Nb8925hK1JsKDkn/e13vAV/2ftLEzQ2F5 4Ieggtg15uhCJuXJIVbUV3YqpRVrvTRbVmhGC2D390Ph5DDXVng76ua/IxLIk7aLqoSo mptwZIjAUjhPIOoc++uX+uNysEumpX0fudAez8/eBsj9mxBLmdhS8v74nXulIf6t5/xU pr8Xqo/CyZLGqGtjRyrRFqthnOvuhSXG2ErO/jyAMQRIT53VbCVB9J2uOBXSwnaPO5Xo dfqg== X-Gm-Message-State: APjAAAXFu+KjY36Hn24tvazy2cvviLKINZQmgcCAlDUqyGZJ+NMwo145 AP81Wy42+StSzp9j396HTcpafEV7M76YjaR0HqM= X-Google-Smtp-Source: APXvYqwGfP/PMRk100gonn2XKdwTIgtJBVPRCwlswAV9K6EAR0sUYQAPpH4Oi2NpoSTWg+ThSrRbldk7oX679sEY4+Y= X-Received: by 2002:a9d:68c5:: with SMTP id i5mr3417043oto.250.1566394195706; Wed, 21 Aug 2019 06:29:55 -0700 (PDT) MIME-Version: 1.0 References: <156638772406.25805.16453148781314116651@ietfa.amsl.com> <0B17F3B3-401E-47CC-AA68-61EAE5DFEF23@cisco.com> In-Reply-To: <0B17F3B3-401E-47CC-AA68-61EAE5DFEF23@cisco.com> From: Kathleen Moriarty Date: Wed, 21 Aug 2019 09:29:19 -0400 Message-ID: To: "Acee Lindem (acee)" Cc: "secdir@ietf.org" , "lsr@ietf.org" , "ietf@ietf.org" , "draft-ietf-ospf-xaf-te.all@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009d067a0590a09175" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ospf-xaf-te-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 13:29:58 -0000 --0000000000009d067a0590a09175 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 21, 2019 at 8:07 AM Acee Lindem (acee) wrote: > Hi. Kathleen, > > =EF=BB=BFOn 8/21/19, 7:42 AM, "Kathleen Moriarty via Datatracker" < > noreply@ietf.org> wrote: > > Reviewer: Kathleen Moriarty > Review result: Has Nits > > I apologize for the very late review. I see you are already working > on Roman's > discuss, so perhaps this nit could be addressed still. > > In the security considerations section, the following text is include= d: > > As such, no new > security threats are introduced beyond the considerations in OSPFv= 2 > [RFC2328], OSPFv3 [RFC5340], and [RFC5786]. > > However, new considerations follow and as such, the above statement > isn't > entirely accurate. I do agree that no security is provided in these > protocols, > and that is not new, but new information is exposed. Perhaps saying > additional > considerations follow would be better than saying "no new security > threats are > introduced". > > As document shepherd and LSR WG Co-Chair, I disagree. There is no new > information exposed. This draft simply enables the TE endpoints from both > IPv4 and IPv6 to be advertised in either OSPFv2 or OSPFv3 rather than > relegating advertisement of IPv4 TE information to OSPFv2 and IPv6 TE > information to OSPFv3. If anything, it improves security by reducing the > surface area for attacks to a single protocol rather than both protocols. > > I won't fight it and it is really too late, but I dislike the sentence especially when used on a protocol with no security properties. If someone doesn't realize the current state and overall lack of security, this sentence doesn't help. Best regards, Kathleen > Thanks, > Acee > > Thank you, > Kathleen > > > > --=20 Best regards, Kathleen --0000000000009d067a0590a09175 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 21, 2019 at 8:07 AM Acee = Lindem (acee) <acee@cisco.com> = wrote:
Hi. Kathl= een,

=EF=BB=BFOn 8/21/19, 7:42 AM, "Kathleen Moriarty via Datatracker"= <noreply@ietf.org= > wrote:

=C2=A0 =C2=A0 Reviewer: Kathleen Moriarty
=C2=A0 =C2=A0 Review result: Has Nits

=C2=A0 =C2=A0 I apologize for the very late review.=C2=A0 I see you are alr= eady working on Roman's
=C2=A0 =C2=A0 discuss, so perhaps this nit could be addressed still.

=C2=A0 =C2=A0 In the security considerations section, the following text is= included:

=C2=A0 =C2=A0 =C2=A0 =C2=A0As such, no new
=C2=A0 =C2=A0 =C2=A0 =C2=A0security threats are introduced beyond the consi= derations in OSPFv2
=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC2328], OSPFv3 [RFC5340], and [RFC5786].

=C2=A0 =C2=A0 However, new considerations follow and as such, the above sta= tement isn't
=C2=A0 =C2=A0 entirely accurate.=C2=A0 I do agree that no security is provi= ded in these protocols,
=C2=A0 =C2=A0 and that is not new, but new information is exposed.=C2=A0 Pe= rhaps saying additional
=C2=A0 =C2=A0 considerations follow would be better than saying "no ne= w security threats are
=C2=A0 =C2=A0 introduced".

As document shepherd and LSR WG Co-Chair, I disagree. There is no new infor= mation exposed. This draft simply enables the TE endpoints from both IPv4 a= nd IPv6 to be advertised in either OSPFv2 or OSPFv3 rather than relegating = advertisement of IPv4 TE information to OSPFv2 and IPv6 TE information to O= SPFv3. If anything, it improves security by reducing the surface area for a= ttacks to a single protocol rather than both protocols.

I won't fight it and it is really too late, but I= dislike the sentence especially when used on a protocol with no security p= roperties.=C2=A0 If someone doesn't realize the current state and overa= ll lack of security, this sentence doesn't help.

Best regards,
Kathleen
=C2=A0
Thanks,
Acee

=C2=A0 =C2=A0 Thank you,
=C2=A0 =C2=A0 Kathleen





--

Best regards,
Kathleen
--0000000000009d067a0590a09175-- From nobody Wed Aug 21 08:01:48 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF62120A0A; Tue, 20 Aug 2019 11:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1566324789; bh=2mlx5XRBIhcsiCVkYyME8f3R8at6iSANy5GacduTync=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=sCsNKq4BywVLsc04WRQH0g3PEmFLaPEH+n3pMSGEPIwA4vir0VkhqteKZPke7bZTz 5a/8TOS3sEAprApMUk+bExW6ACtPuzBf/tobWZYWVP84vZ0GKJ6dlhhNlHIL6G7w0t fHVNA/taBe2AfONfXnmwyC/zZouQ05XpNLLO63RI= X-Mailbox-Line: From new-work-bounces@ietf.org Tue Aug 20 11:13:04 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 396F61209FF; Tue, 20 Aug 2019 11:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1566324781; bh=2mlx5XRBIhcsiCVkYyME8f3R8at6iSANy5GacduTync=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=uO3e4Jpu98ev89E+Gcn22mWGHmVPYd1pQ3SEDWPrIVWd0Kri12b3DdaRe8DS1GQdg 3t1nVS3lUqgqjQ4MbUPR6YxklOI8/bPCdJIMG+8smjYeLqbX8jF2WvSMIKm2hO6xEY pA8lqnbC57XPgLETTSYDA0SoyCmQbwHGUFQN5DoE= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 171501209C9 for ; Tue, 20 Aug 2019 11:12:53 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: MIME-Version: 1.0 Message-ID: <156632477308.366.13779720218977870860.idtracker@ietfa.amsl.com> Date: Tue, 20 Aug 2019 11:12:53 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 21 Aug 2019 08:01:47 -0700 Subject: [secdir] [new-work] WG Review: Autonomic Networking Integrated Model and Approach (anima) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 18:13:15 -0000 The Autonomic Networking Integrated Model and Approach (anima) WG in the Operations and Management Area of the IETF is undergoing rechartering. The IESG has not made any determination 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 2019-08-30. Autonomic Networking Integrated Model and Approach (anima) ----------------------------------------------------------------------- Current status: Active WG Chairs: Toerless Eckert Sheng Jiang Assigned Area Director: Ignas Bagdonas Operations and Management Area Directors: Warren Kumari Ignas Bagdonas Technical advisors: Nancy Cam-Winget Mailing list: Address: anima@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/anima Archive: https://mailarchive.ietf.org/arch/browse/anima/ Group page: https://datatracker.ietf.org/group/anima/ Charter: https://datatracker.ietf.org/doc/charter-ietf-anima/ The Autonomic Networking Integrated Model and Approach (ANIMA) working group develops and maintains specifications and documentation for interoperable protocols and procedures for automated network management and control of professionally-managed networks. The vision is a network that configures, heals, optimizes and protects itself. The strategy is the incremental introduction of components to smoothly evolve existing and new networks accordingly. ANIMA work will rely on the framework described in draft-ietf-anima-reference-model already approved for publication. Work not related to this framework is welcome for review, but WG adoption of such work requires explicit rechartering. The two concrete areas of the reference model are (1) the Autonomic Networking Infrastructure (ANI), and (2) Autonomic Functions (AF) built from software modules called Autonomic Service Agents (ASA). The ANI is specified through prior ANIMA work. It is composed of the Autonomic Control Plane (ACP; RFC 8368), Bootstrap over Secure Key Infrastructures (BRSKI) including Vouchers (RFC8366), and the Generic Autonomic Signaling Protocol (GRASP). ANIMA will work on closing gaps and extending the ANI and its components. ANIMA will start to define Autonomic Functions (AF) to enable service automation in networks; it will also work on generic aspects of ASA including design guidelines and lifecycle management, coordination and dependency management. The reference model also discusses Intent, but ANIMA will not work on this without explicit rechartering. It will rely on the Network Management Research Group (NMRG) to define the next steps for this topic. ANIMA will coordinate with other IETF and IRTF groups as needed. The scope of possible work items are (additional works are subject to extra approval from the responsible AD): - Extensions to the ANI, including variations of ANI deployment (e.g. in virtualised environments), information distribution within an AN, ANI OAMP interfaces (Operations, Administration, Management, Provisioning), interaction with YANG-based mechanisms, defining the domain boundary and membership management of the domain. - Support for Autonomic Service Agents, including design and implementation guidelines for ASAs, life cycle management, authorization and coordination of ASA. - BRSKI features, including proxies, enrollment, adaptions over various network protocols, variations of voucher formats. - Generic use cases of Autonomic Network and new GRASP extensions/options for them, including bulk transfer, DNS-SD interworking, autonomic resource management, autonomic SLA assurance, autonomic multi-tenant management, autonomic network measurement. - Integration with Network Operations Centers (NOCs), including autonomic discovery/connectivity to NOC, YANG-based ANI/ASA management by the NOC and reporting AF from node to NOC. Milestones: Nov 2019 - Submit Information distribution over GRASP to the IESG Dec 2019 - Submit Constrained Voucher Artifacts for Bootstrapping Protocols to the IESG Dec 2019 - Submit Constrained Join Proxy for Bootstrapping Protocols to the IESG Mar 2020 - Submit Lifecycle and Management of Autonomic Service Agents to the IESG Mar 2020 - Submit Guidelines for Developing Autonomic Service Agents to the IESG Jul 2020 - Recharter or close the WG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Wed Aug 21 08:35:40 2019 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 3154B120074; Wed, 21 Aug 2019 08:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=UmrvyD0M; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kxywuPeQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fk0M1aoNHUkU; Wed, 21 Aug 2019 08:35:22 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C931912000F; Wed, 21 Aug 2019 08:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4250; q=dns/txt; s=iport; t=1566401721; x=1567611321; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mWdK3GGQkVeOi13c9e1Rxqd3nubnx2dwMVh/Ev5xd7A=; b=UmrvyD0MnzkIZiw5PCRcCl1ouPyBSiPmlLM0y8IRoAd6hwgderO/wHs6 WOK36OXKp1z2XHww9e2KfhYs1DXkh9JpuZaMVxLaHhjrXEK/t1W+MkV/P gNpurnzU8grq+xnG3JL09hKp47c0XK/kUaPafo2Oqm02Aiq6MUxxD5xv+ A=; IronPort-PHdr: =?us-ascii?q?9a23=3AsxdlYBB7mKRI6u/f8KutUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qg83kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuIPL3bCEhNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAAC1Y11d/49dJa1bCRsBAQEBAwE?= =?us-ascii?q?BAQcDAQEBgVQFAQEBCwGBRFADgUIgBAsqCoQVg0cDimeCNyWXZYEugSQDVAk?= =?us-ascii?q?BAQEMAQEtAgEBhD8CF4JFIzUIDgIFAQEEAQEBAgEGBG2FJwyFSgEBAQECARI?= =?us-ascii?q?REQwBATcBBAsCAQYCDgoCAiYCAgIwFRACBA4FIoMAgWsDDg8BAo8BkGECgTi?= =?us-ascii?q?IYXOBMoJ7AQEFhRQYghYJgQwoAYpCgSsYgUA/gREnDBOCTD6EGiqDCzKCJo8?= =?us-ascii?q?XhTKXEAkCgh2QRIN1G4IxhzCOZaVpAgQCBAUCDgEBBYFRATaBWHAVGksBgkG?= =?us-ascii?q?CQoNyilNygSmKfAGBIAEB?= X-IronPort-AV: E=Sophos;i="5.64,412,1559520000"; d="scan'208";a="613812254" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Aug 2019 15:35:20 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x7LFZK6i030816 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Aug 2019 15:35:20 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 21 Aug 2019 10:35:20 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 21 Aug 2019 11:35:19 -0400 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 21 Aug 2019 10:35:19 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LqgmiWG7iC2Y2aZpDuQ+FwuAPz/RNGObnIVlmYrskR3kNI5pO4NbMzhicMHOLURWMSM/7mcnfsFh0XPHyl7yUJ1eIm2mTdv/LCRwxaymlYsMVMvdfYrZAGbKBnpxKf06XIrF6laGryorY6ETnmseo3RUiEvm0am6RbLNv64nLRnAz6SmCaeqIe4qJc8MgizyUMugtCthYptBEDwCGd5ardjiN3ejbPdtft/9syxgrGhZB/OimiaLjuJT5kK1Tay3ag/0f+yw1asvPMa0Xg0Kt6khz1gq2WdBKOQcujga+A+rjTpLGtrRt0moNODvW57SB7UOWdsICwgpxqFXjvAU9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mWdK3GGQkVeOi13c9e1Rxqd3nubnx2dwMVh/Ev5xd7A=; b=AYZd5x0Kk//WozP9qeLkLDJ+yLF2OS8ty4ruLz9QbZW8Ov5lU5MnnpoEymbmzIURc2nvh5kVkVe/a+zbVBCaQxR/cFAZsupI7py8mgAsBhrXSQsJ3Rt1GP7vScBcmYbbgB+SnExJbrsu2FGekRzmOt9L4Aw0fw9b7x8N2Z4xCdPVGcwrwcufSt0SvcrYB3q9KLr4dMvOT7aN3aNCtwg+FCBhgWo3CM+CK3cvo5bAqr4G9/jMrCn0Vwz3Q2au2i2zit7qp+KqU7gd1dSc3tn8SmVuvLKuiT4eH0EQ5fwAWctlp87iAc4dRMZF8rGwc41SW2FOQvvzywRUTAjMQzG7Iw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mWdK3GGQkVeOi13c9e1Rxqd3nubnx2dwMVh/Ev5xd7A=; b=kxywuPeQ3UO2NQTwAdaS44vC6ZIvZcVEVj/3dfUeoRPGhqhRI9rLwF0Y5exFjU+Fspb/bpEMVLr9D7jDNjeQANIXi+5CqhSDU2Ab9Z985JHgM/NShEe83WZV3AJpPVzzerjy6zntYov7s5c53H0Dj1tcY4GO7x3ZCECCQsuljXw= Received: from DM6PR11MB3516.namprd11.prod.outlook.com (20.177.220.141) by DM6PR11MB4492.namprd11.prod.outlook.com (52.132.251.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.13; Wed, 21 Aug 2019 15:35:16 +0000 Received: from DM6PR11MB3516.namprd11.prod.outlook.com ([fe80::94bf:39d4:29cb:42d1]) by DM6PR11MB3516.namprd11.prod.outlook.com ([fe80::94bf:39d4:29cb:42d1%5]) with mapi id 15.20.2178.020; Wed, 21 Aug 2019 15:35:16 +0000 From: "Darren Dukes (ddukes)" To: Liang Xia CC: "secdir@ietf.org" , "draft-ietf-6man-segment-routing-header.all@ietf.org" , "ipv6@ietf.org" , "ietf@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-6man-segment-routing-header-22 Thread-Index: AQHVUxspvqTpv8U/cUmc6z0cPvC7r6cFxdkA Date: Wed, 21 Aug 2019 15:35:16 +0000 Message-ID: <4074EC87-36AB-4521-A415-DCDC621C4129@cisco.com> References: <156584039497.2287.2516898029582755543@ietfa.amsl.com> In-Reply-To: <156584039497.2287.2516898029582755543@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ddukes@cisco.com; x-originating-ip: [161.44.212.218] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 33420f7f-dda2-4084-2759-08d7264d2ad7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR11MB4492; x-ms-traffictypediagnostic: DM6PR11MB4492: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(39860400002)(396003)(376002)(136003)(189003)(199004)(14444005)(6486002)(6246003)(53546011)(81156014)(71200400001)(4326008)(36756003)(26005)(66446008)(54906003)(5660300002)(316002)(64756008)(14454004)(3846002)(6512007)(8936002)(6116002)(486006)(6506007)(66066001)(25786009)(81166006)(446003)(91956017)(33656002)(99286004)(7736002)(476003)(102836004)(66946007)(76116006)(8676002)(6436002)(71190400001)(66556008)(2616005)(478600001)(186003)(66476007)(256004)(53936002)(11346002)(6916009)(2906002)(86362001)(229853002)(76176011)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB4492; H:DM6PR11MB3516.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: N93Tbs355fbk25qvAJiQJ/X+gZ7bq7IfzkvgH+amMD6+rbViCW8t/6MUeUpglSPEIUrSWSMuoVpxH3UJd/CU+eAKY5uHHq6gPAWjyG7iK0de0xR56WXXQVzwGuM9uu+Otr5mcqj+DMPMkmF6MrtBft6SFJGTPJGVKktHD4R1KH6cNc3hdhLJ6VSHZSLANrZX01XX2MQCfuLbd7a0v/fjQpLJ2bdNSOa/qQar9wTezsrSGONorM3OFErwtumPo/V7retznTkoMlGdgqSL96FJ/qZVvatAN4LRJzn8u9pYzTGbzmvM+VbXirWY76ag/dgKl2QoZw7rZx+p3TIVu84vc/scE2OXBII0VIfR9PaFVlczP8Yn4nuR86mryWZJBTICRZpXVkVhXd8KKPiNBohP8iSSgubb0pySkKDn1eesY6I= Content-Type: text/plain; charset="utf-8" Content-ID: <5E90721CA2841E4EBF95A894C17995A7@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 33420f7f-dda2-4084-2759-08d7264d2ad7 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 15:35:16.8095 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jzsF0YWpepvTxotnSZGhuyG4i+feBxsHO2uREIqbSEZ8kjnowylxWrKtVlao7uMyh9JkDQCJIZGBQUTObe/lXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4492 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-6man-segment-routing-header-22 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 15:35:25 -0000 VGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiAgUGxlYXNlIHNlZSBpbmxpbmUuDQoNCj4gT24gQXVn IDE0LCAyMDE5LCBhdCAxMTozOSBQTSwgTGlhbmcgWGlhIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBs eUBpZXRmLm9yZz4gd3JvdGU6DQo+IA0KPiBSZXZpZXdlcjogTGlhbmcgWGlhDQo+IFJldmlldyBy ZXN1bHQ6IEhhcyBJc3N1ZXMNCj4gDQo+IFNvbWUgbml0czoNCj4gMS4gdGl0bGUgb2YgU2VjdGlv biA0LjMuMjogL0ZJQiBFbnRyeSBpcyBhIExvY2FsIEludGVyZmFjZS9GSUIgRW50cnkgSXMgQSBM b2NhbA0KPiBJbnRlcmZhY2UNCk9LDQoNCj4gMi4gdGl0bGUgb2YgU2VjdGlvbiA1LjI6IC9TUiBE b21haW4gYXMgYSBzaW5nbGUgc3lzdGVtIHdpdGgNCj4gZGVsZWdhdGlvbiBhbW9uZyBjb21wb25l bnRzL1NSIERvbWFpbiBhcyBBIFNpbmdsZSBTeXN0ZW0gd2l0aCBEZWxlZ2F0aW9uIGFtb25nDQo+ IENvbXBvbmVudHMgDQoNCk9LDQoNCg0KPiAzLiBTZWN0aW9uIDIuMS4xOiAvVGhlcmUgYXJlIHR3 byB0eXBlcyBvZiBwYWRkaW5nIFRMVnMsIHBhZDEgYW5kDQo+IHBhZE4sIHRoZSBmb2xsb3dpbmcg YXBwbGllcyB0byBib3RoL1RoZXJlIGFyZSB0d28gdHlwZXMgb2YgUGFkZGluZyBUTFZzLCBwYWQx DQo+IGFuZCBwYWROLCB0aGUgZm9sbG93aW5nIGFwcGxpZXMgdG8gYm90aCANCg0KQWNrLCB3ZeKA mWxsIHVzZSBQYWRkaW5nIFRMViBjYXBpdGFsaXplZCBhcyBhIG5hbWUuDQoNCj4gNC4gU2VjdGlv biAyLjEuMjogIkFsaWdubWVudA0KPiByZXF1aXJlbWVudDogOG4iLiBXaGF0IGlzIDhuPyBGb3Ig YmV0dGVyIHJlYWRhYmlsaXR5LCBjYW4geW91IGdpdmUgYSBtb3JlIGNsZWFyDQo+IGNsYXJpZmlj YXRpb24gdGV4dD8gDQoNClNlY3Rpb24gMi4xIGRlc2NyaWJlcyB3aGF0IGFuIGFsaWdubWVudCBy ZXF1aXJlbWVudCBpcyBhbmQgaG93IGl0IGlzIGRvY3VtZW50ZWQsIHJlZmVyZW5jaW5nIFJGQzgy MDAuDQoNCiJBbGwgVExWcyBzcGVjaWZ5IHRoZWlyIGFsaWdubWVudCByZXF1aXJlbWVudHMgdXNp bmcgYW4geG4reSBmb3JtYXQuDQogICBUaGUgeG4reSBmb3JtYXQgaXMgZGVmaW5lZCBhcyBwZXIg W1JGQzgyMDBdLiAgVGhlIFNSIFNvdXJjZSBub2RlcyB1c2UNCiAgIHRoZSB4bit5IGFsaWdubWVu dCByZXF1aXJlbWVudHMgb2YgVExWcyBhbmQgcGFkZGluZyBUTFZzIHdoZW4NCiAgIGNvbnN0cnVj dGluZyBhbiBTUkgu4oCdDQoNCkRvZXMgdGhpcyBhZGRyZXNzIHlvdXIgY29uY2Vybj8NCg0KPiA1 LiBTZWN0aW9uIDQuMTogL0hNQUMgVExWIG1heSBiZSBzZXQgYWNjb3JkaW5nIHRvIFNlY3Rpb24N Cj4gNy4vSE1BQyBUTFYgbWF5IGJlIHNldCBhY2NvcmRpbmcgdG8gU2VjdGlvbiAyLjEuMi4vPyAN Cg0KVGhhbmtzLCBJ4oCZdmUgZml4ZWQgdGhlIFhNTCB4cmVmIGZvciB0aGUgbmV4dCByZXZpc2lv bi4NCg0KPiA2LiBTZWN0aW9uIDQuMzogaGF2ZSBhICIqIg0KPiBiZWZvcmUgZXZlcnkgaXRlbSBv ZiAiQSBGSUIgZW50cnnigKbigJ0NCj4gPw0KPiANCg0KU3VyZSwgSSBleHBlY3QgdGhhdCB3b3Vs ZCBtYWtlIGl0IG1vcmUgb2J2aW91cyB0aGV5IGFyZSBpbmRpdmlkdWFsIGxpbmUgaXRlbXMuDQoN Cj4gMSBpc3N1ZToNCj4gVGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIFNlY3Rpb24gbWFpbmx5 IGNsYXJpZmllcyB0aGUgc2VjdXJpdHkgcHJvdGVjdGlvbg0KPiBiYXNlZCBvbiB0aGUgc3RyaWN0 IFNSIERvbWFpbiBib3VuZGFyeSBwcm90ZWN0aW9uIHBhcmFkaWdtLCBhbmQgdGhlDQo+IGNvbnNp ZGVyYXRpb25zIG9mIHNvbWUgaWRlbnRpZmllZCBhdHRhY2tzLiBUaGV5IGFyZSB2YWx1YWJsZSwg YnV0IG1heWJlIG5vdA0KPiBjb21wbGV0ZSBpbiBzY29wZS4gSSBub3RpY2VkIDIgU1IgcmVsYXRl ZCBzZWN1cml0eSBjb25zaWRlcmF0aW9uIGRyYWZ0cw0KPiAoZHJhZnQtcGVya2lucy1zci1zZWN1 cml0eS0wMCBhbmQNCj4gZHJhZnQtbGktc3ByaW5nLXNydjYtc2VjdXJpdHktY29uc2lkZXJhdGlv bi0wMCksIHdoaWNoIGFyZSB0cnlpbmcgdG8gc3VtbWFyaXplDQo+IGFsbCB0aGUgcG9zc2libGUg dnVsbmVyYWJpbGl0aWVzIGluIFNSIG5ldHdvcmsuIEkgcGVyc29uYWxseSBzdWdnZXN0cyB0aGUN Cj4gYXV0aG9ycyB0byByZXZpZXcgdGhlbSBhbmQgY29uc2lkZXIgaG93IHRvIHJlZmVyZW5jZSBv ciBpbmNvcnBvcmF0ZSB0aGUNCj4gdmFsdWFibGUgY29uc2lkZXJhdGlvbnMgZnJvbSB0aGVtLg0K DQpUaGFuayB5b3UgZm9yIHRoaXMgc3VnZ2VzdGlvbiwgSeKAmXZlIGFuYWx5emVkIGJvdGggdGhl IHJlZmVyZW5jZWQgZG9jdW1lbnRzOg0KDQpkcmFmdC1saS1zcHJpbmctc3J2Ni1zZWN1cml0eS1j b25zaWRlcmF0aW9uLTAxIGNvbmNsdWRlcyB0aGF0IHRoZXJlIGlzIG5vIHBhY2tldCBmYWxzaWZp Y2F0aW9uLCBpZGVudGl0eSBzcG9vZmluZywgcGFja2V0IHJlcGxheSwgRE9TL0RET1MgdGhyZWF0 IHdpdGhpbiBhbiBTUiBEb21haW4uDQpJdCBkZWZpbmVzIGEgc2VjdXJpdHkgZGVzaWduIGZvbGxv d2luZyB0aGF0IGRvY3VtZW50ZWQgaW4gZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1o ZWFkZXItMjIuICBJIHNlZSBub3RoaW5nIHRvIGFkZCBmcm9tIHRoaXMgZHJhZnQuDQoNCmRyYWZ0 LXBlcmtpbnMtc3Itc2VjdXJpdHktMDAgZGlzY3Vzc2VzIGEgc2V0IG9mIGRlcGxveW1lbnQgc2Nl bmFyaW9zLCBhbmQgU0lEcyB0aGF0IGFyZSBub3QgZG9jdW1lbnRlZCBpbiBkcmFmdC1pZXRmLTZt YW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlci0yMiwgYW5kIGFyZSB0aGVyZWZvcmUgb3V0IG9mIHNj b3BlIGZvciBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciB0byBjb25zaWRl ci4NCg0KSG93ZXZlciB0aGUgZGlzY3Vzc2lvbnMgc3RhcnRlZCB3aXRoIGRyYWZ0LXBlcmtpbnMt c3Itc2VjdXJpdHktMDAgc2hvdWxkIGNvbnRpbnVlIGluIHRoZSBjb250ZXh0IG9mIHRoZSBTUFJJ TkcgV0csIGFzIHBlciBpdHMgY2hhcnRlciwgZm9yIHRoZSB0ZWNobm9sb2dpZXMgYW5kIGRvY3Vt ZW50cyBpdCBwcm9kdWNlcyB1c2luZyB0aGUgU1JILg0KDQpXb3VsZCB0aGlzIGFkZHJlc3MgeW91 ciBjb25jZXJuPw0KDQpEYXJyZW4NCg0KDQo= From nobody Thu Aug 22 07:04:37 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73ADB120013 for ; Thu, 22 Aug 2019 07:04:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <156648267647.14765.2520566347251714090.idtracker@ietfa.amsl.com> Date: Thu, 22 Aug 2019 07:04:36 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 14:04:36 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-08-22 Reviewer LC end Draft Derek Atkins 2019-08-15 draft-ietf-opsec-urpf-improvements-03 For telechat 2019-09-05 Reviewer LC end Draft Christian Huitema 2019-09-02 draft-ietf-core-senml-etch-05 Last calls: Reviewer LC end Draft Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-31 Roman Danyliw 2019-06-04 draft-ietf-rtgwg-enterprise-pa-multihoming-12 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Linda Dunbar 2019-08-28 draft-ietf-cdni-request-routing-extensions-05 Donald Eastlake 2019-08-28 draft-ietf-pce-stateful-path-protection-08 Stephen Farrell 2019-08-28 draft-ietf-pce-stateful-hpce-11 Daniel Franke 2019-08-28 draft-ietf-pce-stateful-pce-auto-bandwidth-10 Daniel Gillmor 2019-08-27 draft-ietf-lsr-isis-rfc5306bis-05 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Tobias Gondrom 2019-08-26 draft-ietf-curdle-ssh-curves-09 Steve Hanna 2019-09-05 draft-ietf-cbor-array-tags-07 Dan Harkins 2019-09-03 draft-ietf-pim-reserved-bits-03 Russ Housley 2019-09-03 draft-ietf-ippm-stamp-07 Leif Johansson 2019-09-02 draft-ietf-tls-sni-encryption-05 Charlie Kaufman 2019-09-02 draft-ietf-ecrit-data-only-ea-18 Aanchal Malhotra 2019-06-26 draft-ietf-ipwave-ipv6-over-80211ocb-52 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-17 Magnus Nystrom 2019-06-20 draft-ietf-mmusic-ice-sip-sdp-39 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Tim Polk 2019-08-01 draft-ietf-acme-star-07 David Waltermire 2019-08-07 draft-ietf-oauth-jwt-introspection-response-05 Brian Weis 2019-08-05 draft-ietf-oauth-resource-indicators-05 Christopher Wood 2019-08-30 draft-klensin-idna-unicode-review-02 Paul Wouters 2019-08-30 draft-klensin-idna-rfc5891bis-04 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-12 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Next in the reviewer rotation: Scott Kelly Stephen Kent Tero Kivinen Watson Ladd Ben Laurie Barry Leiba Chris Lonvick Aanchal Malhotra David Mandelberg Catherine Meadows From nobody Thu Aug 22 10:17:52 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE943120905; Thu, 22 Aug 2019 10:17:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley via Datatracker To: Cc: draft-ietf-ippm-stamp.all@ietf.org, ietf@ietf.org, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Russ Housley Message-ID: <156649425577.14757.13703548347532993926@ietfa.amsl.com> Date: Thu, 22 Aug 2019 10:17:35 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ippm-stamp-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 17:17:36 -0000 Reviewer: Russ Housley Review result: Has Issues 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 authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-ippm-stamp-07 Reviewer: Russ Housley Review Date: 2019-08-22 IETF LC End Date: 2019-09-03 IESG Telechat date: unknown Summary: Has Issues Major Concerns: Section 4.1.1: This paragraph is a bit surprising: The STAMP Session-Sender and Session-Reflector MAY use, not use, or set value of the Z field in accordance with the timestamp format in use. This optional field is to enhance operations, but local configuration or defaults could be used in its place. Why not have this bit set to align with the bits that actually appear in the packet? This is especially worrisome because of the text that come later (Section 4.2.1), which says: o Timestamp and Receiver Timestamp fields are each eight octets long. The format of these fields, NTP or PTPv2, indicated by the Z flag of the Error Estimate field as described in Section 4.1. If the Z field (or Z flag) is not really meaningful, I do not see how the peer knows how to interpret a received timestamp. Section 4.3: Please divide this into two sections. First, you have picked a single mechanism for authentication (HMAC-SHA-256 truncated to 128 bits). This choice seems fine to me, even though you are not saying much about the key management. I would prefer that you have a mandatory to implement key management technique, but allow others; however, I am not going to insist on that. Then, a separate section should talk about confidentiality protection. Section 4.3: This text needs work: If confidentiality protection for STAMP is required, encryption at the higher level MUST be used. For example, STAMP packets could be transmitted in the dedicated IPsec tunnel or share the IPsec tunnel with the monitored flow. I find "at the higher level" very unclear. I believe that IPsec would be below this protocol. I think that DTLS would also provide the confidentiality protection that you desire. Since you are not specifying any details of the encryption, you can say that a "secured transport" (the term that you use in the Security Considerations) such as IPsec or DTLS can be used. Minor Concerns: Section 1: I do not follow this topic, and this may be clear to your expected reader, but it is not clear to me. The Introduction does not tell me the relationship of TWAMP Light and [BBF.TR-390] to this document. One possible way to resolve this is to divide the section into four parts: (1) background and history of measurement protocols; (2) shortcoming of those protocols; (3) what this document does to resolve those shortcomings; and (4) pointers to other documents that make up the rest of the shortcoming resolution. Nits: The document uses "Z field" and "Z flag". Please pick one and use it throughout the document. These terms are defined in Section 2.1, but they are not used in the rest of the document: AES Advanced Encryption Standard CBC Cipher Block Chaining ECB Electronic Cookbook KEK Key-encryption Key From nobody Thu Aug 22 18:06:37 2019 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 4BE0B120271; Thu, 22 Aug 2019 18:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXLJUe_L1EKZ; Thu, 22 Aug 2019 18:06:21 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658B5120168; Thu, 22 Aug 2019 18:06:21 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 3D39039084C2D4F3F2D9; Fri, 23 Aug 2019 02:06:19 +0100 (IST) Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 23 Aug 2019 02:06:19 +0100 Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 23 Aug 2019 02:06:18 +0100 Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Fri, 23 Aug 2019 02:06:18 +0100 Received: from DGGEMM511-MBX.china.huawei.com ([169.254.1.72]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0439.000; Fri, 23 Aug 2019 09:06:14 +0800 From: "Xialiang (Frank, Network Standard & Patent Dept)" To: "Darren Dukes (ddukes)" CC: "secdir@ietf.org" , "draft-ietf-6man-segment-routing-header.all@ietf.org" , "ipv6@ietf.org" , "ietf@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-6man-segment-routing-header-22 Thread-Index: AQHVWDYYmP3iNe23R0OgF245icsplqcH7Spg Date: Fri, 23 Aug 2019 01:06:13 +0000 Message-ID: References: <156584039497.2287.2516898029582755543@ietfa.amsl.com> <4074EC87-36AB-4521-A415-DCDC621C4129@cisco.com> In-Reply-To: <4074EC87-36AB-4521-A415-DCDC621C4129@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.159.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [secdir] =?utf-8?b?562U5aSNOiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBv?= =?utf-8?q?f_draft-ietf-6man-segment-routing-header-22?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 01:06:24 -0000 SGkgRGFycmVuLA0KVGhhbmtzIGZvciB0aGUgcmVzcG9uc2UuDQpObyBtb3JlIGlzc3VlcyBmcm9t IG15IHNpZGUuDQoNCkIuUi4NCkZyYW5rDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7 tuS6ujogRGFycmVuIER1a2VzIChkZHVrZXMpIFttYWlsdG86ZGR1a2VzQGNpc2NvLmNvbV0gDQrl j5HpgIHml7bpl7Q6IDIwMTnlubQ45pyIMjHml6UgMjM6MzUNCuaUtuS7tuS6ujogWGlhbGlhbmcg KEZyYW5rLCBOZXR3b3JrIFN0YW5kYXJkICYgUGF0ZW50IERlcHQpIDxmcmFuay54aWFsaWFuZ0Bo dWF3ZWkuY29tPg0K5oqE6YCBOiBzZWNkaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtNm1hbi1zZWdt ZW50LXJvdXRpbmctaGVhZGVyLmFsbEBpZXRmLm9yZzsgaXB2NkBpZXRmLm9yZzsgaWV0ZkBpZXRm Lm9yZw0K5Li76aKYOiBSZTogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi02 bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXItMjINCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3 LiAgUGxlYXNlIHNlZSBpbmxpbmUuDQoNCj4gT24gQXVnIDE0LCAyMDE5LCBhdCAxMTozOSBQTSwg TGlhbmcgWGlhIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6DQo+IA0K PiBSZXZpZXdlcjogTGlhbmcgWGlhDQo+IFJldmlldyByZXN1bHQ6IEhhcyBJc3N1ZXMNCj4gDQo+ IFNvbWUgbml0czoNCj4gMS4gdGl0bGUgb2YgU2VjdGlvbiA0LjMuMjogL0ZJQiBFbnRyeSBpcyBh IExvY2FsIEludGVyZmFjZS9GSUIgRW50cnkgDQo+IElzIEEgTG9jYWwgSW50ZXJmYWNlDQpPSw0K DQo+IDIuIHRpdGxlIG9mIFNlY3Rpb24gNS4yOiAvU1IgRG9tYWluIGFzIGEgc2luZ2xlIHN5c3Rl bSB3aXRoIGRlbGVnYXRpb24gDQo+IGFtb25nIGNvbXBvbmVudHMvU1IgRG9tYWluIGFzIEEgU2lu Z2xlIFN5c3RlbSB3aXRoIERlbGVnYXRpb24gYW1vbmcgDQo+IENvbXBvbmVudHMNCg0KT0sNCg0K DQo+IDMuIFNlY3Rpb24gMi4xLjE6IC9UaGVyZSBhcmUgdHdvIHR5cGVzIG9mIHBhZGRpbmcgVExW cywgcGFkMSBhbmQgcGFkTiwgDQo+IHRoZSBmb2xsb3dpbmcgYXBwbGllcyB0byBib3RoL1RoZXJl IGFyZSB0d28gdHlwZXMgb2YgUGFkZGluZyBUTFZzLCANCj4gcGFkMSBhbmQgcGFkTiwgdGhlIGZv bGxvd2luZyBhcHBsaWVzIHRvIGJvdGgNCg0KQWNrLCB3ZeKAmWxsIHVzZSBQYWRkaW5nIFRMViBj YXBpdGFsaXplZCBhcyBhIG5hbWUuDQoNCj4gNC4gU2VjdGlvbiAyLjEuMjogIkFsaWdubWVudA0K PiByZXF1aXJlbWVudDogOG4iLiBXaGF0IGlzIDhuPyBGb3IgYmV0dGVyIHJlYWRhYmlsaXR5LCBj YW4geW91IGdpdmUgYSANCj4gbW9yZSBjbGVhciBjbGFyaWZpY2F0aW9uIHRleHQ/DQoNClNlY3Rp b24gMi4xIGRlc2NyaWJlcyB3aGF0IGFuIGFsaWdubWVudCByZXF1aXJlbWVudCBpcyBhbmQgaG93 IGl0IGlzIGRvY3VtZW50ZWQsIHJlZmVyZW5jaW5nIFJGQzgyMDAuDQoNCiJBbGwgVExWcyBzcGVj aWZ5IHRoZWlyIGFsaWdubWVudCByZXF1aXJlbWVudHMgdXNpbmcgYW4geG4reSBmb3JtYXQuDQog ICBUaGUgeG4reSBmb3JtYXQgaXMgZGVmaW5lZCBhcyBwZXIgW1JGQzgyMDBdLiAgVGhlIFNSIFNv dXJjZSBub2RlcyB1c2UNCiAgIHRoZSB4bit5IGFsaWdubWVudCByZXF1aXJlbWVudHMgb2YgVExW cyBhbmQgcGFkZGluZyBUTFZzIHdoZW4NCiAgIGNvbnN0cnVjdGluZyBhbiBTUkgu4oCdDQoNCkRv ZXMgdGhpcyBhZGRyZXNzIHlvdXIgY29uY2Vybj8NCg0KPiA1LiBTZWN0aW9uIDQuMTogL0hNQUMg VExWIG1heSBiZSBzZXQgYWNjb3JkaW5nIHRvIFNlY3Rpb24gNy4vSE1BQyBUTFYgDQo+IG1heSBi ZSBzZXQgYWNjb3JkaW5nIHRvIFNlY3Rpb24gMi4xLjIuLz8NCg0KVGhhbmtzLCBJ4oCZdmUgZml4 ZWQgdGhlIFhNTCB4cmVmIGZvciB0aGUgbmV4dCByZXZpc2lvbi4NCg0KPiA2LiBTZWN0aW9uIDQu MzogaGF2ZSBhICIqIg0KPiBiZWZvcmUgZXZlcnkgaXRlbSBvZiAiQSBGSUIgZW50cnnigKbigJ0N Cj4gPw0KPiANCg0KU3VyZSwgSSBleHBlY3QgdGhhdCB3b3VsZCBtYWtlIGl0IG1vcmUgb2J2aW91 cyB0aGV5IGFyZSBpbmRpdmlkdWFsIGxpbmUgaXRlbXMuDQoNCj4gMSBpc3N1ZToNCj4gVGhlIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zIFNlY3Rpb24gbWFpbmx5IGNsYXJpZmllcyB0aGUgc2VjdXJp dHkgDQo+IHByb3RlY3Rpb24gYmFzZWQgb24gdGhlIHN0cmljdCBTUiBEb21haW4gYm91bmRhcnkg cHJvdGVjdGlvbiBwYXJhZGlnbSwgDQo+IGFuZCB0aGUgY29uc2lkZXJhdGlvbnMgb2Ygc29tZSBp ZGVudGlmaWVkIGF0dGFja3MuIFRoZXkgYXJlIHZhbHVhYmxlLCANCj4gYnV0IG1heWJlIG5vdCBj b21wbGV0ZSBpbiBzY29wZS4gSSBub3RpY2VkIDIgU1IgcmVsYXRlZCBzZWN1cml0eSANCj4gY29u c2lkZXJhdGlvbiBkcmFmdHMNCj4gKGRyYWZ0LXBlcmtpbnMtc3Itc2VjdXJpdHktMDAgYW5kDQo+ IGRyYWZ0LWxpLXNwcmluZy1zcnY2LXNlY3VyaXR5LWNvbnNpZGVyYXRpb24tMDApLCB3aGljaCBh cmUgdHJ5aW5nIHRvIA0KPiBzdW1tYXJpemUgYWxsIHRoZSBwb3NzaWJsZSB2dWxuZXJhYmlsaXRp ZXMgaW4gU1IgbmV0d29yay4gSSBwZXJzb25hbGx5IA0KPiBzdWdnZXN0cyB0aGUgYXV0aG9ycyB0 byByZXZpZXcgdGhlbSBhbmQgY29uc2lkZXIgaG93IHRvIHJlZmVyZW5jZSBvciANCj4gaW5jb3Jw b3JhdGUgdGhlIHZhbHVhYmxlIGNvbnNpZGVyYXRpb25zIGZyb20gdGhlbS4NCg0KVGhhbmsgeW91 IGZvciB0aGlzIHN1Z2dlc3Rpb24sIEnigJl2ZSBhbmFseXplZCBib3RoIHRoZSByZWZlcmVuY2Vk IGRvY3VtZW50czoNCg0KZHJhZnQtbGktc3ByaW5nLXNydjYtc2VjdXJpdHktY29uc2lkZXJhdGlv bi0wMSBjb25jbHVkZXMgdGhhdCB0aGVyZSBpcyBubyBwYWNrZXQgZmFsc2lmaWNhdGlvbiwgaWRl bnRpdHkgc3Bvb2ZpbmcsIHBhY2tldCByZXBsYXksIERPUy9ERE9TIHRocmVhdCB3aXRoaW4gYW4g U1IgRG9tYWluLg0KSXQgZGVmaW5lcyBhIHNlY3VyaXR5IGRlc2lnbiBmb2xsb3dpbmcgdGhhdCBk b2N1bWVudGVkIGluIGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyLTIyLiAg SSBzZWUgbm90aGluZyB0byBhZGQgZnJvbSB0aGlzIGRyYWZ0Lg0KDQpkcmFmdC1wZXJraW5zLXNy LXNlY3VyaXR5LTAwIGRpc2N1c3NlcyBhIHNldCBvZiBkZXBsb3ltZW50IHNjZW5hcmlvcywgYW5k IFNJRHMgdGhhdCBhcmUgbm90IGRvY3VtZW50ZWQgaW4gZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQt cm91dGluZy1oZWFkZXItMjIsIGFuZCBhcmUgdGhlcmVmb3JlIG91dCBvZiBzY29wZSBmb3IgZHJh ZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXIgdG8gY29uc2lkZXIuDQoNCkhvd2V2 ZXIgdGhlIGRpc2N1c3Npb25zIHN0YXJ0ZWQgd2l0aCBkcmFmdC1wZXJraW5zLXNyLXNlY3VyaXR5 LTAwIHNob3VsZCBjb250aW51ZSBpbiB0aGUgY29udGV4dCBvZiB0aGUgU1BSSU5HIFdHLCBhcyBw ZXIgaXRzIGNoYXJ0ZXIsIGZvciB0aGUgdGVjaG5vbG9naWVzIGFuZCBkb2N1bWVudHMgaXQgcHJv ZHVjZXMgdXNpbmcgdGhlIFNSSC4NCg0KV291bGQgdGhpcyBhZGRyZXNzIHlvdXIgY29uY2Vybj8N Cg0KRGFycmVuDQoNCg0K From nobody Sat Aug 24 12:53:26 2019 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 8661D12006E; Sat, 24 Aug 2019 12:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQcwreJL7d15; Sat, 24 Aug 2019 12:53:12 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-oln040092004034.outbound.protection.outlook.com [40.92.4.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26B24120020; Sat, 24 Aug 2019 12:53:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AhvknYUpM2mOlyhkg9aYde4+YCi+INBFbhmOpS7PU7GMpoemdVCly9uC2cBd/StXbA1CnGdBwFP7KfkcBil7CohUWFV2+GxTJ22ZiWO/6FzSAO8fElSVq1HocBAFUJ4Zr7vET+p/MHosORZGzowSSYy8qPLYEqBG/e2I3lBO5wg2RGHPf/iHD2+UxnSZQPzjRC0KXaxkEP+G4zSs377fS4Qe/VERa0bHaPOlembd5MJUSumcZZx0cvFHANTH9bV1e9V0lmuZUQpxYt+FQoe2O+TpNq8C8s/29hgQAg5nWvVlQeyXVgxcNcdH2AJRM61lAIZnllpQIEhw/Ao5jndqtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pnvLoIMZLD/NGH2q8pVVxPg1iux11ZMeEw6Sb8veD7Q=; b=RBNd0WrLcnsDcVyDJwa4UFlhRyoxGdSiRN8Z2MQgpJfrMrcgWHMyvW9lUC0lJzhtVxwap75mdWMb2fFmp5lA2sXwsXFoJEV9pr5OW/ywt7k9Aek1ZxMsGe7sVlD5wpMmXruu6eNFswpNP2L3HRFdw3fBTB400M1QmMv1/oDoPVHxdq0CZzUyX9p9dYEZ/RRpwpQVpmtHxkg3gUxPOSGmgFQ80wXqmatrXcKQ/7brVhtuOhIa87PG1MUOTwm6kdl6HlpF9dxM8QKkzsJ2xyhpfatCZ3UI6qeAzWiECCUcfpw2FEeRdd81fELnXKMm1/tICXfhhbYvqK2FZqY2/rFIAQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pnvLoIMZLD/NGH2q8pVVxPg1iux11ZMeEw6Sb8veD7Q=; b=KkcZkFAoqqhRNZ4P9PRs/b0n8wZYqUm2yxavHMflncLegO9NpJxkABZOCLYRIK8wd8YIuhyx8yrjvwfhAyigxbdydZWaCQmU7rfvAZH/tjKbTu0gC7UTbUAe1YirNUW58S1aNWFs+ByZ8bsUciqhJgI/MFjaiWjXNG7dKPfWlFnfckhJKp+2DDNBA8pXsk89t5v9ZO7pXteS5so/QtANxo0afbSIidOel4UWGLDwgtTkf2hn9aZjjsOTkaB2uGEnp1NEngAQ27op4dkZVwITaLb2s543OrZtSwr1tBxxZcWU6eaytXdvpyPZn477Y4OYG3k7ggYhsgU0v0HP/EVL8Q== Received: from SN1NAM02FT013.eop-nam02.prod.protection.outlook.com (10.152.72.56) by SN1NAM02HT059.eop-nam02.prod.protection.outlook.com (10.152.73.45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.13; Sat, 24 Aug 2019 19:53:11 +0000 Received: from MWHPR04MB0367.namprd04.prod.outlook.com (10.152.72.57) by SN1NAM02FT013.mail.protection.outlook.com (10.152.72.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.13 via Frontend Transport; Sat, 24 Aug 2019 19:53:10 +0000 Received: from MWHPR04MB0367.namprd04.prod.outlook.com ([fe80::647b:b636:342c:f0f5]) by MWHPR04MB0367.namprd04.prod.outlook.com ([fe80::647b:b636:342c:f0f5%2]) with mapi id 15.20.2178.020; Sat, 24 Aug 2019 19:53:10 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ecrit-data-only-ea.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-ecrit-data-only-ea-18 Thread-Index: AQHVWrVSYrXYcnS0SkGl7pu26H6ueQ== Date: Sat, 24 Aug 2019 19:53:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:1F1FED9EAFBA0D4184881D4ACE6AD383884967CEFDE737BBA1E7670C646DC028; UpperCasedChecksum:30B068DF2CCF5B9A043DAF63945B690001059E4739F467AEF8CA51728D220CA4; SizeAsReceived:6714; Count:40 x-tmn: [YdBoR6aQ3yP5WuHc5mzl14h77OcZUwaC] x-ms-publictraffictype: Email x-incomingheadercount: 40 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031323274)(2017031324274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:SN1NAM02HT059; x-ms-traffictypediagnostic: SN1NAM02HT059: x-microsoft-antispam-message-info: DlSZsmLs0WXTO0vMBSDSgsyZyR5UilZrvRvdkAOBlBbE716xAkLX40ApgSMKXkuV8iqcqbuYRHhU6n46eNWKgXNWEBgnpUAP//zME5W96sxVDgPRsXER9M8s1FonEc3cazWT4CjHEsh/cwK7NQQ0bcPP3Cd2zpA9hanP5WMPifHJgYsLUSaYqDUwwvQB2Grk x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR04MB0367DA96CF172D996CDDA622DFA70MWHPR04MB0367namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 12ed7498-8e5b-43f5-2095-08d728ccb0fa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2019 19:53:10.2366 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT059 Archived-At: Subject: [secdir] Secdir review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 19:53:15 -0000 --_000_MWHPR04MB0367DA96CF172D996CDDA622DFA70MWHPR04MB0367namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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. This document defines a new MIME type: 'application/EmergencyCallData.cap+x= ml' for use primarily by sensors to send alert messages to emergency servic= es providers. It also defines a new Emergency Call Data Type: 'cap' in orde= r to embed this data efficiently in a SIP transaction. I saw no new securit= y issues beyond those already noted for the protocols carrying these messag= es. I do have some editorial suggestions: There is a lot of context that the authors assumed any reader would have th= at could have been stated in the introduction. I believe from context that = the purpose of this new MIME type is to support simple (IoT) sensors that d= on't want to implement a more heavyweight protocol, but I don't believe tha= t was stated anywhere. I got the impression that the functionality provided could have been done w= ith existing protocols by sending the CAP message over a SIP session, but t= hat doing so would place an unnecessary burden on simple (IoT) sensors, and= that this protocol would be easier for such sensors to implement for the l= imited cases such sensors need to deal with. If that's true, it should be s= tated. If not, the purpose of this protocol should be more clearly stated. These acronyms were used but never defined: SIP CID LoST These acronyms were expanded, but not in an easy to find place: Common Alerting Protocol (CAP) Public Safety Answering Points (PSAPs) Emergency Services Routing Proxy (ESRP) It would be nice to include them in the terminology section, ideally with a= reference to the RFC where more information is available. Typo: p17 "security mechanism" -> "security mechanisms" --Charlie --_000_MWHPR04MB0367DA96CF172D996CDDA622DFA70MWHPR04MB0367namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's on= going effort to review all IETF documents being processed by the IESG. = ; These comments were written primarily for the benefit of the security are= a directors.  Document editors and WG chairs should treat these comments just like any other last call comments.=

This document defines a new MIME type: 'application/EmergencyCallData.= cap+xml' for use primarily by sensors to send alert messages to emergen= cy services providers. It also defines a new Emergency Call Data Type: 'cap= ' in order to embed this data efficiently in a SIP transaction. I saw no new security issues beyond those already no= ted for the protocols carrying these messages.

I do have some editorial suggestions:

There is a lot of context that the authors assumed any reader would ha= ve that could have been stated in the introduction. I believe from context = that the purpose of this new MIME type is to support simple (IoT) sensors t= hat don't want to implement a more heavyweight protocol, but I don't believe that was stated anywhere.

I got the impression that the functionality provided could have been d= one with existing protocols by sending the CAP message over a SIP session, = but that doing so would place an unnecessary burden on simple (IoT) sensors= , and that this protocol would be easier for such sensors to implement for the limited cases such sensors ne= ed to deal with. If that's true, it should be stated. If not, the purpose o= f this protocol should be more clearly stated.

These acronyms were used but never defined:

SIP
CID
LoST

These acronyms were expanded, but not in an easy to find place:

Common Alerting Protocol (CAP)
Public Safety Answering Points (PSAPs)
Emergency Services Routing Proxy (ESRP)

It would be nice to include them in the terminology section, ideally w= ith a reference to the RFC where more information is available.

Typo:

p17 "security mechanism" -> "security mechanisms&quo= t;

 --Charlie

--_000_MWHPR04MB0367DA96CF172D996CDDA622DFA70MWHPR04MB0367namp_-- From nobody Sat Aug 24 14:18:19 2019 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 43AED120088; Sat, 24 Aug 2019 14:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0O22P_qXfyD; Sat, 24 Aug 2019 14:18:14 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79A212006D; Sat, 24 Aug 2019 14:18:14 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id p3so7950613pgb.9; Sat, 24 Aug 2019 14:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A3FB0rgL5uNCXbL9iJtguwuP4RJOxdtpuP05UwSIrPg=; b=GafuO7dSlA4mcMGwcoQ+dA1sdASfKX9zA6t/BW+5NdE//dEV19K/yURDg7xxoM5Lv3 d7KemYHrELwejbnNaSkO9t3LAiCwzDAwAp4jjD9CK+bB5x84UxqPpLM6OJ5/kaTuDpGE 92FrNb216FjF7Ho6SaLnJSeRO5erzFB0Qkpm0DPoC28OnuyzcxPk9pacBqtEX0PVb98w qt/aUMvcEHEJUDPHvGVDzUuO0u8lCxMzwPxWDKYjHldcUlQUkk7YLe4RGdQAO3Rbb+XN ha32xEHSRnw+CUnp0VG5/9+V8EyLcCchCtH60de/1tbwdp5wSa56fHbfdLhB+mpQDPYU Kqtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A3FB0rgL5uNCXbL9iJtguwuP4RJOxdtpuP05UwSIrPg=; b=mZxLQ5ezXD6BfDo5ikbFtP6Vsbj8KU36+wu9+D6jE7NBCQkzSEWWqnbWMWcbh/Eyy0 mIKPB9XTXsRcgPpR25cSYStxfr2Xb1lN5BsEiTRVdPZcFGo2i5qLPL1QdYsnIhOrwrmX 5gwIr5XBSZowJ51H4HxFlN/sqAjtIzgC6yGfMpFszkHB9jy9IlNPaEM69h/1B/Ju6utD 1eeLCBDnaKkPh2q/6e9/Ogghe2KDmsEHQfsnGbN6JOnCHanRPV8f853dM+RTIFXdZ53B /FtavnwZlUTxH2jxcMMGtGSgdfl3lUmZyJO5FOH6LC+k2VAJ6UKBjQyCv3zpi26rGx6w R7ZA== X-Gm-Message-State: APjAAAXd9ePHMo75Q0bXJ0uXtS4qFM27d4+9Xt3IR9TqnWoosK1Y+Dnr dMgBBNnXFM+iwsgk6OEO81FEXvBeQJbIp13+Bbo= X-Google-Smtp-Source: APXvYqx6+3yEn4HjGxS8Mck0njhon2EfGSDEoh8gfgnjksIsMlbMkeQHrAuzpiYcrNTtpw23ejNFuSTS23OY6Cfn4WM= X-Received: by 2002:a63:61cd:: with SMTP id v196mr9747340pgb.263.1566681494027; Sat, 24 Aug 2019 14:18:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Allison Mankin Date: Sat, 24 Aug 2019 17:18:03 -0400 Message-ID: To: Charlie Kaufman Cc: "draft-ietf-ecrit-data-only-ea.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ed831f0590e375f4" Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 21:18:17 -0000 --000000000000ed831f0590e375f4 Content-Type: text/plain; charset="UTF-8" Thank you, Charlie. Authors, these are good suggestions! On Sat, Aug 24, 2019 at 15:53 Charlie Kaufman 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 defines a new MIME type: > 'application/EmergencyCallData.cap+xml' for use primarily by sensors to > send alert messages to emergency services providers. It also defines a new > Emergency Call Data Type: 'cap' in order to embed this data efficiently in > a SIP transaction. I saw no new security issues beyond those already noted > for the protocols carrying these messages. > > I do have some editorial suggestions: > > There is a lot of context that the authors assumed any reader would have > that could have been stated in the introduction. I believe from context > that the purpose of this new MIME type is to support simple (IoT) sensors > that don't want to implement a more heavyweight protocol, but I don't > believe that was stated anywhere. > > I got the impression that the functionality provided could have been done > with existing protocols by sending the CAP message over a SIP session, but > that doing so would place an unnecessary burden on simple (IoT) sensors, > and that this protocol would be easier for such sensors to implement for > the limited cases such sensors need to deal with. If that's true, it should > be stated. If not, the purpose of this protocol should be more clearly > stated. > > These acronyms were used but never defined: > > SIP > CID > LoST > > These acronyms were expanded, but not in an easy to find place: > > Common Alerting Protocol (CAP) > Public Safety Answering Points (PSAPs) > Emergency Services Routing Proxy (ESRP) > > It would be nice to include them in the terminology section, ideally with > a reference to the RFC where more information is available. > > Typo: > > p17 "security mechanism" -> "security mechanisms" > > --Charlie > > --000000000000ed831f0590e375f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you, Charlie. Authors, these are good suggesti= ons!

On Sat, Aug 24, 2019 at 15:53 Charlie Kaufman <charliekaufman@outlook.com> w= rote:
I have reviewed this document as part of the security directorate'= s ongoing effort to review all IETF documents being processed by the IESG.= =C2=A0 These comments were written primarily for the benefit of the securit= y area directors.=C2=A0 Document editors and WG chairs should treat these comments just like any other last call comments.=

This document defines a new MIME type: 'application/EmergencyCallD= ata.cap+xml' for use primarily by sensors to send alert messages to eme= rgency services providers. It also defines a new Emergency Call Data Type: = 'cap' in order to embed this data efficiently in a SIP transaction. I saw no new security issues beyond those already no= ted for the protocols carrying these messages.

I do have some editorial suggestions:

There is a lot of context that the authors assumed any reader would ha= ve that could have been stated in the introduction. I believe from context = that the purpose of this new MIME type is to support simple (IoT) sensors t= hat don't want to implement a more heavyweight protocol, but I don't believe that was stated anywhere.

I got the impression that the functionality provided could have been d= one with existing protocols by sending the CAP message over a SIP session, = but that doing so would place an unnecessary burden on simple (IoT) sensors= , and that this protocol would be easier for such sensors to implement for the limited cases such sensors ne= ed to deal with. If that's true, it should be stated. If not, the purpo= se of this protocol should be more clearly stated.

These acronyms were used but never defined:

SIP
CID
LoST

These acronyms were expanded, but not in an easy to find place:

Common Alerting Protocol (CAP)
Public Safety Answering Points (PSAPs)
Emergency Services Routing Proxy (ESRP)

It would be nice to include them in the terminology section, ideally w= ith a reference to the RFC where more information is available.

Typo:

p17 "security mechanism" -> "security mechanisms&quo= t;

=C2=A0--Charlie

--000000000000ed831f0590e375f4-- From nobody Sat Aug 24 21:30:55 2019 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 E88901200EF; Sat, 24 Aug 2019 21:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=T5tro9eM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lgBirywa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEkqocxzOvV0; Sat, 24 Aug 2019 21:30:36 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565AD1200D8; Sat, 24 Aug 2019 21:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10154; q=dns/txt; s=iport; t=1566707436; x=1567917036; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=N4NwseiFJxSRuYLYS/xrMyn4o4h6FDV3xgufTiz4pqQ=; b=T5tro9eMDM8MPjGGZsedvmIrbun0DY83IOgdjeDY8C+rNnXVSvikAhJ3 0bq3PgXJcBwlmIhc15IsrswMND5rEO2lVnocLEJbt/DIvrKxv09p8DAIo AQ98Y8qyZhArFMDiSaLmPe3sBIgiLlx7x1UUMfaNH/YVPyHh91hao49Ih 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AZSotxBN3fmdv1gjRCyol6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjrLfftdj46AexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYBwCYDmJd/49dJa1aCg4OAQEBBAE?= =?us-ascii?q?BBwQBAYFngUVQA21WIAQLKoQhg0cDimyCNyWXaIFCgRADVAkBAQEMAQEbEgI?= =?us-ascii?q?BAYQ/AheCUCM4EwIKAQEEAQEBAgEGBG2FLQyFSgEBAQECARIREQwBASkOAQ8?= =?us-ascii?q?CAQgYAgIRCA0CAgIwFRACBA4FIoMAAYFqAw4PAZ5zAoE4iGFzgTKCewEBBYR?= =?us-ascii?q?+GIIWAwaBDCiEe4IEgiqCSRiBQD+BEScME4JMPoN/GisXKIJMMoImjmsym2p?= =?us-ascii?q?nCQKCHoZqjVkUB4IyhzCKTmKDPY8ehjWQOwIEAgQFAg4BAQWBZyGBWHAVZQG?= =?us-ascii?q?CQYJCDBeDT4UUhQQ7coEpjhcBAQ?= X-IronPort-AV: E=Sophos;i="5.64,428,1559520000"; d="scan'208";a="620695168" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Aug 2019 04:30:13 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x7P4UDQ4031438 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 25 Aug 2019 04:30:13 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 24 Aug 2019 23:30:12 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 25 Aug 2019 00:30:11 -0400 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 25 Aug 2019 00:30:11 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DTqBzE1Rln80KcYB28Tc2mBa0VuIH2LjTT/SM+3yro0eVMppP8thZV3Buk6tUtpiC6bAuY6DbRgUp3VEGs9l7WZfWdezf8IyRR6RVKEhP3DhL2y7suZTQI4baGQAS7AZM1WjsqjyT1IQLC47d41TpgUFoLcMFfVGU0s8wKd/q84v1RSe0VYp8WBCp66rTKVwl3ISwaf9Wq0q7iP+WJgD29kVAs4//4TWFFB/TcLEbk9jAs+IidRA1D4PpKJtE5X90OYa8WH8WgU9TopXjq59R40Jp2f71SguEWjXd17B8iC+ZvVw13coGbOrN+UNGONs8Hndr9j2/mlNEHUUxTASeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N4NwseiFJxSRuYLYS/xrMyn4o4h6FDV3xgufTiz4pqQ=; b=FA9OlsiZRvIk9lU3zstyQyeES+wajbYXSH+dabepYFRvoXCO91stg8hUd2A7s+rTNQ8mXRH/qCwLeTzplmHCXLo/41iVgdZP4TO4WXVHMfVYu57qHIbCbuxruVMyCcTcv2qDK8Gv2t1iKTrK2yPTjZCMjrMJ//srdtANYfv1YP/wNBi9k/8beb4/120+A9A2w+6MjOP1HGaj6r4iyf2k2XujZfxxC3+OUYhV2EUSlw4DwRiuOMm+EPXGL2NYsIutP8JrYIoYRWDtE01ffQwoQbnc/lNKCxOUxJblWkAw/QzLh5dpIyQkPq5twz+eAP1ufiOkudP6X10zgNBZLUjIGg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N4NwseiFJxSRuYLYS/xrMyn4o4h6FDV3xgufTiz4pqQ=; b=lgBirywarWUqCve9M7NXMqdNSvM0L8akUu6BK9jXedNigjVvwyby25YlQlo4Yi0PI1guveX3+5m6d7UWDhpwG6ew6YjSyMrKsLXyUmaaLmSIj1GXhZYZqZ2LtQhOHCgVt6wA/a8j1BbRKrO3MgV2zhjfEd6hUKcc8xABFmBAgAY= Received: from CY4PR11MB1559.namprd11.prod.outlook.com (10.172.72.140) by CY4PR11MB1382.namprd11.prod.outlook.com (10.173.16.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.20; Sun, 25 Aug 2019 04:30:09 +0000 Received: from CY4PR11MB1559.namprd11.prod.outlook.com ([fe80::53:33f3:ea63:7f72]) by CY4PR11MB1559.namprd11.prod.outlook.com ([fe80::53:33f3:ea63:7f72%3]) with mapi id 15.20.2199.020; Sun, 25 Aug 2019 04:30:09 +0000 From: "Xiaoqing Zhu (xiaoqzhu)" To: Gorry Fairhurst CC: "draft-ietf-rmcat-nada.all@ietf.org" , IETF , "secdir@ietf.org" , "rmcat@ietf.org" , Mirja Kuehlewind , Colin Perkins , Sean Turner Thread-Topic: [rmcat] Secdir last call review of draft-ietf-rmcat-nada-11 Thread-Index: AQHVUXOlEGdHcdwXkkGy8eFbeJEvyKb4tnUAgAULjoCAAB/9gP//y4AAgAFbUICAADJAAIALycMA Date: Sun, 25 Aug 2019 04:30:08 +0000 Message-ID: References: <156565849881.20488.4580765481520503258@ietfa.amsl.com> <5D526D4A.5010304@erg.abdn.ac.uk> <8EB353C0-FC34-4514-8283-0D1654EE48DD@kuehlewind.net> <2EB42977-16EF-46AA-B1E8-EA4C420FA51A@csperkins.org> <865425B9-FF34-45F6-89C4-2C2D79741382@cisco.com> <5D57BADD.8080508@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1c.0.190812 authentication-results: spf=none (sender IP is ) smtp.mailfrom=xiaoqzhu@cisco.com; x-originating-ip: [2001:420:c0cc:1007::f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 41d80ab7-64f3-4737-c84b-08d72914e9da x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR11MB1382; x-ms-traffictypediagnostic: CY4PR11MB1382: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 01401330D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(376002)(39860400002)(136003)(366004)(189003)(199004)(31014005)(186003)(966005)(256004)(14444005)(14454004)(478600001)(476003)(71200400001)(71190400001)(76176011)(25786009)(6246003)(11346002)(486006)(6436002)(46003)(102836004)(446003)(53936002)(99286004)(6506007)(53546011)(5660300002)(4326008)(6306002)(6512007)(296002)(316002)(58126008)(33656002)(54906003)(2906002)(6116002)(81166006)(8676002)(81156014)(2616005)(8936002)(6486002)(7736002)(305945005)(229853002)(76116006)(91956017)(86362001)(66446008)(6916009)(36756003)(64756008)(66556008)(66946007)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB1382; H:CY4PR11MB1559.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: +xDiLi4Sa7OigHXlxSpKMRJ8LNJUgrI+ywPNIcVtvHN2shv4TD0Nw0+lDusSno3UYSODnH9xEbKzyqBASrWJho9CZe3YKNv2uewHOjnqkGYXle/mWB9gn3kOLpmzn1tsZ7jsjdaRZyPo1WWvaoe16INJRqmSEkvg5WiE1EN+Us6of8JeCVu+j2eAZNUjR/QKH/toGl/56UsYE5Gg2x95nqSLLre+lsW1nlGaxFl2qG3baAExQuKMHlfqO03p5fV5lWgeSQ7c9f62HwSlDUq2ZCnxO7IY+8UQNs2bIlmEf2/NFyLiq1t7btsTZtHIdbcDsLxwuNH06sSg0y6IStbn5O6FdWHotjDeGmarLLQAMwS3dqrUEbQ0RZJZXgleo5KKn9MU4MMeLE5NKbQdiu4gN2mwYh9TGog8UM/4mHzFl48= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 41d80ab7-64f3-4737-c84b-08d72914e9da X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2019 04:30:09.3749 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Grw02r8NJqQc+rMiGREOwzrSdUIKnEvWiJuBPfIuMyDh3DkERI38sIlFax+d6zFDW35p8VxvR3fEJ8DWZ17IOg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1382 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xch-rcd-012.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [secdir] [rmcat] Secdir last call review of draft-ietf-rmcat-nada-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 04:30:39 -0000 SnVzdCB3YW50ZWQgdG8gdXBkYXRlIHRoYXQgdGhlIGRyYWZ0IGhhcyBiZWVuIHVwZGF0ZWQgdG8g dmVyc2lvbiAtMTIsIHdoZXJlIHdlIGluY29ycG9yYXRlZCB0aGUgU2VjZGlyIHJldmlldyBjb21t ZW50cyBhcyBkaXNjdXNzZWQgaW4gdGhpcyB0aHJlYWQuIA0KDQpUaGFua3MgYWdhaW4gdG8gR29y cnkvU2Vhbi9NaXJqYS9Db2xpbiBmb3IgeW91ciBpbnB1dCAmIHN1Z2dlc3Rpb25zLiANCg0KQmVz dCwNClhpYW9xaW5nDQoNCg0K77u/T24gOC8xNy8xOSwgNjozMCBBTSwgIkdvcnJ5IEZhaXJodXJz dCIgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPiB3cm90ZToNCg0KICAgIA0KICAgIFRvIGJlIGNsZWFy LCBzZWUgbm90ZXMgYmVsb3cuDQogICAgDQogICAgU2VudCBmcm9tIG15IGlQYWQNCiAgICANCiAg ICA+IE9uIDE3IEF1ZyAyMDE5LCBhdCAwOToyOSwgR29ycnkgRmFpcmh1cnN0IDxnb3JyeUBlcmcu YWJkbi5hYy51az4gd3JvdGU6DQogICAgPiANCiAgICA+IA0KICAgID4gWWVzLiBJJ20gaGFwcHkg d2l0aCB0aGlzIGFwcHJvYWNoIGluIHJlc3BvbnNlIHRvIG15IGZlZWRiYWNrLiBTcGVjaWZpY2Fs bHksIHByb3ZpZGluZyBleHRyYSB0ZXh0IGluIHRoZSBzZWN1cml0eSByZXF1aXJlbWVudHMgdG8g aGlnaGxpZ2h0IGVhY2ggb2YgdGhlc2UgKGdlbmVyaWMpIENDIHRvcGljcyAtIGlmIG5lZWRlZCwg d2l0aCBwb2ludGVycyB0byBvdGhlciBkb2N1bWVudHMgd2hlcmUgdGhlc2UgYXJlIGRpc2N1c3Nl ZCBtb3JlLg0KICAgID4gDQogICAgPiBHb3JyeQ0KICAgID4gDQogICAgPj4gT24gMTYvMDgvMjAx OSwgMTc6NDYsIFhpYW9xaW5nIFpodSAoeGlhb3F6aHUpIHdyb3RlOg0KICAgID4+IEhpLA0KICAg ID4+IA0KICAgID4+IFRoYW5rcyB0byBTZWFuIGFuZCBHb3JyeSBmb3IgeW91ciByZXZpZXcgY29t bWVudHMuICBBbmQgdGhhbmtzIHRvIE1pcmphIGFuZCBDb2xpbiBmb3IgY2hpbWluZyBpbiB3aXRo IHlvdXIgaW5wdXRzIGFuZCBzdWdnZXN0aW9ucy4NCiAgICA+PiANCiAgICA+PiBCZWxvdyBhcmUg bXkgcGxhbm5lZCBhY3Rpb25zIGZvciByZXZpc2luZyB0aGUgZHJhZnQsIHNvIHRoYXQgdGhleSBj YW4gYWRkcmVzcyB0aGUgb3JpZ2luYWwgc2V0IG9mIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMgZnJv bSBTZWFuICh3aGlsZSB0YWtpbmcgaW50byBhY2NvdW50IGlucHV0cyBmcm9tIEdvcnJ5L01pcmph L0NvbGluKQ0KICAgID4+IA0KICAgID4+ICogU3VnZ2VzdGlvbnMgZm9yIHJldmlzZWQgdGV4dCBp biB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM6ICB3aWxsIGJlIGhhcHB5IHRvIHJldmlzZSBh Y2NvcmRpbmdseS4gV2lsbCBhbHNvIHNwbGl0IHVwIHRoZSB0ZXh0IGludG8gdHdvIHBhcmFncmFw aHMgY29ycmVzcG9uZGluZyB0byB0aGUgdHdvIHBvaW50cy4NCiAgICANCiAgICBJIGxpa2VkIHRo ZSBpZGVhIG9mIG5vdGluZyB0aGUgQ0MgaW1wbGljYXRpb25zIGluIHRoZSBTZWN1cml0eSBDb25z aWRlcmF0aW9ucywgd2UgaGF2ZSBkb25lIHNvIGJlZm9yZSwgYW5kIGEgYnJpZWYgYWRkaXRpb25h bCB0ZXh0ICB3aXRoIHJlZnMgdG8gYW5vdGhlciBSRkMgc2hvdWxkIHN1ZmZpY2UuDQogICAgDQog ICAgPj4gKiBRdWVzdGlvbiAxIG9uIGNvbmNlcm5zIHJlbGF0ZWQgdG8gZ3JlZWR5IHJlY2VpdmVy czogIGFzIGEgZ2VuZXJhbCBmYWlybmVzcyBjb25jZXJuIChmb3IgbW9zdCBjb25nZXN0aW9uIGNv bnRyb2wgc2NoZW1lcykgdGhpcyBpcyBkaXNjdXNzZWQgaW4gZ3JlYXRlciBkZXRhaWwgaW4gdGhl IGNjLXJlcXVpcmVtZW50cyBkcmFmdC4gIFRoZSBkcmFmdCBjdXJyZW50IG9ubHkgY2l0ZXMgdGhl IGNjLXJlcXVpcmVtZW50cyBkcmFmdCBpbiB0aGUgaW50cm8uIFdlIGNhbiBhZGQgc29tZSBtb3Jl IHRleHQgdG8gaGlnaGxpZ2h0IHNldmVyYWwgc2FsaWVudCByZXF1aXJlbWVudHMgKGUuZy4sIHN0 YWJpbGl0eSwgZmFpcm5lc3MpIGFzIGV4YW1wbGUuDQogICAgDQogICAgUHJvdmluZyBhIGJyaWVm IHN1bW1hcnkgYW5kIGNpdGluZyBpbiB0aGUgc2VjIGNvbnNpZGVyYXRpb25zIHNlZW1zIGdvb2Qg dG8gbWUuDQogICAgDQogICAgPj4gKiBRdWVzdGlvbiAyIG9uIFJUUC9SVENQIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zOiAgcGVyIENvbGluJ3Mgc3VnZ2VzdGlvbiwgd2lsbCBhZGQgYSByZWZlcmVu Y2UgYW5kIHBvaW50IHRvIHRoZSBjYy1mZWVkYmFjay1tZXNzYWdlIGRyYWZ0IGZvciBmdXJ0aGVy IGRpc2N1c3Npb25zIG9uIHNlY3VyaXR5IG1lY2hhbmlzbXMuDQogICAgPj4gDQogICAgPj4gR29y cnkgLS0gSSB1bmRlcnN0b29kIHlvdXIgY29tbWVudHMgYXMgcmVmZXJyaW5nIHRvIHRoZSB0ZXh0 IHN1Z2dlc3Rpb25zIGJ5IFNlYW4uICBQbGVhc2UgbGV0IHVzIGtub3cgaWYgdGhhdCdzIG5vdCB0 aGUgY2FzZSBvciBpZiB0aGUgYWJvdmUgcGxhbm5lZCBjaGFuZ2VzIG1pc3Mgb3V0IGFueSBwb2lu dHMgeW91J2QgbGlrZSB0byBoaWdobGlnaHQuDQogICAgWWVzIGFuZCBzb21lIG1lbnRpb24gb2Yg cG9zc2libGUgYXR0YWNrIG9uIHJlY2VpdmVyLXN1cHBsaWVkIGluZm8sIGFsdGhvdWdoIGFnYWlu IG15IHByZWZlcmVuY2Ugd291bGQgYmUgaWRlbnRpZnkgaXNzdWUgYW5kIHByb3ZpZGUgIGEgcmVm IHRvIGFub3RoZXIgUkZDLCByYXRoZXIgdGhhbiBkZXRhaWxlZCBkaXNjdXNzaW9uLiBUaGlzIGlz IG5vdCBhIG5ldyBpc3N1ZS4NCiAgICANCiAgICA+PiBCZXN0LA0KICAgID4+IFhpYW9xaW5nDQog ICAgPj4gDQogICAgPj4gT24gOC8xNi8xOSwgOTo1NCBBTSwgIkNvbGluIFBlcmtpbnMiPGNzcEBj c3BlcmtpbnMub3JnPiAgd3JvdGU6DQogICAgPj4gDQogICAgPj4gICAgSGksDQogICAgPj4gDQog ICAgPj4+IE9uIDE2IEF1ZyAyMDE5LCBhdCAxMzo1OSwgTWlyamEgS3VlaGxld2luZDxpZXRmQGt1 ZWhsZXdpbmQubmV0PiAgd3JvdGU6DQogICAgPj4+IA0KICAgID4+PiBIaSBTZWFuLCBoaSBHb3Jy eSwNCiAgICA+Pj4gDQogICAgPj4+IFRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIGZlZWRiYWNr LiBQbGVhc2Ugc2VlIGJlbG93Lg0KICAgID4+PiANCiAgICA+Pj4+IE9uIDEzLiBBdWcgMjAxOSwg YXQgMDk6NTYsIEdvcnJ5IEZhaXJodXJzdDxnb3JyeUBlcmcuYWJkbi5hYy51az4gIHdyb3RlOg0K ICAgID4+Pj4gDQogICAgPj4+PiBTZWUgIGJlbG93Og0KICAgID4+Pj4gDQogICAgPj4+Pj4gT24g MTMvMDgvMjAxOSwgMDI6MDgsIFNlYW4gVHVybmVyIHZpYSBEYXRhdHJhY2tlciB3cm90ZToNCiAg ICA+Pj4+PiBSZXZpZXdlcjogU2VhbiBUdXJuZXINCiAgICA+Pj4+PiBSZXZpZXcgcmVzdWx0OiBI YXMgTml0cw0KICAgID4+Pj4+IA0KICAgID4+Pj4+IEhpISBJJ20gbm8gY29uZ2VzdGlvbiBjb250 cm9sIGV4cGVydCBzbyBub3RoaW5nIGluIHRoZSBtYWluIGJvZHkganVtcGVkIG91dCBhdA0KICAg ID4+Pj4+IG1lLiAgSSBkaWQgdGFrZSBhIGxpdHRsZSB0aW1lIHRvIHJldmlldyBzb21lIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIGZvciBvdGhlcg0KICAgID4+Pj4+IGNvbmdlc3Rpb24gY29udHJv bCBSRkNzIGFuZCBqdXN0IHdhbnRlZCB0byBtYWtlIHN1cmUgdGhlIHNhbWUga2luZCBvZg0KICAg ID4+Pj4+IGluZm9ybWF0aW9uIGlzIGdldHRpbmcgYWRkcmVzc2VkLiAgSSBpbmRpY2F0ZWQgdGhl IHJlc3VsdCBvZiB0aGlzIHJldmlldyBhcw0KICAgID4+Pj4+ICJoYXMgbml0cyIgYmVjYXVzZSB0 aGVyZSBpcyBhIHByZXR0eSBnb29kIGNoYW5jZSBJIGFtIGp1c3Qgc3VnZ2VzdGluZyBzb21lDQog ICAgPj4+Pj4gZWRpdG9yaWFsIHR3ZWFrcy4NCiAgICA+Pj4+PiANCiAgICA+Pj4+PiBUaGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgcmlnaHRseSBwb2ludHMgb3V0IHRoYXQgdGhpcyBtZWNoYW5p c20gaXMNCiAgICA+Pj4+PiBzdXNjZXB0aWJsZSB0byB0aGUgc2FtZSBraW5kIG9mIGF0dGFja3Mg YXMgVENQIChlLmcuLCBoaWphY2ssIHJlcGxhY2VtZW50KSBhbmQNCiAgICA+Pj4+PiB3aGF0IG1p dGlnYXRpb25zIHRvIHVzZSAoaS5lLiwgaW50ZWdyaXR5IHByb3RlY3Rpb24gb2YgdGhlIFJUQ1Ag ZmVlZGJhY2sNCiAgICA+Pj4+PiBtZXNzYWdlcykuICBCdXQsIHdoYXQgaXMgbWlzc2luZyBpcyB3 aGF0IGhhcHBlbnMgaWYgdGhlc2UgYXR0YWNrcyBzdWNjZWVkOiBEb1MNCiAgICA+Pj4+PiBvciBp biB0aGUgd29yc3QgY2FzZSBjb25nZXN0aW9uIGNvbGxhcHNlPyAgU28sIG1heWJlIGluc3RlYWQg b2Y6DQogICAgPj4+Pj4gDQogICAgPj4+Pj4gICBBcyBzdWNoLCBpdCBpcyB2dWxuZXJhYmxlIHRv IGF0dGFja3Mgd2hlcmUgZmVlZGJhY2sNCiAgICA+Pj4+PiAgIG1lc3NhZ2VzIGFyZSBoaWphY2tl ZCwgcmVwbGFjZXMsIG9yIGludGVudGlvbmFsbHkgaW5qZWN0ZWQgd2l0aA0KICAgID4+Pj4+ICAg bWlzbGVhZGluZyBpbmZvcm1hdGlvbiwgc2ltaWxhciB0byB0aG9zZSB0aGF0IGNhbiBhZmZlY3Qg VENQLg0KICAgID4+Pj4+IA0KICAgID4+Pj4+IE1heWJlOg0KICAgID4+Pj4+IA0KICAgID4+Pj4+ ICAgQXMgc3VjaCwgaXQgaXMgdnVsbmVyYWJsZSB0byBhdHRhY2tzIHdoZXJlIGZlZWRiYWNrDQog ICAgPj4+Pj4gICBtZXNzYWdlcyBhcmUgaGlqYWNrZWQsIHJlcGxhY2VzLCBvciBpbnRlbnRpb25h bGx5IGluamVjdGVkIHdpdGgNCiAgICA+Pj4+PiAgIG1pc2xlYWRpbmcgaW5mb3JtYXRpb24gcmVz dWx0aW5nIGluIGRlbmlhbCBvZiBzZXJ2aWNlLCBzaW1pbGFyDQogICAgPj4+Pj4gICB0byB0aG9z ZSB0aGF0IGNhbiBhZmZlY3QgVENQLg0KICAgID4+Pj4+IA0KICAgID4+Pj4+IEFsc28sIHVubGVz cyBJJ3ZlIGNvbXBsZXRlbHkgbWlzcmVhZCB0aGlzIHBhcmFncmFwaCBpdCBzZWVtcyBsaWtlIHlv dSBhcmUNCiAgICA+Pj4+PiB0YWxraW5nIGFib3V0IHR3byB0aGluZ3M6IDEpIGl0J3MganVzdCBs aWtlIFRDUCwgYW5kIDIpICJUaGUgbW9kaWZpY2F0aW9uIG9mDQogICAgPj4+Pj4gc2VuZGluZyBy YXRlIC4uLiIuICBTbywgbWF5YmUgc3BsaXQgdGhlIHBhcmFncmFwaCBhbG9uZyB0aG9zZSBsaW5l cy4NCiAgICA+Pj4gDQogICAgPj4+IEkgdGhpbmsgdGhpcyBpcyBhY3R1YWxseSBiYXNlZCBvbiB0 ZXh0IHRoYXQgd2UgdXNlZCBmb3Igc2NyZWFtIChub3cgUkZDODI5OCkgd2hpY2ggaXMgYW5vdGhl ciBjb25nZXN0aW9uIGNvbnRyb2wgZGV2ZWxvcGVkIGluIHJtY2F0LiBJIHRoaW5rIHdlIHJlZmlu ZWQgdGhhdCB0ZXh0IGFsc28gYmFzZWQgb24gYSBTRUMgKG9yIEdFTj8pIHJldmlldyBjb21tZW50 IGF0IHRoYXQgdGltZSBhbmQgcGVvcGxlIHdlcmUgYXQgdGhlIGVuZCBzYXRpc2ZpZWQgd2l0aCBp dC4gSG93ZXZlciwgeW91ciBwcm9wb3NlZCBjaGFuZ2UgYWJvdmUgY291bGQgc3VyZWx5IGJlIGlu dGVncmF0ZWQgYW5kIEkgbGVhdmUgaXQgdG8gdGhlIGF1dGhvcnMgaWYgdGhleSB3YW50IHRvIHJl ZmluZSB0aGUgdGV4dCBmdXJ0aGVyLg0KICAgID4+PiANCiAgICA+Pj4+PiANCiAgICA+Pj4+PiBG dXJ0aGVyIHF1ZXN0aW9uczoNCiAgICA+Pj4+PiANCiAgICA+Pj4+PiAxLiBBcmUgdGhlcmUgYW55 IGNvbmNlcm5zIHJlbGF0ZWQgdG8gYSBncmVlZHkgcmVjZWl2ZXIgd2hvIHdhbnRzIHRvIGdvYmJs ZSB1cA0KICAgID4+Pj4+IG1vcmUgdGhhbiBpdHMgZmFpciBzaGFyZSBvZiBuZXR3b3JrIGJhbmR3 aWR0aD8NCiAgICA+Pj4gDQogICAgPj4+IFRoaXMgaXMgYSB2ZXJ5IGdlbmVyYWwgcG9pbnQgZm9y IGFsbCBjb25nZXN0aW9uIGNvbnRyb2wgc2NoZW1lcywgYW5kIGZvciBybWNhdCBpdCBpcyBhbHNv IGRpc2N1c3NlZCBpbiBkcmFmdC1pZXRmLXJtY2F0LWNjLXJlcXVpcmVtZW50cyAod2hpY2ggaXMg c2l0dGluZyBpbiB0aGUgUkZDIGVkaXRvciBxdWV1ZSBmb3IgYSB3aGlsZSBhcyBwYXJ0IG9mIHRo ZSAyMzggY2x1c3RlcuKApikuIEkgcGVyc29uYWxseSBkb27igJl0IHNlZSB0b28gbXVjaCB2YWx1 ZSBpbiBkaXNjdXNzaW5nIHRoaXMgaGVyZSBvbmNlIGFnYWluIChnaXZlbiB0aGUgZ2VuZXJpYyBu YXR1cmUgb2YgdGhlIHByb2JsZW0gYW5kIHZlcnkgdW5jbGVhciBkZWZpbml0aW9uIG9mIOKAnGZh aXLigJ0pLg0KICAgID4+PiANCiAgICA+Pj4+PiANCiAgICA+Pj4+PiAyLiBTZWVtcyBsaWtlIG1h eWJlIHlvdSBhbHNvIG5lZWQgdG8gcmVmZXIgdG8gdGhlIFJUUC9SVENQIHNlY3VyaXR5DQogICAg Pj4+Pj4gY29uc2lkZXJhdGlvbnMgYmVjYXVzZSBpdCBzZWVtcyBsaWtlIHNlY3VyaXR5IHByaW1h cmlseSBuZWVkcyB0byBiZSBjb25zaWRlcmVkDQogICAgPj4+Pj4gaW4gdGhlIGNvbnRleHQgb2Yg YSBzcGVjaWZpYyB0cmFuc3BvcnQgcHJvdG9jb2wgYW5kIGl0cyBhdXRoZW50aWNhdGlvbg0KICAg ID4+Pj4+IG1lY2hhbmlzbXMuDQogICAgPj4+IA0KICAgID4+PiBIbSwgYWxzbyBub3Qgc3VyZSBo ZXJlIGJlY2F1c2UsIHdoaWxlIHRoaXMgY29uZ2VzdGlvbiBjb250cm9sIHNjaGVtZSBpcyBkZXZl bG9wZWQgZm9yIFJUUC9SVENQLCBpdCdzIGRlZmluZWQgaW4gYSBtb3JlIGdlbmVyaWMgd2F5IGFu ZCB0aGVyZSBhcmUgYWN0dWFsbHkgbm8gcmVhbCBkZXBlbmRlbmNpZXMgb24gYSBzcGVjaWZpYyBw cm90b2NvbC4NCiAgICA+PiANCiAgICA+PiAgICBGb3IgYm90aCB0aGlzIGFuZCB0aGUgR2VuQVJU IHJldmlldywgaXQgc2hvdWxkIG1heWJlIHBvaW50IHRvIGRyYWZ0LWlldGYtYXZ0Y29yZS1jYy1m ZWVkYmFjay1tZXNzYWdlLTA0IGFzIGFuIGV4YW1wbGUgbWVjaGFuaXNtIHRvIGNhcnJ5IGNvbmdl c3Rpb24gZmVlZGJhY2suIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiB0aGF0IGRyYWZ0 IGhpZ2hsaWdodCBzb21lIG9mIHRoZXNlIGlzc3VlcywgYW5kIHBvaW50IHRvIHRoZSBSVFAgc2Vj dXJpdHkgbWVjaGFuaXNtcyBuZWVkZWQgdG8gc2VjdXJlIHRoZSBmZWVkYmFjay4NCiAgICA+PiAN CiAgICA+PiAgICBDb2xpbg0KICAgID4+IA0KICAgID4+IA0KICAgID4+IA0KICAgID4+Pj4+IA0K ICAgID4+Pj4+IENoZWVycywNCiAgICA+Pj4+PiANCiAgICA+Pj4+PiBzcHQNCiAgICA+Pj4+IEkg YWxzbyB0aGluayB0aGF0IHRleHQgKG9yIHNpbWlsYXIpIHdvdWxkIGFsc28gYmUgdmFsdWFibGUg aW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQogICAgPj4+IA0KICAgID4+ PiBHb3JyeTogQ2FuIHlvdSBmdXJ0aGVyIGV4cGxhaW4gd2hhdCBwYXJ0IHRoaXMgY29tbWVudCBy ZWxhdGVkIHRvPw0KICAgID4+PiANCiAgICA+Pj4gVGhhbmtzIQ0KICAgID4+PiBNaXJqYQ0KICAg ID4+PiANCiAgICA+Pj4gDQogICAgPj4+IA0KICAgID4+Pj4gR29ycnkNCiAgICA+PiANCiAgICA+ PiANCiAgICA+PiANCiAgICA+PiAgICAtLSAgICAgIENvbGluIFBlcmtpbnMNCiAgICA+PiAgICBo dHRwczovL2NzcGVya2lucy5vcmcvDQogICAgPj4gDQogICAgPj4gDQogICAgPj4gDQogICAgDQog ICAgDQoNCg== From nobody Sun Aug 25 04:21:31 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 553AE1200E3; Sun, 25 Aug 2019 04:21:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tobias Gondrom via Datatracker To: Cc: curdle@ietf.org, ietf@ietf.org, draft-ietf-curdle-ssh-curves.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Tobias Gondrom Message-ID: <156673208322.31181.16685593489316726586@ietfa.amsl.com> Date: Sun, 25 Aug 2019 04:21:23 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-curdle-ssh-curves-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 11:21:23 -0000 Reviewer: Tobias Gondrom Review result: Ready 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 summary of the review is Ready. This document describes how to implement key exchange based on Elliptic Curve Curve25519 (with SHA256) and Curve448 (with SHA512) in SSH. Note: the curve25519-sha256 key exchange is similar to the "curve25519-sha256@libssh.org" key exchange method implemented in libssh and OpenSSH. One thought: I am not cryptographer enough to give a proper recommendation as to the suitability of Curve448 with SHA-512. The reviews state that they would be similar, but with Curve448 not having received the same amount of cryptographic review. I am a bit cautious on assuming it would be good fallback in case Curve25519 would be considered weakened by cryptographic advances. Surely extending the hash to 512 can be helpful, but as both Curve448 and Curve25519 seem to rely on similar principles, the advances that might weaken 25519 might sooner or later also impact 448. Considering that 448 has not had so many reviews, I am not sure whether it is helpful to add it as a fallback. In case of new advances, 448 would have to be reviewed more closely before a general fallback would be recommended. This is only my personal view with limited background in cryptography. However, equally, it might be prudent to add 448 in this document now as it is and then schedule the deeper review once new breakthroughs are being discovered that weaken 25519. One minor spelling nits: section 5: ...but it is provided as an hedge/ but it is provided as a hedge Overall the draft is ready to go. Best regards, Tobias From nobody Sun Aug 25 10:13:15 2019 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 690921200E6; Sun, 25 Aug 2019 10:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMiOHXO9nuJ9; Sun, 25 Aug 2019 10:13:04 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A70D5120033; Sun, 25 Aug 2019 10:13:04 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id c7so13144324otp.1; Sun, 25 Aug 2019 10:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KAusff8vHKIEeCdG/1h5pOk4eAy5zYUDqsWsYb5I8uA=; b=HAB0zL0LecyDPfH5EMVALeLms0SN9pAvo6ZzA/akKVyYJ42dWv3sc9HBFMMk5ZNCFh ocF/uCW8lVnk6IhOLMNMD9pt2jDkezl8pnLL0YT+JgzkCew2Rc9y2Dp06QWH6O0VTPGH c6qmlSKk5L707CIV9wL2WNNWaU83PzuC6ZGzw35QX/xy9r5Uv+rjZMrydSzucli3Dw5k tq9o2DUS5kUhT3MRWu17mxL7bL2zD7KXNt0m+vYh51wlWBDjEzxThJZBKxyQzZo3I0PS zxtUPbgbervPFxN4ztOqfEpa8EoahyrGrRlVeR7jSNwrylPNoCdaT8jSrmpqzyTEGMHG lqGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KAusff8vHKIEeCdG/1h5pOk4eAy5zYUDqsWsYb5I8uA=; b=K65Pa7Gp9b1OKT2kRjUnJPQCwCLbr+XwBHirZCP6/tUvARrpVBFZCQBmu8WKtwRgsd QZCA5D1XKdDw5CRtc3lZs/mDlShqFUakKhD1LDq0lgY4TVW6OMIolHHQPc6z6YBOKTo4 TkkGqAJ54pmQt6OdhNVOSkyBy8AysckGCwvM1EsHWo4hb/mp40s+BbqaKVMBzq6XDF2K Buc1T1zsEh1tNM0vpZxXiNZOAzZF6+QjoYG0bNjbh4XW/L78Upa+xy/zCSymuK4d4kOZ JztDpTvEUxAkVzTb7yxDv7G1XwB1Avzs6liXKH5cw3NbryNTqhSgDzqn1xuYRQUVp1Ok 3CAw== X-Gm-Message-State: APjAAAVV2ZRxFHtLsy3AHRDf/fZJf8TWQqWl0gJN5WGsIQVLCas8tDs3 BcfeOzAjjHCU1UUecHHu/Hl28YmZjgO3hD5yDTA= X-Google-Smtp-Source: APXvYqw2P3F4KF99EyH83+ArR+UuPctnf6d6tFeh3wwAweWJISB+gPvOUdvNNronagUCAWfP6n0H3rOgS/TfHCBw04U= X-Received: by 2002:a9d:61c3:: with SMTP id h3mr12530388otk.39.1566753183983; Sun, 25 Aug 2019 10:13:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mahend Negi Date: Sun, 25 Aug 2019 22:42:53 +0530 Message-ID: To: shawn.emery@gmail.com, semery@uccs.edu Cc: secdir , draft-ietf-pce-lsp-control-request.all@ietf.org, pce@ietf.org, Dhruv Dhody Content-Type: multipart/alternative; boundary="000000000000fb6a880590f4260c" Archived-At: Subject: Re: [secdir] Review of draft-ietf-pce-lsp-control-request-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 17:13:07 -0000 --000000000000fb6a880590f4260c Content-Type: text/plain; charset="UTF-8" Hi Shawn/Dhruv, Thanks for the review and clarifications, we have fixed all the editorial comments in new version. New Version: https://tools.ietf.org/html/draft-ietf-pce-lsp-control-request-08 Version Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-control-request-08 Regards, Mahendra On Tue, Aug 20, 2019 at 11:14 AM Dhruv Dhody wrote: > Hi Shawn, > > > > Thanks for your security review and comments. > > On Mon, Aug 19, 2019 at 6:17 AM Shawn Emery wrote: > > > > Reviewer: Shawn M. Emery > > Review result: Ready > > > > 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 specifies an extension to the Path Computation Element > communication > > Protocol (PCE) that allows a PCE to request control of Label Switched > Paths (LSPs). > > > > The security considerations section does exist and discusses a new DoS > vector > > that this draft creates. The attack involves sending control requests > for delegate > > control of all of its LSPs to the Path Computation Client (PCC). The > proposed > > solution is to set a threshold rate of the delegation requests for the > PCC per PCE. > > I agree with the proposed solution, though I don't know if guidance can > be provided > > on what these thresholds would be per environment. > > > > As you noted the document does not provide default for the threshold > as it dependent on the deployment/environment. The same is true for > RFC 8231. > > > The section goes on to refer to RFC 8231 to justify that the PCP > extension should > > be deployed with authenticated and encrypted sessions in TLS using RFC > 8253. > > I agree with this prescription as well else an attacker would now be > able to take > > control over all local LSPs with this extension. I think that this > should at least be > > stated if an attacker is able to compromise a PCE. > > > > The security consideration includes "...either by spoofing messages or > by compromising the PCE itself". > > > General comments: > > > > None. > > > > Editorial comments: > > > > s/sends PCRpt/sends a PCRpt/ > > s/also specify/also specifies/ > > s/all its/all of its/ > > s/If threshold/If the threshold/ > > s/explicitly set aside/explicitly excluded/ > > > > Thanks for these, request authors to handle them. > > Thanks! > Dhruv > > > Shawn. > > -- > --000000000000fb6a880590f4260c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Shawn/Dhruv,

Thanks for t= he review and clarifications, we have fixed all the editorial comments in n= ew version.

New Version:

Version Diff:

Regar= ds,
Mahendra


On Tue, Aug 20, 2019 at 11:= 14 AM Dhruv Dhody <dhruv.ietf@gm= ail.com> wrote:
Hi Shawn,

<adding WG>

Thanks for your security review and comments.

On Mon, Aug 19, 2019 at 6:17 AM Shawn Emery <shawn.emery@gmail.com> wrote:
>
> Reviewer: Shawn M. Emery
> Review result: Ready
>
> I have reviewed this document as part of the security directorate'= s
> ongoing effort to review all IETF documents being processed by the IES= G.
> These comments were written primarily for the benefit of the security<= br> > area directors. Document editors and WG chairs should treat these
> comments just like any other last call comments.
>
> This draft specifies an extension to the Path Computation Element comm= unication
> Protocol (PCE) that allows a PCE to request control of Label Switched = Paths (LSPs).
>
> The security considerations section does exist and discusses a new DoS= vector
> that this draft creates.=C2=A0 The attack involves sending control req= uests for delegate
> control of all of its LSPs to the Path Computation Client (PCC).=C2=A0= The proposed
> solution is to set a threshold rate of the delegation requests for the= PCC per PCE.
> I agree with the proposed solution, though I don't know if guidanc= e can be provided
> on what these thresholds would be per environment.
>

As you noted the document does not provide default for the threshold
as it dependent on the deployment/environment. The same is true for
RFC 8231.

> The section goes on to refer to RFC 8231 to justify that the PCP exten= sion should
> be deployed with authenticated and encrypted sessions in TLS using RFC= 8253.
> I agree with this prescription as well else an attacker would now be a= ble to take
> control over all local LSPs with this extension.=C2=A0 I think that th= is should at least be
> stated if an attacker is able to compromise a PCE.
>

The security consideration includes "...either by spoofing messages or=
by compromising the PCE itself".

> General comments:
>
> None.
>
> Editorial comments:
>
> s/sends PCRpt/sends a PCRpt/
> s/also specify/also specifies/
> s/all its/all of its/
> s/If threshold/If the threshold/
> s/explicitly set aside/explicitly excluded/
>

Thanks for these, request authors to handle them.

Thanks!
Dhruv

> Shawn.
> --
--000000000000fb6a880590f4260c-- From nobody Sun Aug 25 12:18:06 2019 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 D317912010C; Sun, 25 Aug 2019 12:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwdRP0KFsH6Y; Sun, 25 Aug 2019 12:17:53 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2754C120026; Sun, 25 Aug 2019 12:17:53 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id a21so23220589edt.11; Sun, 25 Aug 2019 12:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mz/fZqbzmfE7EnawcgrXjSqv0hfJbp9PWS1bXvFjxPo=; b=n7Nu34s80DfUsBGzNFdg0ps7Ns0IbBCGVadjeG/cs/CPXAqDexLjAtO1I2af0FDsLd 5fEudLyC7rAoxZgjPi5KkkQuaBaOL9KTHvvyvzpB689BgLOzSrNc3lX5XTeGzn+vfcHo vjL9a4wecLX/0i1guo+CezYYIr7I+vpGVUHKby/a/ngPde8jNMVcsIZ2J1PqwxYKgG5m v5N4kjVfyXhg4+XyA67QpJTN4jSe+ZK65peTn5stBjcxRt457jYt4nC/7sXGwdkfPH7x ZuJE4XtPfuJsoJWoVj6AS0LWMf/FoFpH9hh9yDCg78hUCPKoWYkWZl+XCiHB1vUTZ/Z7 ttRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mz/fZqbzmfE7EnawcgrXjSqv0hfJbp9PWS1bXvFjxPo=; b=La539IuIe5XP+Gp58R5zHEdf27kpLi2pccWvaW2djCxfRGn3n8uJRcmgUAJ5+LRmaj szteoqwjVjJ+kazfY0VGYwi4ZW71KxI5FSRxNCfCs+I3QOJ+yx+nBo8V9f4F6mnL5LTJ Z9VltIF6pThzOfbB9UZmC6rpOeSzLEqnEVNH7sivyMzfXA4QOk4NIT3YmHnq0Ns+JD8k 5K73MYnLe4SoMAqsbzDuSICwZQTx9Mvi5Jmr0kBwCQAXZiJ/Jz52CaugBFW8uWXNv5l4 4lLimEJr01QTO57B02SfFl1lU6Za183DOVffHd/zVCtFqm/8yTAwgTkUkf24pSN2IHuI xmwg== X-Gm-Message-State: APjAAAXXjdGttFr4SMXBA1zOD1riEN3gfu2WPqrxBUGpGSz1KJyM5tJo AF5de9BLZhvvjsS9GKK08HaAorgeBMvg1hLarHA= X-Google-Smtp-Source: APXvYqx6v3xJfe20+QsJHEDXGw7dDqQYOOJHPUXT0TqA5p7wqG5qwxqOMbAUrOkghYTu/EavH7nXr+BZ6tTZ4wXQWew= X-Received: by 2002:a17:906:135b:: with SMTP id x27mr13525037ejb.291.1566760671455; Sun, 25 Aug 2019 12:17:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Shawn Emery Date: Sun, 25 Aug 2019 13:17:39 -0600 Message-ID: To: Mahend Negi Cc: secdir , draft-ietf-pce-lsp-control-request.all@ietf.org, pce@ietf.org, Dhruv Dhody Content-Type: multipart/alternative; boundary="000000000000452e2e0590f5e562" Archived-At: Subject: Re: [secdir] Review of draft-ietf-pce-lsp-control-request-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 19:17:56 -0000 --000000000000452e2e0590f5e562 Content-Type: text/plain; charset="UTF-8" The changes look good. Thank you for the follow-up. Shawn. -- On Sun, Aug 25, 2019 at 11:13 AM Mahend Negi wrote: > Hi Shawn/Dhruv, > > Thanks for the review and clarifications, we have fixed all the editorial > comments in new version. > > New Version: > https://tools.ietf.org/html/draft-ietf-pce-lsp-control-request-08 > > Version Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-control-request-08 > > Regards, > Mahendra > > > On Tue, Aug 20, 2019 at 11:14 AM Dhruv Dhody wrote: > >> Hi Shawn, >> >> >> >> Thanks for your security review and comments. >> >> On Mon, Aug 19, 2019 at 6:17 AM Shawn Emery >> wrote: >> > >> > Reviewer: Shawn M. Emery >> > Review result: Ready >> > >> > 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 specifies an extension to the Path Computation Element >> communication >> > Protocol (PCE) that allows a PCE to request control of Label Switched >> Paths (LSPs). >> > >> > The security considerations section does exist and discusses a new DoS >> vector >> > that this draft creates. The attack involves sending control requests >> for delegate >> > control of all of its LSPs to the Path Computation Client (PCC). The >> proposed >> > solution is to set a threshold rate of the delegation requests for the >> PCC per PCE. >> > I agree with the proposed solution, though I don't know if guidance can >> be provided >> > on what these thresholds would be per environment. >> > >> >> As you noted the document does not provide default for the threshold >> as it dependent on the deployment/environment. The same is true for >> RFC 8231. >> >> > The section goes on to refer to RFC 8231 to justify that the PCP >> extension should >> > be deployed with authenticated and encrypted sessions in TLS using RFC >> 8253. >> > I agree with this prescription as well else an attacker would now be >> able to take >> > control over all local LSPs with this extension. I think that this >> should at least be >> > stated if an attacker is able to compromise a PCE. >> > >> >> The security consideration includes "...either by spoofing messages or >> by compromising the PCE itself". >> >> > General comments: >> > >> > None. >> > >> > Editorial comments: >> > >> > s/sends PCRpt/sends a PCRpt/ >> > s/also specify/also specifies/ >> > s/all its/all of its/ >> > s/If threshold/If the threshold/ >> > s/explicitly set aside/explicitly excluded/ >> > >> >> Thanks for these, request authors to handle them. >> >> Thanks! >> Dhruv >> >> > Shawn. >> > -- >> > --000000000000452e2e0590f5e562 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The changes look good.=C2=A0 Thank you for the follow-up.<= div>
Shawn.
--

On Sun, Aug 25, 2019 at 11:13 A= M Mahend Negi <mahend.ietf@gmai= l.com> wrote:
Hi Shawn/Dhruv,

Thanks = for the review and clarifications, we have fixed all the editorial comments= in new version.

New Version:

Version Diff:
<= a href=3D"https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-lsp-control-re= quest-08" rel=3D"noreferrer" target=3D"_blank">https://www.ietf.org/rfcdiff= ?url2=3Ddraft-ietf-pce-lsp-control-request-08

= Regards,
Mahendra


On Tue, Aug 20, 2019= at 11:14 AM Dhruv Dhody <dhruv.ietf@gmail.com> wrote:
Hi Shawn,

<adding WG>

Thanks for your security review and comments.

On Mon, Aug 19, 2019 at 6:17 AM Shawn Emery <shawn.emery@gmail.com> wrote:
>
> Reviewer: Shawn M. Emery
> Review result: Ready
>
> I have reviewed this document as part of the security directorate'= s
> ongoing effort to review all IETF documents being processed by the IES= G.
> These comments were written primarily for the benefit of the security<= br> > area directors. Document editors and WG chairs should treat these
> comments just like any other last call comments.
>
> This draft specifies an extension to the Path Computation Element comm= unication
> Protocol (PCE) that allows a PCE to request control of Label Switched = Paths (LSPs).
>
> The security considerations section does exist and discusses a new DoS= vector
> that this draft creates.=C2=A0 The attack involves sending control req= uests for delegate
> control of all of its LSPs to the Path Computation Client (PCC).=C2=A0= The proposed
> solution is to set a threshold rate of the delegation requests for the= PCC per PCE.
> I agree with the proposed solution, though I don't know if guidanc= e can be provided
> on what these thresholds would be per environment.
>

As you noted the document does not provide default for the threshold
as it dependent on the deployment/environment. The same is true for
RFC 8231.

> The section goes on to refer to RFC 8231 to justify that the PCP exten= sion should
> be deployed with authenticated and encrypted sessions in TLS using RFC= 8253.
> I agree with this prescription as well else an attacker would now be a= ble to take
> control over all local LSPs with this extension.=C2=A0 I think that th= is should at least be
> stated if an attacker is able to compromise a PCE.
>

The security consideration includes "...either by spoofing messages or=
by compromising the PCE itself".

> General comments:
>
> None.
>
> Editorial comments:
>
> s/sends PCRpt/sends a PCRpt/
> s/also specify/also specifies/
> s/all its/all of its/
> s/If threshold/If the threshold/
> s/explicitly set aside/explicitly excluded/
>

Thanks for these, request authors to handle them.

Thanks!
Dhruv

> Shawn.
> --
--000000000000452e2e0590f5e562-- From nobody Mon Aug 26 10:16:09 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8465412084E; Mon, 26 Aug 2019 10:16:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: draft-ietf-cdni-request-routing-extensions.all@ietf.org, ietf@ietf.org, cdni@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Linda Dunbar Message-ID: <156683976148.30653.13816124126977906406@ietfa.amsl.com> Date: Mon, 26 Aug 2019 10:16:01 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-cdni-request-routing-extensions-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 17:16:02 -0000 Reviewer: Linda Dunbar Review result: Has Nits 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 terminology RR (Request Router) and CP (Content Provider) specified by the Terminology are not used for the entire document. I assume that RR would be the one request content, isn't? is RR same as Client? Is RR part of Downstream CDN Provider? is the CP same as Downstream CDN provider or Upstream CDN Provider? who issued the Redirect Target? It would be good for the document to clearly specify the relationship of all the entities, such as who makes request and who respond, and who use the Redirect Target capability, etc. Thank you very much. Linda Dunbar From nobody Mon Aug 26 13:34:55 2019 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 48757120CF0 for ; Mon, 26 Aug 2019 13:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUlob0Bwy6bu for ; Mon, 26 Aug 2019 13:34:52 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9C012004D for ; Mon, 26 Aug 2019 13:34:51 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id f10so683539qkg.7 for ; Mon, 26 Aug 2019 13:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=G9QH4iFldqe77/C4KQH64rjdHhzNbEj0ujVfUaz9gzw=; b=17hBjENo7PYczx13zt0V5ulCr+xGZUsAGG8bg7+IjMR8rJllKIi5R7fZsObmIRxYc3 v0z5GoKVjt4LcBzCm+6zAjyWG/4/Yi9LO36CAH86W6B/mk1EpMIIiNMCfik9UgPgP1AU EFPfjeWrWkhET4cZ0r+FMzyb8IxUdn3fcWBwFu1I9jID7oHOXA2fQLyipGZ45bNmdQdq 6xbJaKjsTyIkNuTna97SmuzHsTzvptVpCjTO4aU5wsm20V21g57iVX6wX8/tGpDAGaIZ nYMMkXDCDFQm7FyMN+bfddEa9c9qH094221I8K9scEpHoyD9JPbzW3GVQl0vU4j7T3Yc htfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=G9QH4iFldqe77/C4KQH64rjdHhzNbEj0ujVfUaz9gzw=; b=TrpC790x5mRSgzcjEFgInCtpkNf9Qp7U15LXell/BtI7tA6JnAAnfkfuH7WHMxCpsW 9nOszcnFPP+3fdlCqpLOen7qVT0fOkZMv3fttC2dTETSgFOsL7Ve8v6x55q3P5007c92 mCWGoZ5LCsfo7RKjvbingJKL0HJlPJcwkNdoBnD2wScdkzP1Dv7WeEOCpuRkifxeedkm ekKwQXAmxVbFmY0jFlfoKv9easg+Vk7t0ISDFXPqtUMOzowsuFDsPwryPa2GHeDofW1X JUtMk37r6D9XHQian9cidJrFwfamY6gH0clKcKVkurgPOFnVqnDNedGTQcj3RiENpPYi 0Jxg== X-Gm-Message-State: APjAAAVCHgdzI7jNvDzAPp3Iab1jB+wag3Xubem3WNqo0ylDLsi446Je S2RbfTqulpAYnc6BDDvs1lG8DA== X-Google-Smtp-Source: APXvYqzTM0YWioaYz2Mywh/36dhPpaCCb+B38WXTTm0CkXJ/NgcVK2G+FXRvpG3sNnKBWwMzlIPyiQ== X-Received: by 2002:a37:9b48:: with SMTP id d69mr18733327qke.449.1566851690724; Mon, 26 Aug 2019 13:34:50 -0700 (PDT) Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id 145sm7134511qkm.1.2019.08.26.13.34.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Aug 2019 13:34:50 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_26D64576-1C1A-4C42-AB7C-6D56AFA05284" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 26 Aug 2019 16:34:49 -0400 In-Reply-To: Cc: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ecrit-data-only-ea.all@ietf.org" To: Charlie Kaufman References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 20:34:54 -0000 --Apple-Mail=_26D64576-1C1A-4C42-AB7C-6D56AFA05284 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Charlie Thanks for the review, I appreciate it. The introduction section has this text Data-only emergency calls are similar to regular emergency calls in the sense that they require the emergency indications, emergency call routing functionality and may even have the same location requirements. However, the communication interaction will not lead to the exchange of interactive media, that is, Real-Time Protocol packets, such as voice, video data or real-time text. ... This document describes a method of including a CAP message in a SIP transaction by defining it as a block of "additional data" as defined in [RFC7852 ]. The CAP message = is included either by value (the CAP message is in the body of the message, using a CID) or by reference (a URI is included in the message, which when dereferenced returns the CAP message). The additional data mechanism is also used to send alert specific data beyond that available in the CAP message. This document also describes how a SIP MESSAGE [RFC3428 = ] transaction can be used to send a data-only call. This says that this document describes how to send an emergency call = when there is not two way interactive media (voice, video and/or text), = and it says that the way you do that is to send a SIP MESSAGE, with a = CAP message pointed to by a Call-Info header. That text seems very clear to me, and yet you didn=E2=80=99t read what = we hoped into what we wrote. I would really like to fix this, but I=E2=80= =99m at a loss to understand what I need to do. I=E2=80=99ll improve the acronym stuff. > On Aug 24, 2019, at 3:53 PM, Charlie Kaufman = wrote: >=20 > 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. >=20 > This document defines a new MIME type: = 'application/EmergencyCallData.cap+xml' for use primarily by sensors to = send alert messages to emergency services providers. It also defines a = new Emergency Call Data Type: 'cap' in order to embed this data = efficiently in a SIP transaction. I saw no new security issues beyond = those already noted for the protocols carrying these messages. >=20 > I do have some editorial suggestions: >=20 > There is a lot of context that the authors assumed any reader would = have that could have been stated in the introduction. I believe from = context that the purpose of this new MIME type is to support simple = (IoT) sensors that don't want to implement a more heavyweight protocol, = but I don't believe that was stated anywhere. >=20 > I got the impression that the functionality provided could have been = done with existing protocols by sending the CAP message over a SIP = session, but that doing so would place an unnecessary burden on simple = (IoT) sensors, and that this protocol would be easier for such sensors = to implement for the limited cases such sensors need to deal with. If = that's true, it should be stated. If not, the purpose of this protocol = should be more clearly stated. >=20 > These acronyms were used but never defined: >=20 > SIP > CID > LoST >=20 > These acronyms were expanded, but not in an easy to find place: >=20 > Common Alerting Protocol (CAP) > Public Safety Answering Points (PSAPs) > Emergency Services Routing Proxy (ESRP) >=20 > It would be nice to include them in the terminology section, ideally = with a reference to the RFC where more information is available. >=20 > Typo: >=20 > p17 "security mechanism" -> "security mechanisms" >=20 > --Charlie --Apple-Mail=_26D64576-1C1A-4C42-AB7C-6D56AFA05284 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Charlie

Thanks for = the review, I appreciate it.

The introduction section has this = text
   Data-only emergency =
calls are similar to regular emergency calls in
   the sense that they require the emergency indications, emergency call
   routing functionality and may even have the same location
   requirements.  However, the communication interaction will not lead
   to the exchange of interactive media, that is, Real-Time Protocol
   packets, such as voice, video data or real-time text.

   ...

   This document describes a method of including a CAP message in a SIP
   transaction by defining it as a block of "additional data" as defined
   in [RFC7852].  The CAP message is included either by value =
(the CAP
   message is in the body of the message, using a CID) or by reference
   (a URI is included in the message, which when dereferenced returns
   the CAP message).  The additional data mechanism is also used to send
   alert specific data beyond that available in the CAP message.  This
   document also describes how a SIP MESSAGE [RFC3428] transaction can
   be used to send a data-only call.


This says that this document describes how to send an = emergency call when there is not two way interactive media (voice, video = and/or text), and it says that the way you do that is to send a SIP = MESSAGE, with a CAP message pointed to by a Call-Info header.

That text seems very = clear to me, and yet you didn=E2=80=99t read what we hoped into what we = wrote.  I would really like to fix this, but I=E2=80=99m at a loss = to understand what I need to do.

I=E2=80=99ll improve the acronym = stuff.


On Aug 24, 2019, at 3:53 PM, = Charlie Kaufman <charliekaufman@outlook.com> 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 defines a new MIME type: = 'application/EmergencyCallData.cap+xml' for use primarily by sensors to = send alert messages to emergency services providers. It also defines a = new Emergency Call Data Type: 'cap' in order to embed this data = efficiently in a SIP transaction. I saw no new security issues beyond = those already noted for the protocols carrying these messages.

I do have some editorial = suggestions:

There is a lot of context that the authors assumed any reader = would have that could have been stated in the introduction. I believe = from context that the purpose of this new MIME type is to support simple = (IoT) sensors that don't want to implement a more heavyweight protocol, = but I don't believe that was stated anywhere.

I got the impression that the = functionality provided could have been done with existing protocols by = sending the CAP message over a SIP session, but that doing so would = place an unnecessary burden on simple (IoT) sensors, and that this = protocol would be easier for such sensors to implement for the limited = cases such sensors need to deal with. If that's true, it should be = stated. If not, the purpose of this protocol should be more clearly = stated.

These = acronyms were used but never defined:

SIP
CID
LoST

These acronyms were expanded, but not in an easy to find = place:

Common = Alerting Protocol (CAP)
Public Safety Answering Points = (PSAPs)
Emergency Services Routing Proxy (ESRP)

It would be nice to = include them in the terminology section, ideally with a reference to the = RFC where more information is available.

Typo:

p17 "security mechanism" -> = "security mechanisms"

 --Charlie

= --Apple-Mail=_26D64576-1C1A-4C42-AB7C-6D56AFA05284-- From nobody Mon Aug 26 15:10:57 2019 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 891E812001A; Mon, 26 Aug 2019 15:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyVLUmLNOvua; Mon, 26 Aug 2019 15:10:34 -0700 (PDT) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53877120013; Mon, 26 Aug 2019 15:10:30 -0700 (PDT) Received: by mail-lj1-x243.google.com with SMTP id m24so16521329ljg.8; Mon, 26 Aug 2019 15:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JGW00s4H2qgmzOAKgOA/N2wrwAzMgx17Kd7bF3O+7T8=; b=SDvnxa5ix6xKfD7X+ET05BGsJdlt0O3rFaNLAHbTsNZWa+hdggwpAHtbMq9q5xNRT7 MpvrCHiVAzf+Ru33Z94DXXLM4SfQFi2N/gan25C6BXKUkZNydKnRXtk+QeS8su2y/fAm HdutWMgmmWoMimzsdLgHuzVmZzzv8sZQzdekLT/A++pNiOIZsmjICzus7ShtBsQhkT3x rqXokjdI7FbL4XyetOkXTfzwrueTomojpoQwSGw7K+/Xux58JyHYZWvNdLO6HWh+s2bG 8KhWSwh5DQ8O9qdxkc7wCzVGVmVQD3DO8hVOocsWXNb4BaJWwEwKqoMZcFZJ2pMz6tVy xefA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JGW00s4H2qgmzOAKgOA/N2wrwAzMgx17Kd7bF3O+7T8=; b=LSHAexUW+r/IPjJTi3e6ccaZPBxY28sn+nA3rnxPi1bPF3NwttDAV+8VFvXTux28GA UQz67BJ5awSID5KBf/bYgdN7io8pzio3Bw0P5WDHF0zIEH10fWmhL1EWfwgWD/u3Secy 2PJ2glg6v51JcHC1q2P1UNRWSLyR5eNA+MLhwZc0mkhHQGgqhuPTR+DiuGz/lc5mBQ7o ltCCq3Rga+ArAfGyaOjJ3tIxt98gWBSv/E9rsphwgzNcEoXv8bnXeXa0DCIlzQ6usFkU WsjPJX/xkZ5Sm1xyjun3AGmPhEvvvNwq5f7trYVt6zVMVqpBDUERfLa2MgGbK2qh5c3x aEOA== X-Gm-Message-State: APjAAAVsjuwKrFhC4tmK3ViSIr+49biNDF4qoDrXbvyZrb3kmL2WQOvS 70Wk7LlNQy8CG0BMVPJ4OPMleUiE4v8nCMFDLmQ= X-Google-Smtp-Source: APXvYqymF6vRKwwYW7N4vkgYx01NY7F+/fRqVTTq3jhUcFDlCtySsAJ39t7epUhz699IB6UdfE8LErveMhuy559n24g= X-Received: by 2002:a2e:7c12:: with SMTP id x18mr12185437ljc.100.1566857427872; Mon, 26 Aug 2019 15:10:27 -0700 (PDT) MIME-Version: 1.0 References: <156649425577.14757.13703548347532993926@ietfa.amsl.com> In-Reply-To: <156649425577.14757.13703548347532993926@ietfa.amsl.com> From: Greg Mirsky Date: Mon, 26 Aug 2019 15:10:15 -0700 Message-ID: To: Russ Housley Cc: secdir@ietf.org, draft-ietf-ippm-stamp.all@ietf.org, IETF list , IETF IPPM WG Content-Type: multipart/mixed; boundary="000000000000681d2605910c6cc6" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ippm-stamp-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 22:10:40 -0000 --000000000000681d2605910c6cc6 Content-Type: multipart/alternative; boundary="000000000000681d2305910c6cc4" --000000000000681d2305910c6cc4 Content-Type: text/plain; charset="UTF-8" Hi Russ, thank you for your review, comments, and suggestions. Please find my notes in-lined under GIM>> tag. Also, please find the diff and the working version of the draft attached. Regards, Greg On Thu, Aug 22, 2019 at 10:17 AM Russ Housley via Datatracker < noreply@ietf.org> wrote: > Reviewer: Russ Housley > Review result: Has Issues > > 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 authors, document editors, and WG chairs should > treat these comments just like any other IETF Last Call comments. > > Document: draft-ietf-ippm-stamp-07 > Reviewer: Russ Housley > Review Date: 2019-08-22 > IETF LC End Date: 2019-09-03 > IESG Telechat date: unknown > > Summary: Has Issues > > > Major Concerns: > > Section 4.1.1: This paragraph is a bit surprising: > > The STAMP Session-Sender and Session-Reflector MAY use, not use, > or set value of the Z field in accordance with the timestamp > format in use. This optional field is to enhance operations, but > local configuration or defaults could be used in its place. > > Why not have this bit set to align with the bits that actually appear > in the packet? GIM>> The use of the Z bit to indicate the format of the timestamp used by TWAMP test nodes has been described in RFC 8186 . The value of the Z flag is set by the Session-Sender and the Session-Reflector independently to reflect the format of timestamp that each of them respectively uses. The Z flag is part of the Error Estimate field and thus is part of the STAMP test packet transmitted by the Session-Sender and the packet reflected by the Session-Reflector. > This is especially worrisome because of the text that > come later (Section 4.2.1), which says: > > o Timestamp and Receiver Timestamp fields are each eight octets > long. The format of these fields, NTP or PTPv2, indicated by the > Z flag of the Error Estimate field as described in Section 4.1. > > If the Z field (or Z flag) is not really meaningful, I do not see how > the peer knows how to interpret a received timestamp. > GIM>> A Session-Reflector would not interpret the value of the Z flag (will convert to "Z flag") but only the Session-Sender will use the value in the Error Estimate field on the reflected packet to correctly interpret the values in the Receive Timestamp and Timestamp fields. (The Session-Sender Timestamp is the copy of the timestamp set by the Session-Sender and is expected to be processed correctly.) > > > Section 4.3: Please divide this into two sections. First, you have > picked a single mechanism for authentication (HMAC-SHA-256 truncated > to 128 bits). This choice seems fine to me, even though you are not > saying much about the key management. I would prefer that you have > a mandatory to implement key management technique, but allow others; > however, I am not going to insist on that. Then, a separate section > should talk about confidentiality protection. > > > Section 4.3: This text needs work: > > If confidentiality protection for STAMP is required, encryption at > the higher level MUST be used. For example, STAMP packets could be > transmitted in the dedicated IPsec tunnel or share the IPsec tunnel > with the monitored flow. > > I find "at the higher level" very unclear. I believe that IPsec would > be below this protocol. > > I think that DTLS would also provide the confidentiality protection > that you desire. Since you are not specifying any details of the > encryption, you can say that a "secured transport" (the term that you > use in the Security Considerations) such as IPsec or DTLS can be used. > GIM>> Thank you for the suggestions. Renamed Section 4.3 in Integrity Protection in STAMP, and added the new section: NEW TEXT: 4.4. Confidentiality Protection in STAMP If confidentiality protection for STAMP is required, a STAMP test session MUST use a secured transport. For example, STAMP packets could be transmitted in the dedicated IPsec tunnel or share the IPsec tunnel with the monitored flow. Also, Datagram Transport Layer Security protocol would provide the desired confidentiality protection. > > Minor Concerns: > > Section 1: I do not follow this topic, and this may be clear to your > expected reader, but it is not clear to me. The Introduction does not > tell me the relationship of TWAMP Light and [BBF.TR-390] to this > document. One possible way to resolve this is to divide the section > into four parts: (1) background and history of measurement protocols; > (2) shortcoming of those protocols; (3) what this document does to > resolve those shortcomings; and (4) pointers to other documents that > make up the rest of the shortcoming resolution. > GIM>> Thank you for your suggestions. Split the section into four paragraphs. Hopefully the text is more clear now: 1. Introduction Development and deployment of Two-Way Active Measurement Protocol (TWAMP) [RFC5357] and its extensions, e.g., [RFC6038] that defined features such as Reflect Octets and Symmetrical Size for TWAMP provided invaluable experience. Several independent implementations of both TWAMP and TWAMP Light exist, have been deployed, and provide important operational performance measurements. At the same time, there has been noticeable interest in using a more straightforward mechanism for active performance monitoring that can provide deterministic behavior and inherit separation of control (vendor-specific configuration or orchestration) and test functions. Recent work on IP Edge to Customer Equipment using TWAMP Light from Broadband Forum [BBF.TR-390] demonstrated that interoperability among implementations of TWAMP Light is challenged because the composition and operation of TWAMP Light were not sufficiently specified in [RFC5357]. According to [RFC8545], TWAMP Light includes sub-set of Mirsky, et al. Expires February 27, 2020 [Page 2] Internet-Draft STAMP August 2019 TWAMP-Test functions to provide comprehensive solution requires support by other applications that provide, for example, control and security. This document defines an active performance measurement test protocol, Simple Two-way Active Measurement Protocol (STAMP), that enables measurement of both one-way and round-trip performance metrics like delay, delay variation, and packet loss. Some TWAMP extensions, e.g., [RFC7750] are supported by the extensions to STAMP base specification in [I-D.ietf-ippm-stamp-option-tlv]. > > > > Nits: > > The document uses "Z field" and "Z flag". Please pick one and use it > throughout the document. > GIM>> Settled on "Z flag". > > These terms are defined in Section 2.1, but they are not used in the > rest of the document: > > AES Advanced Encryption Standard > > CBC Cipher Block Chaining > > ECB Electronic Cookbook > > KEK Key-encryption Key > GIM>> Cleared them all. --000000000000681d2305910c6cc4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Russ,
thank you for your review, c= omments, and suggestions. Please find my notes in-lined under GIM>> t= ag.
Also, please find the diff and the working version of the dra= ft attached.

Regards,
Greg
On Thu, = Aug 22, 2019 at 10:17 AM Russ Housley via Datatracker <noreply@ietf.org> wrote:
Reviewer: Russ Housley=
Review result: Has Issues

I reviewed this document as part of the Security Directorate's ongoing<= br> effort to review all IETF documents being processed by the IESG.=C2=A0 Thes= e
comments were written primarily for the benefit of the Security Area
Directors.=C2=A0 Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments.

Document: draft-ietf-ippm-stamp-07
Reviewer: Russ Housley
Review Date: 2019-08-22
IETF LC End Date: 2019-09-03
IESG Telechat date: unknown

Summary: Has Issues


Major Concerns:

Section 4.1.1: This paragraph is a bit surprising:

=C2=A0 =C2=A0 =C2=A0 The STAMP Session-Sender and Session-Reflector MAY use= , not use,
=C2=A0 =C2=A0 =C2=A0 or set value of the Z field in accordance with the tim= estamp
=C2=A0 =C2=A0 =C2=A0 format in use.=C2=A0 This optional field is to enhance= operations, but
=C2=A0 =C2=A0 =C2=A0 local configuration or defaults could be used in its p= lace.

Why not have this bit set to align with the bits that actually appear
in the packet?=C2=A0
GIM>> The use of the Z bit to = indicate the format of the timestamp used by TWAMP=C2=A0 test nodes has bee= n described in RFC 8186. The value of the Z flag is set by the Session-Sen= der and the Session-Reflector independently to reflect the format of timest= amp that each of them respectively uses. The Z flag is part of the Error Es= timate field and thus is part of the STAMP test packet transmitted by the S= ession-Sender and the packet reflected by the Session-Reflector.
This is especially worrisome b= ecause of the text that
come later (Section 4.2.1), which says:

=C2=A0 =C2=A0o=C2=A0 Timestamp and Receiver Timestamp fields are each eight= octets
=C2=A0 =C2=A0 =C2=A0 long.=C2=A0 The format of these fields, NTP or PTPv2, = indicated by the
=C2=A0 =C2=A0 =C2=A0 Z flag of the Error Estimate field as described in Sec= tion 4.1.

If the Z field (or Z flag) is not really meaningful, I do not see how
the peer knows how to interpret a received timestamp.
= GIM>> A Session-Reflector would not interpret the value of the Z flag= (will convert to "Z flag") but only the Session-Sender will
use the value in the Error Estimate field on the reflected packet to = correctly interpret the values in the Receive Timestamp and Timestamp field= s. (The Session-Sender Timestamp is the copy of the timestamp set by the Se= ssion-Sender and is expected to be processed correctly.)


Section 4.3:=C2=A0 Please divide this into two sections.=C2=A0 First, you h= ave
picked a single mechanism for authentication (HMAC-SHA-256 truncated
to 128 bits).=C2=A0 This choice seems fine to me, even though you are not saying much about the key management.=C2=A0 I would prefer that you have a mandatory to implement key management technique, but allow others;
however, I am not going to insist on that.=C2=A0 Then, a separate section should talk about confidentiality protection.


Section 4.3:=C2=A0 This text needs work:

=C2=A0 =C2=A0If confidentiality protection for STAMP is required, encryptio= n at
=C2=A0 =C2=A0the higher level MUST be used.=C2=A0 For example, STAMP packet= s could be
=C2=A0 =C2=A0transmitted in the dedicated IPsec tunnel or share the IPsec t= unnel
=C2=A0 =C2=A0with the monitored flow.

I find "at the higher level" very unclear.=C2=A0 I believe that I= Psec would
be below this protocol.

I think that DTLS would also provide the confidentiality protection
that you desire.=C2=A0 Since you are not specifying any details of the
encryption, you can say that a "secured transport" (the term that= you
use in the Security Considerations) such as IPsec or DTLS can be used.
<= /blockquote>
GIM>> Thank you for the suggestions. Renamed Section= 4.3 in Integrity Protection in STAMP, and added the new section:
NEW TEXT:
4.4.=C2=A0 Confidentiality Protection in STAMP

= =C2=A0 =C2=A0If confidentiality protection for STAMP is required, a STAMP t= est
=C2=A0 =C2=A0session MUST use a secured transport.=C2=A0 For example= , STAMP packets
=C2=A0 =C2=A0could be transmitted in the dedicated IPsec= tunnel or share the IPsec
=C2=A0 =C2=A0tunnel with the monitored flow.= =C2=A0 Also, Datagram Transport Layer
=C2=A0 =C2=A0Security protocol wou= ld provide the desired confidentiality
=C2=A0 =C2=A0protection.



Minor Concerns:

Section 1:=C2=A0 I do not follow this topic, and this may be clear to your<= br> expected reader, but it is not clear to me.=C2=A0 The Introduction does not=
tell me the relationship of TWAMP Light and [BBF.TR-390] to this
document.=C2=A0 One possible way to resolve this is to divide the section into four parts: (1) background and history of measurement protocols;
(2) shortcoming of those protocols; (3) what this document does to
resolve those shortcomings; and (4) pointers to other documents that
make up the rest of the shortcoming resolution.
GIM>= ;> Thank you for your suggestions. Split the section into four paragraph= s. Hopefully the text is more clear now:
=C2=A01.=C2=A0 Introduct= ion

=C2=A0 =C2=A0Development and deployment of Two-Way Active Meas= urement Protocol
=C2=A0 =C2=A0(TWAMP) [RFC5357] and its extensions, e.g.= , [RFC6038] that defined
=C2=A0 =C2=A0features such as Reflect Octets an= d Symmetrical Size for TWAMP
=C2=A0 =C2=A0provided invaluable experience= .=C2=A0 Several independent implementations
=C2=A0 =C2=A0of both TWAMP a= nd TWAMP Light exist, have been deployed, and provide
=C2=A0 =C2=A0impor= tant operational performance measurements.

=C2=A0 =C2=A0At the same = time, there has been noticeable interest in using a more
=C2=A0 =C2=A0st= raightforward mechanism for active performance monitoring that can
=C2= =A0 =C2=A0provide deterministic behavior and inherit separation of control<= br>=C2=A0 =C2=A0(vendor-specific configuration or orchestration) and test f= unctions.
=C2=A0 =C2=A0Recent work on IP Edge to Customer Equipment usin= g TWAMP Light from
=C2=A0 =C2=A0Broadband Forum [BBF.TR-390] demonstrate= d that interoperability among
=C2=A0 =C2=A0implementations of TWAMP Ligh= t is challenged because the composition
=C2=A0 =C2=A0and operation of TW= AMP Light were not sufficiently specified in
=C2=A0 =C2=A0[RFC5357].=C2= =A0 According to [RFC8545], TWAMP Light includes sub-set of



= Mirsky, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires February 27, 2020 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 2]
=0C
Interne= t-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0STAMP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0August 2019


=C2=A0 =C2=A0TWAMP-Test functions to provi= de comprehensive solution requires
=C2=A0 =C2=A0support by other applica= tions that provide, for example, control and
=C2=A0 =C2=A0security.
<= br>=C2=A0 =C2=A0This document defines an active performance measurement tes= t
=C2=A0 =C2=A0protocol, Simple Two-way Active Measurement Protocol (STA= MP), that
=C2=A0 =C2=A0enables measurement of both one-way and round-tri= p performance
=C2=A0 =C2=A0metrics like delay, delay variation, and pack= et loss.=C2=A0 Some TWAMP
=C2=A0 =C2=A0extensions, e.g., [RFC7750] are s= upported by the extensions to STAMP
=C2=A0 =C2=A0base specification in [= I-D.ietf-ippm-stamp-option-tlv].


Nits:

The document uses "Z field" and "Z flag".=C2=A0 Please = pick one and use it
throughout the document.
GIM>> Settled on "= Z flag".=C2=A0

These terms are defined in Section 2.1, but they are not used in the
rest of the document:

=C2=A0 =C2=A0AES Advanced Encryption Standard

=C2=A0 =C2=A0CBC Cipher Block Chaining

=C2=A0 =C2=A0ECB Electronic Cookbook

=C2=A0 =C2=A0KEK Key-encryption Key
GIM>> Cleare= d them all.=C2=A0
--000000000000681d2305910c6cc4-- --000000000000681d2605910c6cc6 Content-Type: text/plain; charset="US-ASCII"; name="draft-ietf-ippm-stamp-08.txt" Content-Disposition: attachment; filename="draft-ietf-ippm-stamp-08.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jzsyg3pk1 CgoKCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEcuIE1pcnNreQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBaVEUgQ29ycC4KSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRy4gSnVuCkV4cGly ZXM6IEZlYnJ1YXJ5IDI3LCAyMDIwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFpURSBD b3Jwb3JhdGlvbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBILiBOeWRlbGwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEFjY2VkaWFuIE5ldHdvcmtzCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBGb290 ZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTm9raWEKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQXVndXN0IDI2LCAyMDE5CgoKICAgICAgICAgICAgICAgU2ltcGxl IFR3by13YXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sCiAgICAgICAgICAgICAgICAgICAg ICAgIGRyYWZ0LWlldGYtaXBwbS1zdGFtcC0wOAoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIGEgU2ltcGxlIFR3by13YXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sCiAg IHdoaWNoIGVuYWJsZXMgdGhlIG1lYXN1cmVtZW50IG9mIGJvdGggb25lLXdheSBhbmQgcm91bmQt dHJpcAogICBwZXJmb3JtYW5jZSBtZXRyaWNzIGxpa2UgZGVsYXksIGRlbGF5IHZhcmlhdGlvbiwg YW5kIHBhY2tldCBsb3NzLgoKU3RhdHVzIG9mIFRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1E cmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNp b25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5n IGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVU RikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2lu ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRl cm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRz L2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQg Zm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFj ZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBp cyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1h dGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIK CiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gRmVicnVhcnkgMjcsIDIwMjAu CgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMTkgSUVURiBUcnVzdCBhbmQg dGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCBy aWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFu ZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBE b2N1bWVudHMKICAgKGh0dHBzOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVm ZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxl YXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJl IHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9j dW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0 CgoKCk1pcnNreSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjcsIDIwMjAgICAg ICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBT VEFNUCAgICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxOQoKCiAgIGluY2x1ZGUgU2ltcGxp ZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgogICB0 aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFu dHkgYXMKICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoKVGFibGUg b2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMgogICAyLiAgQ29udmVudGlvbnMgdXNlZCBpbiB0 aGlzIGRvY3VtZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgICAyLjEuICBU ZXJtaW5vbG9neSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICAzCiAgICAgMi4yLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgMwogICAzLiAgU29mdHdhcml6YXRpb24gb2YgUGVyZm9ybWFuY2Ug TWVhc3VyZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgNC4gIFRoZW9yeSBvZiBPcGVy YXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgICAg NC4xLiAgU2Vzc2lvbi1TZW5kZXIgQmVoYXZpb3IgYW5kIFBhY2tldCBGb3JtYXQgLiAuIC4gLiAu IC4gLiAuICAgNQogICAgICAgNC4xLjEuICBTZXNzaW9uLVNlbmRlciBQYWNrZXQgRm9ybWF0IGlu IFVuYXV0aGVudGljYXRlZCBNb2RlICAgIDUKICAgICAgIDQuMS4yLiAgU2Vzc2lvbi1TZW5kZXIg UGFja2V0IEZvcm1hdCBpbiBBdXRoZW50aWNhdGVkIE1vZGUgIC4gICA2CiAgICAgNC4yLiAgU2Vz c2lvbi1SZWZsZWN0b3IgQmVoYXZpb3IgYW5kIFBhY2tldCBGb3JtYXQgIC4gLiAuIC4gLiAuICAg NwogICAgICAgNC4yLjEuICBTZXNzaW9uLVJlZmxlY3RvciBQYWNrZXQgRm9ybWF0IGluIFVuYXV0 aGVudGljYXRlZAogICAgICAgICAgICAgICBNb2RlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgKICAgICAgIDQuMi4yLiAgU2Vzc2lvbi1SZWZsZWN0 b3IgUGFja2V0IEZvcm1hdCBpbiBBdXRoZW50aWNhdGVkIE1vZGUgICA5CiAgICAgNC4zLiAgSW50 ZWdyaXR5IFByb3RlY3Rpb24gaW4gU1RBTVAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx MAogICAgIDQuNC4gIENvbmZpZGVudGlhbGl0eSBQcm90ZWN0aW9uIGluIFNUQU1QIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMTEKICAgICA0LjUuICBJbnRlcm9wZXJhYmlsaXR5IHdpdGggVFdBTVAg TGlnaHQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExCiAgIDUuICBJQU5BIENvbnNpZGVyYXRp b25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMgogICA2LiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTIKICAgNy4gIEFja25vd2xlZGdtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyCiAgIDguICBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMwogICAgIDguMS4gIE5vcm1h dGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTMK ICAgICA4LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDE0CiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNQoKMS4gIEludHJvZHVjdGlvbgoKICAgRGV2 ZWxvcG1lbnQgYW5kIGRlcGxveW1lbnQgb2YgVHdvLVdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJv dG9jb2wKICAgKFRXQU1QKSBbUkZDNTM1N10gYW5kIGl0cyBleHRlbnNpb25zLCBlLmcuLCBbUkZD NjAzOF0gdGhhdCBkZWZpbmVkCiAgIGZlYXR1cmVzIHN1Y2ggYXMgUmVmbGVjdCBPY3RldHMgYW5k IFN5bW1ldHJpY2FsIFNpemUgZm9yIFRXQU1QCiAgIHByb3ZpZGVkIGludmFsdWFibGUgZXhwZXJp ZW5jZS4gIFNldmVyYWwgaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRpb25zCiAgIG9mIGJvdGggVFdB TVAgYW5kIFRXQU1QIExpZ2h0IGV4aXN0LCBoYXZlIGJlZW4gZGVwbG95ZWQsIGFuZCBwcm92aWRl CiAgIGltcG9ydGFudCBvcGVyYXRpb25hbCBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudHMuCgogICBB dCB0aGUgc2FtZSB0aW1lLCB0aGVyZSBoYXMgYmVlbiBub3RpY2VhYmxlIGludGVyZXN0IGluIHVz aW5nIGEgbW9yZQogICBzdHJhaWdodGZvcndhcmQgbWVjaGFuaXNtIGZvciBhY3RpdmUgcGVyZm9y bWFuY2UgbW9uaXRvcmluZyB0aGF0IGNhbgogICBwcm92aWRlIGRldGVybWluaXN0aWMgYmVoYXZp b3IgYW5kIGluaGVyaXQgc2VwYXJhdGlvbiBvZiBjb250cm9sCiAgICh2ZW5kb3Itc3BlY2lmaWMg Y29uZmlndXJhdGlvbiBvciBvcmNoZXN0cmF0aW9uKSBhbmQgdGVzdCBmdW5jdGlvbnMuCiAgIFJl Y2VudCB3b3JrIG9uIElQIEVkZ2UgdG8gQ3VzdG9tZXIgRXF1aXBtZW50IHVzaW5nIFRXQU1QIExp Z2h0IGZyb20KICAgQnJvYWRiYW5kIEZvcnVtIFtCQkYuVFItMzkwXSBkZW1vbnN0cmF0ZWQgdGhh dCBpbnRlcm9wZXJhYmlsaXR5IGFtb25nCiAgIGltcGxlbWVudGF0aW9ucyBvZiBUV0FNUCBMaWdo dCBpcyBjaGFsbGVuZ2VkIGJlY2F1c2UgdGhlIGNvbXBvc2l0aW9uCiAgIGFuZCBvcGVyYXRpb24g b2YgVFdBTVAgTGlnaHQgd2VyZSBub3Qgc3VmZmljaWVudGx5IHNwZWNpZmllZCBpbgogICBbUkZD NTM1N10uICBBY2NvcmRpbmcgdG8gW1JGQzg1NDVdLCBUV0FNUCBMaWdodCBpbmNsdWRlcyBzdWIt c2V0IG9mCgoKCk1pcnNreSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjcsIDIw MjAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgICBTVEFNUCAgICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxOQoKCiAgIFRXQU1QLVRl c3QgZnVuY3Rpb25zIHRvIHByb3ZpZGUgY29tcHJlaGVuc2l2ZSBzb2x1dGlvbiByZXF1aXJlcwog ICBzdXBwb3J0IGJ5IG90aGVyIGFwcGxpY2F0aW9ucyB0aGF0IHByb3ZpZGUsIGZvciBleGFtcGxl LCBjb250cm9sIGFuZAogICBzZWN1cml0eS4KCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBh Y3RpdmUgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgdGVzdAogICBwcm90b2NvbCwgU2ltcGxlIFR3 by13YXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sIChTVEFNUCksIHRoYXQKICAgZW5hYmxl cyBtZWFzdXJlbWVudCBvZiBib3RoIG9uZS13YXkgYW5kIHJvdW5kLXRyaXAgcGVyZm9ybWFuY2UK ICAgbWV0cmljcyBsaWtlIGRlbGF5LCBkZWxheSB2YXJpYXRpb24sIGFuZCBwYWNrZXQgbG9zcy4g IFNvbWUgVFdBTVAKICAgZXh0ZW5zaW9ucywgZS5nLiwgW1JGQzc3NTBdIGFyZSBzdXBwb3J0ZWQg YnkgdGhlIGV4dGVuc2lvbnMgdG8gU1RBTVAKICAgYmFzZSBzcGVjaWZpY2F0aW9uIGluIFtJLUQu aWV0Zi1pcHBtLXN0YW1wLW9wdGlvbi10bHZdLgoKMi4gIENvbnZlbnRpb25zIHVzZWQgaW4gdGhp cyBkb2N1bWVudAoKMi4xLiAgVGVybWlub2xvZ3kKCiAgIFNUQU1QIC0gU2ltcGxlIFR3by13YXkg QWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sCgogICBOVFAgLSBOZXR3b3JrIFRpbWUgUHJvdG9j b2wKCiAgIFBUUCAtIFByZWNpc2lvbiBUaW1lIFByb3RvY29sCgogICBITUFDIEhhc2hlZCBNZXNz YWdlIEF1dGhlbnRpY2F0aW9uIENvZGUKCiAgIE9XQU1QIE9uZS1XYXkgQWN0aXZlIE1lYXN1cmVt ZW50IFByb3RvY29sCgogICBUV0FNUCBUd28tV2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2Nv bAoKICAgTUJaIE1heSBiZSBaZXJvCgoyLjIuICBSZXF1aXJlbWVudHMgTGFuZ3VhZ2UKCiAgIFRo ZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hB TEwgTk9UIiwKICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk5PVCBS RUNPTU1FTkRFRCIsICJNQVkiLCBhbmQKICAgIk9QVElPTkFMIiBpbiB0aGlzIGRvY3VtZW50IGFy ZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gQkNQCiAgIDE0IFtSRkMyMTE5XSBb UkZDODE3NF0gd2hlbiwgYW5kIG9ubHkgd2hlbiwgdGhleSBhcHBlYXIgaW4gYWxsCiAgIGNhcGl0 YWxzLCBhcyBzaG93biBoZXJlLgoKMy4gIFNvZnR3YXJpemF0aW9uIG9mIFBlcmZvcm1hbmNlIE1l YXN1cmVtZW50CgogICBGaWd1cmUgMSBwcmVzZW50cyB0aGUgU2ltcGxlIFR3by13YXkgQWN0aXZl IE1lYXN1cmVtZW50IFByb3RvY29sCiAgIChTVEFNUCkgU2Vzc2lvbi1TZW5kZXIsIGFuZCBTZXNz aW9uLVJlZmxlY3RvciB3aXRoIGEgbWVhc3VyZW1lbnQKICAgc2Vzc2lvbi4gIFRoZSBjb25maWd1 cmF0aW9uIGFuZCBtYW5hZ2VtZW50IG9mIHRoZSBTVEFNUCBTZXNzaW9uLQogICBTZW5kZXIsIFNl c3Npb24tUmVmbGVjdG9yLCBhbmQgbWFuYWdlbWVudCBvZiB0aGUgU1RBTVAgc2Vzc2lvbnMgY2Fu CiAgIGJlIGFjaGlldmVkIHRocm91Z2ggdmFyaW91cyBtZWFucy4gIENvbW1hbmQgTGluZSBJbnRl cmZhY2UsIE9TUy9CU1MKICAgKG9wZXJhdGlvbnMgc3VwcG9ydCBzeXN0ZW0vYnVzaW5lc3Mgc3Vw cG9ydCBzeXN0ZW0gYXMgYSBjb21iaW5hdGlvbgogICBvZiB0d28gc3lzdGVtcyB1c2VkIHRvIHN1 cHBvcnQgYSByYW5nZSBvZiB0ZWxlY29tbXVuaWNhdGlvbiBzZXJ2aWNlcykKICAgdXNpbmcgU05N UCBvciBjb250cm9sbGVycyBpbiBTb2Z0d2FyZS1EZWZpbmVkIE5ldHdvcmtpbmcgdXNpbmcKICAg TmV0Y29uZi9ZQU5HIGFyZSBidXQgYSBmZXcgZXhhbXBsZXMuCgoKCk1pcnNreSwgZXQgYWwuICAg ICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjcsIDIwMjAgICAgICAgICAgICAgICBbUGFnZSAzXQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBTVEFNUCAgICAgICAgICAgICAgICAg ICAgICBBdWd1c3QgMjAxOQoKCiAgICAgICAgIG8tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tbwogICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgIENvbmZpZ3VyYXRpb24gYW5kICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICBNYW5hZ2VtZW50ICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICAgICAgIG8tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tbwogICAgICAgICAgICAgICAgfHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8fAogICAgICAgICAgICAgICAgfHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8fAogICAgICAgICAgICAgICAgfHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8fAogICAgICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tKyAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICB8IFNU QU1QIFNlc3Npb24tU2VuZGVyIHwgPC0tLSBTVEFNUC0tLT4gfCBTVEFNUCBTZXNzaW9uLVJlZmxl Y3RvciB8CiAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKwoKCiAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTog U1RBTVAgUmVmZXJlbmNlIE1vZGVsCgo0LiAgVGhlb3J5IG9mIE9wZXJhdGlvbgoKICAgU1RBTVAg U2Vzc2lvbi1TZW5kZXIgdHJhbnNtaXRzIHRlc3QgcGFja2V0cyBvdmVyIFVEUCB0cmFuc3BvcnQg dG93YXJkCiAgIFNUQU1QIFNlc3Npb24tUmVmbGVjdG9yLiAgQSBTVEFNUCBTZXNzaW9uLVNlbmRl ciBNVVNUIHVzZSBVRFAgcG9ydAogICA4NjIgKFRXQU1QLVRlc3QgUmVjZWl2ZXIgUG9ydCkgYXMg dGhlIGRlZmF1bHQgZGVzdGluYXRpb24gVURQIHBvcnQKICAgbnVtYmVyLiAgQSBTVEFNUCBpbXBs ZW1lbnRhdGlvbiBvZiBTZXNzaW9uLVNlbmRlciBNVVNUIGJlIGFibGUgdG8gdXNlCiAgIFVEUCBw b3J0IG51bWJlcnMgZnJvbSBVc2VyLCBhLmsuYS4gIFJlZ2lzdGVyZWQsIFBvcnRzIGFuZCBEeW5h bWljLAogICBhLmsuYS4gIFByaXZhdGUgb3IgRXBoZW1lcmFsLCBQb3J0cyByYW5nZXMgZGVmaW5l ZCBpbiBbUkZDNjMzNV0uCiAgIEJlZm9yZSB1c2luZyBudW1iZXJzIGZyb20gdGhlIFVzZXIgUG9y dHMgcmFuZ2UsIHRoZSBwb3NzaWJsZSBpbXBhY3QKICAgb24gdGhlIG5ldHdvcmsgTVVTVCBiZSBj YXJlZnVsbHkgc3R1ZGllZCBhbmQgYWdyZWVkIGJ5IGFsbCB1c2VycyBvZgogICB0aGUgbmV0d29y ay4KCiAgIFNUQU1QIFNlc3Npb24tUmVmbGVjdG9yIHJlY2VpdmVzIFNlc3Npb24tU2VuZGVyJ3Mg cGFja2V0IGFuZCBhY3RzCiAgIGFjY29yZGluZyB0byB0aGUgY29uZmlndXJhdGlvbiBhbmQgb3B0 aW9uYWwgY29udHJvbCBpbmZvcm1hdGlvbgogICBjb21tdW5pY2F0ZWQgaW4gdGhlIFNlc3Npb24t U2VuZGVyJ3MgdGVzdCBwYWNrZXQuICBBbiBpbXBsZW1lbnRhdGlvbgogICBvZiBTVEFNUCBTZXNz aW9uLVJlZmxlY3RvciBieSBkZWZhdWx0IE1VU1QgdXNlIHJlY2VpdmUgU1RBTVAgdGVzdAogICBw YWNrZXRzIG9uIFVEUCBwb3J0IDg2Mi4gIEFuIGltcGxlbWVudGF0aW9uIG9mIFNlc3Npb24tUmVm bGVjdG9yIHRoYXQKICAgc3VwcG9ydHMgdGhpcyBzcGVjaWZpY2F0aW9uIE1VU1QgYmUgYWJsZSB0 byBkZWZpbmUgdGhlIHBvcnQgbnVtYmVyIHRvCiAgIHJlY2VpdmUgU1RBTVAgdGVzdCBwYWNrZXRz IGZyb20gVXNlciBQb3J0cyBhbmQgRHluYW1pYyBQb3J0cyByYW5nZXMKICAgdGhhdCBhcmUgZGVm aW5lZCBpbiBbUkZDNjMzNV0uICBTVEFNUCBkZWZpbmVzIHR3byBkaWZmZXJlbnQgdGVzdAogICBw YWNrZXQgZm9ybWF0cywgb25lIGZvciBwYWNrZXRzIHRyYW5zbWl0dGVkIGJ5IHRoZSBTVEFNUC1T ZXNzaW9uLQogICBTZW5kZXIgYW5kIG9uZSBmb3IgcGFja2V0cyB0cmFuc21pdHRlZCBieSB0aGUg U1RBTVAtU2Vzc2lvbi0KICAgUmVmbGVjdG9yLgoKICAgU1RBTVAgc3VwcG9ydHMgdHdvIG1vZGVz OiB1bmF1dGhlbnRpY2F0ZWQgYW5kIGF1dGhlbnRpY2F0ZWQuCiAgIFVuYXV0aGVudGljYXRlZCBT VEFNUCB0ZXN0IHBhY2tldHMsIGRlZmluZWQgaW4gU2VjdGlvbiA0LjEuMSBhbmQKICAgU2VjdGlv biA0LjIuMSwgZW5zdXJlIGludGVyd29ya2luZyBiZXR3ZWVuIFNUQU1QIGFuZCBUV0FNUCBMaWdo dCBhcwogICBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjUgcGFja2V0IGZvcm1hdHMuCgogICBCeSBk ZWZhdWx0LCBTVEFNUCB1c2VzIHN5bW1ldHJpY2FsIHBhY2tldHMsIGkuZS4sIHNpemUgb2YgdGhl IHBhY2tldAogICB0cmFuc21pdHRlZCBieSBTZXNzaW9uLVJlZmxlY3RvciBlcXVhbHMgdGhlIHNp emUgb2YgdGhlIHBhY2tldAogICByZWNlaXZlZCBieSB0aGUgU2Vzc2lvbi1SZWZsZWN0b3IuCgoK CgoKTWlyc2t5LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNywgMjAyMCAgICAg ICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIFNU QU1QICAgICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDE5CgoKNC4xLiAgU2Vzc2lvbi1TZW5k ZXIgQmVoYXZpb3IgYW5kIFBhY2tldCBGb3JtYXQKCiAgIEJlY2F1c2UgU1RBTVAgc3VwcG9ydHMg c3ltbWV0cmljYWwgdGVzdCBwYWNrZXRzLCBTVEFNUCBTZXNzaW9uLVNlbmRlcgogICBwYWNrZXQg aGFzIGEgbWluaW11bSBzaXplIG9mIDQ0IG9jdGV0cyBpbiB1bmF1dGhlbnRpY2F0ZWQgbW9kZSwg c2VlCiAgIEZpZ3VyZSAyLCBhbmQgMTEyIG9jdGV0cyBpbiB0aGUgYXV0aGVudGljYXRlZCBtb2Rl LCBzZWUgRmlndXJlIDQuCgo0LjEuMS4gIFNlc3Npb24tU2VuZGVyIFBhY2tldCBGb3JtYXQgaW4g VW5hdXRoZW50aWNhdGVkIE1vZGUKCiAgIFNUQU1QIFNlc3Npb24tU2VuZGVyIHBhY2tldCBmb3Jt YXQgaW4gdW5hdXRoZW50aWNhdGVkIG1vZGU6CgogICAgICAgMCAgICAgICAgICAgICAgICAgICAx ICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgICAgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAg ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBTZXF1ZW5jZSBOdW1i ZXIgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgIFRpbWVzdGFtcCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgICAgICAgICBFcnJvciBFc3Rp bWF0ZSAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICArCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgTUJaICgzMCBvY3RldHMpICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rCgogICBGaWd1cmUgMjogU1RBTVAgU2Vzc2lvbi1TZW5kZXIgdGVzdCBwYWNrZXQg Zm9ybWF0IGluIHVuYXV0aGVudGljYXRlZAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIG1vZGUKCiAgIHdoZXJlIGZpZWxkcyBhcmUgZGVmaW5lZCBhcyB0aGUgZm9sbG93aW5nOgoK ICAgbyAgU2VxdWVuY2UgTnVtYmVyIGlzIGZvdXIgb2N0ZXRzIGxvbmcgZmllbGQuICBGb3IgZWFj aCBuZXcgc2Vzc2lvbgogICAgICBpdHMgdmFsdWUgc3RhcnRzIGF0IHplcm8gYW5kIGlzIGluY3Jl bWVudGVkIHdpdGggZWFjaCB0cmFuc21pdHRlZAogICAgICBwYWNrZXQuCgogICBvICBUaW1lc3Rh bXAgaXMgZWlnaHQgb2N0ZXRzIGxvbmcgZmllbGQuICBTVEFNUCBub2RlIE1VU1Qgc3VwcG9ydAog ICAgICBOZXR3b3JrIFRpbWUgUHJvdG9jb2wgKE5UUCkgdmVyc2lvbiA0IDY0LWJpdCB0aW1lc3Rh bXAgZm9ybWF0CiAgICAgIFtSRkM1OTA1XSwgdGhlIGZvcm1hdCB1c2VkIGluIFtSRkM1MzU3XS4g IFNUQU1QIG5vZGUgTUFZIHN1cHBvcnQKICAgICAgSUVFRSAxNTg4djIgUHJlY2lzaW9uIFRpbWUg UHJvdG9jb2wgdHJ1bmNhdGVkIDY0LWJpdCB0aW1lc3RhbXAKICAgICAgZm9ybWF0IFtJRUVFLjE1 ODguMjAwOF0sIHRoZSBmb3JtYXQgdXNlZCBpbiBbUkZDODE4Nl0uCgogICBvICBFcnJvciBFc3Rp bWF0ZSBpcyB0d28gb2N0ZXRzIGxvbmcgZmllbGQgd2l0aCBmb3JtYXQgZGlzcGxheWVkIGluCiAg ICAgIEZpZ3VyZSAzCgoKCgoKTWlyc2t5LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBGZWJydWFy eSAyNywgMjAyMCAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgICAgIFNUQU1QICAgICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDE5CgoKICAg ICAgICAgICAgMCAgICAgICAgICAgICAgICAgICAxCiAgICAgICAgICAgIDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUKICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsKICAgICAgICAgICB8U3xafCAgIFNjYWxlICAgfCAgIE11bHRpcGxpZXIgIHwKICAgICAg ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgICAgICAgICAgICAgICAg ICAgICBGaWd1cmUgMzogRXJyb3IgRXN0aW1hdGUgRm9ybWF0CgogICAgICB3aGVyZSBTLCBTY2Fs ZSwgYW5kIE11bHRpcGxpZXIgZmllbGRzIGFyZSBpbnRlcnByZXRlZCBhcyB0aGV5IGhhdmUKICAg ICAgYmVlbiBkZWZpbmVkIGluIHNlY3Rpb24gNC4xLjIgW1JGQzQ2NTZdOyBhbmQgWiBmbGFnIC0g YXMgaGFzIGJlZW4KICAgICAgZGVmaW5lZCBpbiBzZWN0aW9uIDIuMyBbUkZDODE4Nl06CgogICAg ICAqICAwIC0gTlRQIDY0IGJpdCBmb3JtYXQgb2YgYSB0aW1lc3RhbXA7CgogICAgICAqICAxIC0g UFRQdjIgdHJ1bmNhdGVkIGZvcm1hdCBvZiBhIHRpbWVzdGFtcC4KCiAgICAgIFRoZSBTVEFNUCBT ZXNzaW9uLVNlbmRlciBhbmQgU2Vzc2lvbi1SZWZsZWN0b3IgTUFZIHVzZSwgbm90IHVzZSwKICAg ICAgb3Igc2V0IHZhbHVlIG9mIHRoZSBaIGZsYWcgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSB0aW1l c3RhbXAgZm9ybWF0CiAgICAgIGluIHVzZS4gIFRoaXMgb3B0aW9uYWwgZmllbGQgaXMgdG8gZW5o YW5jZSBvcGVyYXRpb25zLCBidXQgbG9jYWwKICAgICAgY29uZmlndXJhdGlvbiBvciBkZWZhdWx0 cyBjb3VsZCBiZSB1c2VkIGluIGl0cyBwbGFjZS4KCiAgIG8gIE1heS1iZS1aZXJvIChNQlopIGZp ZWxkIGluIHRoZSBzZXNzaW9uLXNlbmRlciB1bmF1dGhlbnRpY2F0ZWQKICAgICAgcGFja2V0IGlz IDMwIG9jdGV0cyBsb25nLiAgSXQgTUFZIGJlIGFsbCB6ZXJvZWQgb24gdGhlCiAgICAgIHRyYW5z bWlzc2lvbiBhbmQgTVVTVCBiZSBpZ25vcmVkIG9uIHJlY2VpcHQuCgo0LjEuMi4gIFNlc3Npb24t U2VuZGVyIFBhY2tldCBGb3JtYXQgaW4gQXV0aGVudGljYXRlZCBNb2RlCgogICBTVEFNUCBTZXNz aW9uLVNlbmRlciBwYWNrZXQgZm9ybWF0IGluIGF1dGhlbnRpY2F0ZWQgbW9kZToKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgpNaXJza3ksIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI3 LCAyMDIwICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgICAgU1RBTVAgICAgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTkKCgogICAgIDAg ICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAg IDMKICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEKICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8ICAgICAgICAgICAgICAgICAgICAgIFNl cXVlbmNlIE51bWJlciAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8CiAgICB8ICAgICAgICAgICAgICAgICAgICAgIE1CWiAoMTIgb2N0ZXRzKSAgICAg ICAgICAgICAgICAgICAgICAgICAgfAogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgVGltZXN0YW1wICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfAogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8ICAgICAgICBFcnJvciBFc3RpbWF0 ZSAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsK ICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB+CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIE1CWiAoNzAgb2N0ZXRz KSAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH4KICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgfCAgICAgICAgICAgICAgICAgICAgICAgSE1BQyAoMTYgb2N0ZXRzKSAgICAg ICAgICAgICAgICAgICAgICAgIHwKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsKCiAgICBGaWd1cmUgNDogU1RBTVAgU2Vzc2lvbi1TZW5kZXIgdGVzdCBwYWNrZXQgZm9ybWF0 IGluIGF1dGhlbnRpY2F0ZWQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb2Rl CgogICBUaGUgZmllbGQgZGVmaW5pdGlvbnMgYXJlIHRoZSBzYW1lIGFzIHRoZSB1bmF1dGhlbnRp Y2F0ZWQgbW9kZSwKICAgbGlzdGVkIGluIFNlY3Rpb24gNC4xLjEuICBBbHNvLCBNQlogZmllbGRz IGFyZSB1c2VkIHRvIGFsaWduIHRoZQogICBwYWNrZXQgb24gMTYgb2N0ZXRzIGJvdW5kYXJ5LiAg VGhlIHZhbHVlIG9mIHRoZSBmaWVsZCBNQVkgYmUgemVyb2VkCiAgIG9uIHRyYW5zbWlzc2lvbiBh bmQgTVVTVCBiZSBpZ25vcmVkIG9uIHJlY2VpcHQuICBBbHNvLCB0aGUgcGFja2V0CiAgIGluY2x1 ZGVzIGEga2V5LWhhc2hlZCBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIGNvZGUgKEhNQUMpIChbUkZD MjEwNF0pCiAgIGhhc2ggYXQgdGhlIGVuZCBvZiB0aGUgUERVLiAgVGhlIGRldGFpbGVkIHVzZSBv ZiB0aGUgSE1BQyBmaWVsZCBpcwogICBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjMuCgo0LjIuICBT ZXNzaW9uLVJlZmxlY3RvciBCZWhhdmlvciBhbmQgUGFja2V0IEZvcm1hdAoKICAgVGhlIFNlc3Np b24tUmVmbGVjdG9yIHJlY2VpdmVzIHRoZSBTVEFNUCB0ZXN0IHBhY2tldCwgdmVyaWZpZXMgaXQs CiAgIHByZXBhcmVzIGFuZCB0cmFuc21pdHMgdGhlIHJlZmxlY3RlZCB0ZXN0IHBhY2tldC4KCiAg IFR3byBtb2RlcyBvZiBTVEFNUCBTZXNzaW9uLVJlZmxlY3RvciBjaGFyYWN0ZXJpemUgdGhlIGV4 cGVjdGVkCiAgIGJlaGF2aW9yIGFuZCwgY29uc2VxdWVudGx5LCBwZXJmb3JtYW5jZSBtZXRyaWNz IHRoYXQgY2FuIGJlIG1lYXN1cmVkOgoKICAgbyAgU3RhdGVsZXNzIC0gU1RBTVAgU2Vzc2lvbi1S ZWZsZWN0b3IgZG9lcyBub3QgbWFpbnRhaW4gdGVzdCBzdGF0ZQogICAgICBhbmQgd2lsbCByZWZs ZWN0IHRoZSByZWNlaXZlZCBzZXF1ZW5jZSBudW1iZXIgd2l0aG91dAogICAgICBtb2RpZmljYXRp b24uICBBcyBhIHJlc3VsdCwgb25seSByb3VuZC10cmlwIHBhY2tldCBsb3NzIGNhbiBiZQogICAg ICBjYWxjdWxhdGVkIHdoaWxlIHRoZSByZWZsZWN0b3IgaXMgb3BlcmF0aW5nIGluIHN0YXRlbGVz cyBtb2RlLgoKCgoKTWlyc2t5LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNywg MjAyMCAgICAgICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgICAgIFNUQU1QICAgICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDE5CgoKICAgbyAgU3Rh dGVmdWwgLSBTVEFNUCBTZXNzaW9uLVJlZmxlY3RvciBtYWludGFpbnMgdGVzdCBzdGF0ZSB0aHVz CiAgICAgIGVuYWJsaW5nIHRoZSBhYmlsaXR5IHRvIGRldGVybWluZSBmb3J3YXJkIGxvc3MsIGdh cHMgcmVjb2duaXplZCBpbgogICAgICB0aGUgcmVjZWl2ZWQgc2VxdWVuY2UgbnVtYmVyLiAgQXMg YSByZXN1bHQsIGJvdGggbmVhci1lbmQKICAgICAgKGZvcndhcmQpIGFuZCBmYXItZW5kIChiYWNr d2FyZCkgcGFja2V0IGxvc3MgY2FuIGJlIGNvbXB1dGVkLgogICAgICBUaGF0IGltcGxpZXMgdGhh dCB0aGUgU1RBTVAgU2Vzc2lvbi1SZWZsZWN0b3IgTVVTVCBrZWVwIGEgc3RhdGUKICAgICAgZm9y IGVhY2ggYWNjZXB0ZWQgU1RBTVAtdGVzdCBzZXNzaW9uLCB1bmlxdWVseSBpZGVudGlmeWluZyBT VEFNUC0KICAgICAgdGVzdCBwYWNrZXRzIHRvIG9uZSBzdWNoIHNlc3Npb24gaW5zdGFuY2UsIGFu ZCBlbmFibGluZyBhZGRpbmcgYQogICAgICBzZXF1ZW5jZSBudW1iZXIgaW4gdGhlIHRlc3QgcmVw bHkgdGhhdCBpcyBpbmRpdmlkdWFsbHkgaW5jcmVtZW50ZWQKICAgICAgb24gYSBwZXItc2Vzc2lv biBiYXNpcy4KCjQuMi4xLiAgU2Vzc2lvbi1SZWZsZWN0b3IgUGFja2V0IEZvcm1hdCBpbiBVbmF1 dGhlbnRpY2F0ZWQgTW9kZQoKICAgRm9yIHVuYXV0aGVudGljYXRlZCBtb2RlOgoKICAgICAwICAg ICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAz CiAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxCiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAgICAgICAgICAgIFNl cXVlbmNlIE51bWJlciAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICBUaW1lc3RhbXAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwKICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8ICAgICAgICAgRXJyb3IgRXN0 aW1hdGUgICAgICAgIHwgICAgICAgICAgIE1CWiAgICAgICAgICAgICAgICAgfAogICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIFJlY2VpdmUgVGltZXN0YW1wICAgICAg ICAgICAgICAgICAgICB8CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAg ICAgICAgIFNlc3Npb24tU2VuZGVyIFNlcXVlbmNlIE51bWJlciAgICAgICAgICAgICAgICB8CiAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAgICAgIFNlc3Npb24tU2VuZGVyIFRpbWVzdGFt cCAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgfCBT ZXNzaW9uLVNlbmRlciBFcnJvciBFc3RpbWF0ZSB8ICAgICAgICAgICBNQlogICAgICAgICAgICAg ICAgIHwKICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rCiAgICB8U2VzLVNlbmRlciBUVEwgfCAgICAgICAgICAgICAgICAg ICAgTUJaICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgICAgICAgICBG aWd1cmUgNTogU1RBTVAgU2Vzc2lvbi1SZWZsZWN0b3IgdGVzdCBwYWNrZXQgZm9ybWF0IGluCiAg ICAgICAgICAgICAgICAgICAgICAgICAgIHVuYXV0aGVudGljYXRlZCBtb2RlCgogICB3aGVyZSBm aWVsZHMgYXJlIGRlZmluZWQgYXMgdGhlIGZvbGxvd2luZzoKCiAgIG8gIFNlcXVlbmNlIE51bWJl ciBpcyBmb3VyIG9jdGV0cyBsb25nIGZpZWxkLiAgVGhlIHZhbHVlIG9mIHRoZQogICAgICBTZXF1 ZW5jZSBOdW1iZXIgZmllbGQgaXMgc2V0IGFjY29yZGluZyB0byB0aGUgbW9kZSBvZiB0aGUgU1RB TVAKICAgICAgU2Vzc2lvbi1SZWZsZWN0b3I6CgogICAgICAqICBpbiB0aGUgc3RhdGVsZXNzIG1v ZGUgdGhlIFNlc3Npb24tUmVmbGVjdG9yIGNvcGllcyB0aGUgdmFsdWUKICAgICAgICAgZnJvbSB0 aGUgcmVjZWl2ZWQgU1RBTVAgdGVzdCBwYWNrZXQncyBTZXF1ZW5jZSBOdW1iZXIgZmllbGQ7CgoK Ck1pcnNreSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjcsIDIwMjAgICAgICAg ICAgICAgICBbUGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBTVEFN UCAgICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxOQoKCiAgICAgICogIGluIHRoZSBzdGF0 ZWZ1bCBtb2RlIHRoZSBTZXNzaW9uLVJlZmxlY3RvciBjb3VudHMgdGhlIHJlY2VpdmVkCiAgICAg ICAgIFNUQU1QIHRlc3QgcGFja2V0cyBpbiBlYWNoIHRlc3Qgc2Vzc2lvbiBhbmQgdXNlcyB0aGF0 IGNvdW50ZXIKICAgICAgICAgdG8gc2V0IHRoZSB2YWx1ZSBvZiB0aGUgU2VxdWVuY2UgTnVtYmVy IGZpZWxkLgoKICAgbyAgVGltZXN0YW1wIGFuZCBSZWNlaXZlciBUaW1lc3RhbXAgZmllbGRzIGFy ZSBlYWNoIGVpZ2h0IG9jdGV0cwogICAgICBsb25nLiAgVGhlIGZvcm1hdCBvZiB0aGVzZSBmaWVs ZHMsIE5UUCBvciBQVFB2MiwgaW5kaWNhdGVkIGJ5IHRoZQogICAgICBaIGZsYWcgb2YgdGhlIEVy cm9yIEVzdGltYXRlIGZpZWxkIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuMS4KCiAgIG8gIEVy cm9yIEVzdGltYXRlIGhhcyB0aGUgc2FtZSBzaXplIGFuZCBpbnRlcnByZXRhdGlvbiBhcyBkZXNj cmliZWQKICAgICAgaW4gU2VjdGlvbiA0LjEuCgogICBvICBTZXNzaW9uLVNlbmRlciBTZXF1ZW5j ZSBOdW1iZXIsIFNlc3Npb24tU2VuZGVyIFRpbWVzdGFtcCwgYW5kCiAgICAgIFNlc3Npb24tU2Vu ZGVyIEVycm9yIEVzdGltYXRlIGFyZSBjb3BpZXMgb2YgdGhlIGNvcnJlc3BvbmRpbmcKICAgICAg ZmllbGRzIGluIHRoZSBTVEFNUCB0ZXN0IHBhY2tldCBzZW50IGJ5IHRoZSBTZXNzaW9uLVNlbmRl ci4KCiAgIG8gIFNlc3Npb24tU2VuZGVyIFRUTCBpcyBvbmUgb2N0ZXQgbG9uZyBmaWVsZCwgYW5k IGl0cyB2YWx1ZSBpcyB0aGUKICAgICAgY29weSBvZiB0aGUgVFRMIGZpZWxkIGluIElQdjQgKG9y IEhvcCBMaW1pdCBpbiBJUHY2KSBmcm9tIHRoZQogICAgICByZWNlaXZlZCBTVEFNUCB0ZXN0IHBh Y2tldC4KCiAgIG8gIE1CWiBpcyB1c2VkIHRvIGFjaGlldmUgYWxpZ25tZW50IG9uIGEgZm91ciBv Y3RldHMgYm91bmRhcnkuICBUaGUKICAgICAgdmFsdWUgb2YgdGhlIGZpZWxkIE1BWSBiZSB6ZXJv ZWQgb24gdHJhbnNtaXNzaW9uIGFuZCBNVVNUIGJlCiAgICAgIGlnbm9yZWQgb24gcmVjZWlwdC4K CjQuMi4yLiAgU2Vzc2lvbi1SZWZsZWN0b3IgUGFja2V0IEZvcm1hdCBpbiBBdXRoZW50aWNhdGVk IE1vZGUKCiAgIEZvciB0aGUgYXV0aGVudGljYXRlZCBtb2RlOgoKICAgICAgMCAgICAgICAgICAg ICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgICAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDEKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIFNlcXVl bmNlIE51bWJlciAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgIE1CWiAoMTIgb2N0ZXRzKSAgICAgICAgICAgICAgICAg ICAgICAgIHwKICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgVGltZXN0YW1wICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwKICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgfCAgICAgICAg IEVycm9yIEVzdGltYXRlICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICsKICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIE1CWiAoNiBvY3Rl dHMpICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgIFJlY2VpdmUgVGltZXN0YW1wICAgICAgICAgICAgICAgICAgICAg IHwKICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgIE1CWiAoOCBvY3RldHMpICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwKCgoKTWlyc2t5LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNywgMjAy MCAgICAgICAgICAgICAgIFtQYWdlIDldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg ICAgIFNUQU1QICAgICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDE5CgoKICAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsKICAgICAgfCAgICAgICAgICAgICAgICAgU2Vzc2lvbi1TZW5kZXIgU2VxdWVuY2UgTnVtYmVy ICAgICAgICAgICAgICAgIHwKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgIE1CWiAoMTIgb2N0ZXRzKSAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwKICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgfCAgICAgICAgICAgICAg ICAgU2Vzc2lvbi1TZW5kZXIgVGltZXN0YW1wICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgfCBTZXNzaW9uLVNlbmRlciBFcnJvciBFc3Rp bWF0ZSB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsKICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgIE1CWiAoNiBvY3RldHMpICAgICAgICAgICAgICAg ICAgICAgICAgIHwKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgfFNlcy1TZW5kZXIgVFRMIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgKy0rLSstKy0r LSstKy0rLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsK ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwKICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIE1CWiAoMTUgb2N0 ZXRzKSAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsKICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIEhNQUMgKDE2IG9jdGV0cykgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsKCgogICBGaWd1cmUgNjogU1RBTVAgU2Vzc2lvbi1SZWZsZWN0 b3IgdGVzdCBwYWNrZXQgZm9ybWF0IGluIGF1dGhlbnRpY2F0ZWQKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBtb2RlCgogICBUaGUgZmllbGQgZGVmaW5pdGlvbnMgYXJlIHRoZSBz YW1lIGFzIHRoZSB1bmF1dGhlbnRpY2F0ZWQgbW9kZSwKICAgbGlzdGVkIGluIFNlY3Rpb24gNC4y LjEuICBBZGRpdGlvbmFsbHksIHRoZSBNQlogZmllbGQgaXMgdXNlZCB0bwogICBhbGlnbiB0aGUg cGFja2V0IG9uIDE2IG9jdGV0cyBib3VuZGFyeS4gIFRoZSB2YWx1ZSBvZiB0aGUgZmllbGQgTUFZ CiAgIGJlIHplcm9lZCBvbiB0cmFuc21pc3Npb24gYW5kIE1VU1QgYmUgaWdub3JlZCBvbiByZWNl aXB0LiAgQWxzbywKICAgU1RBTVAgU2Vzc2lvbi1SZWZsZWN0b3IgdGVzdCBwYWNrZXQgZm9ybWF0 IGluIGF1dGhlbnRpY2F0ZWQgbW9kZQogICBpbmNsdWRlcyBhIGtleSAoSE1BQykgKFtSRkMyMTA0 XSkgaGFzaCBhdCB0aGUgZW5kIG9mIHRoZSBQRFUuICBUaGUKICAgZGV0YWlsZWQgdXNlIG9mIHRo ZSBITUFDIGZpZWxkIGlzIGluIFNlY3Rpb24gNC4zLgoKNC4zLiAgSW50ZWdyaXR5IFByb3RlY3Rp b24gaW4gU1RBTVAKCiAgIFRvIHByb3ZpZGUgaW50ZWdyaXR5IHByb3RlY3Rpb24sIGVhY2ggU1RB TVAgbWVzc2FnZSBpcyBiZWluZwogICBhdXRoZW50aWNhdGVkIGJ5IGFkZGluZyBIYXNoZWQgTWVz c2FnZSBBdXRoZW50aWNhdGlvbiBDb2RlIChITUFDKS4KICAgU1RBTVAgdXNlcyBITUFDLVNIQS0y NTYgdHJ1bmNhdGVkIHRvIDEyOCBiaXRzIChzaW1pbGFybHkgdG8gdGhlIHVzZQogICBvZiBpdCBp biBJUFNlYyBkZWZpbmVkIGluIFtSRkM0ODY4XSk7IGhlbmNlIHRoZSBsZW5ndGggb2YgdGhlIEhN QUMKICAgZmllbGQgaXMgMTYgb2N0ZXRzLiAgSE1BQyB1c2VzIGl0cyBvd24ga2V5LCBhbmQgdGhl IGRlZmluaXRpb24gb2YgdGhlCiAgIG1lY2hhbmlzbSB0byBkaXN0cmlidXRlIHRoZSBITUFDIGtl eSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzCiAgIHNwZWNpZmljYXRpb24uICBPbmUgZXhh bXBsZSBpcyB0byB1c2UgYW4gb3JjaGVzdHJhdG9yIHRvIGNvbmZpZ3VyZQogICBITUFDIGtleSBi YXNlZCBvbiBTVEFNUCBZQU5HIGRhdGEgbW9kZWwgW0ktRC5pZXRmLWlwcG0tc3RhbXAteWFuZ10u CgoKCk1pcnNreSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjcsIDIwMjAgICAg ICAgICAgICAgIFtQYWdlIDEwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBT VEFNUCAgICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxOQoKCiAgIEhNQUMgTVVTVCBiZSB2 ZXJpZmllZCBhcyBlYXJseSBhcyBwb3NzaWJsZSB0byBhdm9pZCB1c2luZyBvcgogICBwcm9wYWdh dGluZyBjb3JydXB0ZWQgZGF0YS4KCjQuNC4gIENvbmZpZGVudGlhbGl0eSBQcm90ZWN0aW9uIGlu IFNUQU1QCgogICBJZiBjb25maWRlbnRpYWxpdHkgcHJvdGVjdGlvbiBmb3IgU1RBTVAgaXMgcmVx dWlyZWQsIGEgU1RBTVAgdGVzdAogICBzZXNzaW9uIE1VU1QgdXNlIGEgc2VjdXJlZCB0cmFuc3Bv cnQuICBGb3IgZXhhbXBsZSwgU1RBTVAgcGFja2V0cwogICBjb3VsZCBiZSB0cmFuc21pdHRlZCBp biB0aGUgZGVkaWNhdGVkIElQc2VjIHR1bm5lbCBvciBzaGFyZSB0aGUgSVBzZWMKICAgdHVubmVs IHdpdGggdGhlIG1vbml0b3JlZCBmbG93LiAgQWxzbywgRGF0YWdyYW0gVHJhbnNwb3J0IExheWVy CiAgIFNlY3VyaXR5IHByb3RvY29sIHdvdWxkIHByb3ZpZGUgdGhlIGRlc2lyZWQgY29uZmlkZW50 aWFsaXR5CiAgIHByb3RlY3Rpb24uCgo0LjUuICBJbnRlcm9wZXJhYmlsaXR5IHdpdGggVFdBTVAg TGlnaHQKCiAgIE9uZSBvZiB0aGUgZXNzZW50aWFsIHJlcXVpcmVtZW50cyB0byBTVEFNUCBpcyB0 aGUgYWJpbGl0eSB0bwogICBpbnRlcndvcmsgd2l0aCBhIFRXQU1QIExpZ2h0IGRldmljZS4gIFRo ZXJlIGFyZSB0d28gcG9zc2libGUKICAgY29tYmluYXRpb25zIGZvciBzdWNoIHVzZSBjYXNlOgoK ICAgbyAgU1RBTVAgU2Vzc2lvbi1TZW5kZXIgd2l0aCBUV0FNUCBMaWdodCBTZXNzaW9uLVJlZmxl Y3RvcjsKCiAgIG8gIFRXQU1QIExpZ2h0IFNlc3Npb24tU2VuZGVyIHdpdGggU1RBTVAgU2Vzc2lv bi1SZWZsZWN0b3IuCgogICBJbiB0aGUgZm9ybWVyIGNhc2UsIHRoZSBTZXNzaW9uLVNlbmRlciBN QVkgbm90IGJlIGF3YXJlIHRoYXQgaXRzCiAgIFNlc3Npb24tUmVmbGVjdG9yIGRvZXMgbm90IHN1 cHBvcnQgU1RBTVAuICBGb3IgZXhhbXBsZSwgYSBUV0FNUCBMaWdodAogICBTZXNzaW9uLVJlZmxl Y3RvciBtYXkgbm90IHN1cHBvcnQgdGhlIHVzZSBvZiBVRFAgcG9ydCA4NjIgYXMgZGVmaW5lZAog ICBpbiBbUkZDODU0NV0uICBUaHVzIFNUQU1QIFNlc3Npb24tU2VuZGVyIE1BWSB1c2UgcG9ydCBu dW1iZXJzIGFzCiAgIGRlZmluZWQgaW4gU2VjdGlvbiA0LiAgSWYgYW55IG9mIFNUQU1QIGV4dGVu c2lvbnMgYXJlIHVzZWQsIHRoZSBUV0FNUAogICBMaWdodCBTZXNzaW9uLVJlZmxlY3RvciB3aWxs IHZpZXcgdGhlbSBhcyBQYWNrZXQgUGFkZGluZyBmaWVsZC4gIFRoZQogICBTZXNzaW9uLVNlbmRl ciBTSE9VTEQgdXNlIHRoZSBkZWZhdWx0IGZvcm1hdCBmb3IgaXRzIHRpbWVzdGFtcHMgLQogICBO VFAuICBBbmQgaXQgTUFZIHVzZSBQVFB2MiB0aW1lc3RhbXAgZm9ybWF0LgoKICAgSW4gdGhlIGxh dHRlciBzY2VuYXJpbywgaWYgYSBUV0FNUCBMaWdodCBTZXNzaW9uLVNlbmRlciBkb2VzIG5vdAog ICBzdXBwb3J0IHRoZSB1c2Ugb2YgVURQIHBvcnQgODYyLCB0aGUgdGVzdCBtYW5hZ2VtZW50IHN5 c3RlbSBNVVNUIHNldAogICBTVEFNUCBTZXNzaW9uLVJlZmxlY3RvciB0byB1c2UgVURQIHBvcnQg bnVtYmVyIGFzIGRlZmluZWQgaW4KICAgU2VjdGlvbiA0LiAgSWYgdGhlIFRXQU1QIExpZ2h0IFNl c3Npb24tU2VuZGVyIGluY2x1ZGVzIFBhY2tldCBQYWRkaW5nCiAgIGZpZWxkIGluIGl0cyB0cmFu c21pdHRlZCBwYWNrZXQsIHRoZSBTVEFNUCBTZXNzaW9uLVJlZmxlY3RvciB3aWxsCiAgIHJldHVy biB0aGUgcmVmbGVjdGVkIHBhY2tldCBvZiB0aGUgc3ltbWV0cmljYWwgc2l6ZSBpZiB0aGUgc2l6 ZSBvZgogICB0aGUgcmVjZWl2ZWQgdGVzdCBwYWNrZXQgaXMgbGFyZ2VyIHRoYW4gdGhlIHNpemUg b2YgdGhlIFNUQU1QIGJhc2UKICAgcGFja2V0LiAgVGhlIFNlc3Npb24tUmVmbGVjdG9yIE1VU1Qg YmUgc2V0IHRvIHVzZSB0aGUgZGVmYXVsdCBmb3JtYXQKICAgZm9yIGl0cyB0aW1lc3RhbXBzLCBO VFAuCgogICBTVEFNUCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBSZWZsZWN0IE9jdGV0cyBjYXBhYmls aXR5IGRlZmluZWQgaW4KICAgW1JGQzYwMzhdLiAgSWYgdGhlIFNlcnZlciBPY3RldHMgZmllbGQg aXMgcHJlc2VudCBpbiB0aGUgVFdBTVAKICAgU2Vzc2lvbi1TZW5kZXIgcGFja2V0LCBTVEFNUCBT ZXNzaW9uLVJlZmxlY3RvciB3aWxsIG5vdCBjb3B5IHRoZQogICBjb250ZW50IHN0YXJ0aW5nIGZy b20gdGhlIFNlcnZlciBPY3RldHMgZmllbGQgYnV0IHdpbGwgdHJhbnNtaXQgdGhlCiAgIHJlZmxl Y3RlZCBwYWNrZXQgb2YgZXF1YWwgc2l6ZS4KCgoKCgpNaXJza3ksIGV0IGFsLiAgICAgICAgICBF eHBpcmVzIEZlYnJ1YXJ5IDI3LCAyMDIwICAgICAgICAgICAgICBbUGFnZSAxMV0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICAgICAgU1RBTVAgICAgICAgICAgICAgICAgICAgICAgQXVn dXN0IDIwMTkKCgo1LiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAgVGhpcyBkb2N1bWVudCBkb2Vz bid0IGhhdmUgYW55IElBTkEgYWN0aW9uLiAgVGhpcyBzZWN0aW9uIG1heSBiZQogICByZW1vdmVk IGJlZm9yZSB0aGUgcHVibGljYXRpb24uCgo2LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAg IEluIGdlbmVyYWwsIGFsbCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgcmVsYXRlZCB0byBU V0FNUC1UZXN0LAogICBkaXNjdXNzZWQgaW4gW1JGQzUzNTddIGFwcGx5IHRvIFNUQU1QLiAgU2lu Y2UgU1RBTVAgdXNlcyB0aGUgd2VsbC0KICAga25vd24gVURQIHBvcnQgbnVtYmVyIGFsbG9jYXRl ZCBmb3IgdGhlIE9XQU1QLVRlc3QvVFdBTVAtVGVzdAogICBSZWNlaXZlciBwb3J0LCB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgYW5kIG1lYXN1cmVzIHRvIG1pdGlnYXRlCiAgIHRoZSByaXNr IG9mIHRoZSBhdHRhY2sgdXNpbmcgdGhlIHJlZ2lzdGVyZWQgcG9ydCBudW1iZXIgZG9jdW1lbnRl ZCBpbgogICBTZWN0aW9uIDYgW1JGQzg1NDVdIGVxdWFsbHkgYXBwbHkgdG8gU1RBTVAuICBCZWNh dXNlIG9mIHRoZSBjb250cm9sCiAgIGFuZCBtYW5hZ2VtZW50IG9mIGEgU1RBTVAgdGVzdCBiZWlu ZyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzCiAgIHNwZWNpZmljYXRpb24gb25seSB0aGUgbW9y ZSBnZW5lcmFsIHJlcXVpcmVtZW50IGlzIHNldDoKCiAgICAgIFRvIG1pdGlnYXRlIHRoZSBwb3Nz aWJsZSBhdHRhY2sgdmVjdG9yLCB0aGUgY29udHJvbCwgYW5kCiAgICAgIG1hbmFnZW1lbnQgb2Yg YSBTVEFNUCB0ZXN0IHNlc3Npb24gTVVTVCB1c2UgdGhlIHNlY3VyZWQgdHJhbnNwb3J0LgoKICAg ICAgTG9hZCBvZiBTVEFNUCB0ZXN0IHBhY2tldHMgb2ZmZXJlZCB0byBhIG5ldHdvcmsgTVVTVCBi ZSBjYXJlZnVsbHkKICAgICAgZXN0aW1hdGVkLCBhbmQgdGhlIHBvc3NpYmxlIGltcGFjdCBvbiB0 aGUgZXhpc3Rpbmcgc2VydmljZXMgTVVTVAogICAgICBiZSB0aG9yb3VnaGx5IGFuYWx5emVkIGJl Zm9yZSBsYXVuY2hpbmcgdGhlIHRlc3Qgc2Vzc2lvbi4KICAgICAgW1JGQzgwODVdIHNlY3Rpb24g My4xLjUgcHJvdmlkZXMgZ3VpZGFuY2Ugb24gaGFuZGxpbmcgbmV0d29yayBsb2FkCiAgICAgIGZv ciBVRFAtYmFzZWQgcHJvdG9jb2wuICBXaGlsZSB0aGUgY2hhcmFjdGVyaXN0aWMgb2YgdGVzdCB0 cmFmZmljCiAgICAgIGRlcGVuZHMgb24gdGhlIHRlc3Qgb2JqZWN0aXZlLCBpdCBpcyBoaWdobHkg cmVjb21tZW5kZWQgdG8gc3RheSBpbgogICAgICB0aGUgbGltaXRzIGFzIHByb3ZpZGVkIGluIFtS RkM4MDg1XS4KCiAgIFNUQU1QIHRlc3QgcGFja2V0cyBjYW4gYmUgdHJhbnNtaXR0ZWQgd2l0aCB0 aGUgZGVzdGluYXRpb24gVURQIHBvcnQKICAgbnVtYmVyIGZyb20gdGhlIFVzZXIgUG9ydHMgcmFu Z2UsIGFzIGRlZmluZWQgaW4gU2VjdGlvbiA0LCB0aGF0IGlzCiAgIGFscmVhZHkgb3Igd2lsbCBi ZSBhc3NpZ25lZCBieSBJQU5BLiAgVGhlIHBvc3NpYmxlIGltcGFjdCBvZiB0aGUKICAgU1RBTVAg dGVzdCBwYWNrZXRzIG9uIHRoZSBuZXR3b3JrIE1VU1QgYmUgdGhvcm91Z2hseSBhbmFseXplZCwg YW5kCiAgIHRoZSB1c2Ugb2YgU1RBTVAgZm9yIGVhY2ggY2FzZSBNVVNUIGJlIGFncmVlZCBieSBh bGwgdXNlcnMgb24gdGhlCiAgIG5ldHdvcmsgYmVmb3JlIHN0YXJ0aW5nIHRoZSBTVEFNUCB0ZXN0 IHNlc3Npb24uCgogICBVc2Ugb2YgSE1BQy1TSEEtMjU2IGluIHRoZSBhdXRoZW50aWNhdGVkIG1v ZGUgcHJvdGVjdHMgdGhlIGRhdGEKICAgaW50ZWdyaXR5IG9mIHRoZSBTVEFNUCB0ZXN0IHBhY2tl dHMuCgo3LiAgQWNrbm93bGVkZ21lbnRzCgogICBBdXRob3JzIGV4cHJlc3MgdGhlaXIgYXBwcmVj aWF0aW9uIHRvIEpvc2UgSWduYWNpbyBBbHZhcmV6LUhhbWVsaW4KICAgYW5kIEJyaWFuIFdlaXMg Zm9yIHRoZWlyIGdyZWF0IGluc2lnaHRzIGludG8gdGhlIHNlY3VyaXR5IGFuZAogICBpZGVudGl0 eSBwcm90ZWN0aW9uLCBhbmQgdGhlIG1vc3QgaGVscGZ1bCBhbmQgcHJhY3RpY2FsIHN1Z2dlc3Rp b25zLgogICBBbHNvLCBvdXIgc2luY2VyZSB0aGFua3MgdG8gRGF2aWQgQmFsbCBhbmQgUmFrZXNo IEdhbmRoaSBvciB0aGVpcgogICB0aG9yb3VnaCByZXZpZXdzIGFuZCBoZWxwZnVsIGNvbW1lbnRz LgoKCgoKCgoKTWlyc2t5LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNywgMjAy MCAgICAgICAgICAgICAgW1BhZ2UgMTJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg ICAgIFNUQU1QICAgICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDE5CgoKOC4gIFJlZmVyZW5j ZXMKCjguMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbSUVFRS4xNTg4LjIwMDhdCiAgICAg ICAgICAgICAgIlN0YW5kYXJkIGZvciBhIFByZWNpc2lvbiBDbG9jayBTeW5jaHJvbml6YXRpb24g UHJvdG9jb2wKICAgICAgICAgICAgICBmb3IgTmV0d29ya2VkIE1lYXN1cmVtZW50IGFuZCBDb250 cm9sIFN5c3RlbXMiLAogICAgICAgICAgICAgIElFRUUgU3RhbmRhcmQgMTU4OCwgTWFyY2ggMjAw OC4KCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNz IHRvIEluZGljYXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBS RkMgMjExOSwKICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDMjExOSwgTWFyY2ggMTk5NywK ICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMyMTE5Pi4K CiAgIFtSRkM0NjU2XSAgU2hhbHVub3YsIFMuLCBUZWl0ZWxiYXVtLCBCLiwgS2FycCwgQS4sIEJv b3RlLCBKLiwgYW5kIE0uCiAgICAgICAgICAgICAgWmVrYXVza2FzLCAiQSBPbmUtd2F5IEFjdGl2 ZSBNZWFzdXJlbWVudCBQcm90b2NvbAogICAgICAgICAgICAgIChPV0FNUCkiLCBSRkMgNDY1Niwg RE9JIDEwLjE3NDg3L1JGQzQ2NTYsIFNlcHRlbWJlciAyMDA2LAogICAgICAgICAgICAgIDxodHRw czovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzQ2NTY+LgoKICAgW1JGQzUzNTddICBIZWRh eWF0LCBLLiwgS3J6YW5vd3NraSwgUi4sIE1vcnRvbiwgQS4sIFl1bSwgSy4sIGFuZCBKLgogICAg ICAgICAgICAgIEJhYmlhcnosICJBIFR3by1XYXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29s IChUV0FNUCkiLAogICAgICAgICAgICAgIFJGQyA1MzU3LCBET0kgMTAuMTc0ODcvUkZDNTM1Nywg T2N0b2JlciAyMDA4LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9p bmZvL3JmYzUzNTc+LgoKICAgW1JGQzU5MDVdICBNaWxscywgRC4sIE1hcnRpbiwgSi4sIEVkLiwg QnVyYmFuaywgSi4sIGFuZCBXLiBLYXNjaCwKICAgICAgICAgICAgICAiTmV0d29yayBUaW1lIFBy b3RvY29sIFZlcnNpb24gNDogUHJvdG9jb2wgYW5kIEFsZ29yaXRobXMKICAgICAgICAgICAgICBT cGVjaWZpY2F0aW9uIiwgUkZDIDU5MDUsIERPSSAxMC4xNzQ4Ny9SRkM1OTA1LCBKdW5lIDIwMTAs CiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNTkwNT4u CgogICBbUkZDNjAzOF0gIE1vcnRvbiwgQS4gYW5kIEwuIENpYXZhdHRvbmUsICJUd28tV2F5IEFj dGl2ZSBNZWFzdXJlbWVudAogICAgICAgICAgICAgIFByb3RvY29sIChUV0FNUCkgUmVmbGVjdCBP Y3RldHMgYW5kIFN5bW1ldHJpY2FsIFNpemUKICAgICAgICAgICAgICBGZWF0dXJlcyIsIFJGQyA2 MDM4LCBET0kgMTAuMTc0ODcvUkZDNjAzOCwgT2N0b2JlciAyMDEwLAogICAgICAgICAgICAgIDxo dHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzYwMzg+LgoKICAgW1JGQzYzMzVdICBD b3R0b24sIE0uLCBFZ2dlcnQsIEwuLCBUb3VjaCwgSi4sIFdlc3Rlcmx1bmQsIE0uLCBhbmQgUy4K ICAgICAgICAgICAgICBDaGVzaGlyZSwgIkludGVybmV0IEFzc2lnbmVkIE51bWJlcnMgQXV0aG9y aXR5IChJQU5BKQogICAgICAgICAgICAgIFByb2NlZHVyZXMgZm9yIHRoZSBNYW5hZ2VtZW50IG9m IHRoZSBTZXJ2aWNlIE5hbWUgYW5kCiAgICAgICAgICAgICAgVHJhbnNwb3J0IFByb3RvY29sIFBv cnQgTnVtYmVyIFJlZ2lzdHJ5IiwgQkNQIDE2NSwKICAgICAgICAgICAgICBSRkMgNjMzNSwgRE9J IDEwLjE3NDg3L1JGQzYzMzUsIEF1Z3VzdCAyMDExLAogICAgICAgICAgICAgIDxodHRwczovL3d3 dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzYzMzU+LgoKICAgW1JGQzgxNzRdICBMZWliYSwgQi4s ICJBbWJpZ3VpdHkgb2YgVXBwZXJjYXNlIHZzIExvd2VyY2FzZSBpbiBSRkMKICAgICAgICAgICAg ICAyMTE5IEtleSBXb3JkcyIsIEJDUCAxNCwgUkZDIDgxNzQsIERPSSAxMC4xNzQ4Ny9SRkM4MTc0 LAogICAgICAgICAgICAgIE1heSAyMDE3LCA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5m by9yZmM4MTc0Pi4KCgoKCgoKCk1pcnNreSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRmVicnVh cnkgMjcsIDIwMjAgICAgICAgICAgICAgIFtQYWdlIDEzXQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICAgICBTVEFNUCAgICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxOQoKCiAg IFtSRkM4MTg2XSAgTWlyc2t5LCBHLiBhbmQgSS4gTWVpbGlrLCAiU3VwcG9ydCBvZiB0aGUgSUVF RSAxNTg4CiAgICAgICAgICAgICAgVGltZXN0YW1wIEZvcm1hdCBpbiBhIFR3by1XYXkgQWN0aXZl IE1lYXN1cmVtZW50IFByb3RvY29sCiAgICAgICAgICAgICAgKFRXQU1QKSIsIFJGQyA4MTg2LCBE T0kgMTAuMTc0ODcvUkZDODE4NiwgSnVuZSAyMDE3LAogICAgICAgICAgICAgIDxodHRwczovL3d3 dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzgxODY+LgoKICAgW1JGQzg1NDVdICBNb3J0b24sIEEu LCBFZC4gYW5kIEcuIE1pcnNreSwgRWQuLCAiV2VsbC1Lbm93biBQb3J0CiAgICAgICAgICAgICAg QXNzaWdubWVudHMgZm9yIHRoZSBPbmUtV2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbAog ICAgICAgICAgICAgIChPV0FNUCkgYW5kIHRoZSBUd28tV2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQ cm90b2NvbAogICAgICAgICAgICAgIChUV0FNUCkiLCBSRkMgODU0NSwgRE9JIDEwLjE3NDg3L1JG Qzg1NDUsIE1hcmNoIDIwMTksCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL2luZm8vcmZjODU0NT4uCgo4LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbQkJG LlRSLTM5MF0KICAgICAgICAgICAgICAiUGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQgZnJvbSBJUCBF ZGdlIHRvIEN1c3RvbWVyCiAgICAgICAgICAgICAgRXF1aXBtZW50IHVzaW5nIFRXQU1QIExpZ2h0 IiwgQkJGIFRSLTM5MCwgTWF5IDIwMTcuCgogICBbSS1ELmlldGYtaXBwbS1zdGFtcC1vcHRpb24t dGx2XQogICAgICAgICAgICAgIE1pcnNreSwgRy4sIFhpYW8sIE0uLCBKdW4sIEcuLCBOeWRlbGws IEguLCBhbmQgUi4gRm9vdGUsCiAgICAgICAgICAgICAgIlNpbXBsZSBUd28td2F5IEFjdGl2ZSBN ZWFzdXJlbWVudCBQcm90b2NvbCBPcHRpb25hbAogICAgICAgICAgICAgIEV4dGVuc2lvbnMiLCBk cmFmdC1pZXRmLWlwcG0tc3RhbXAtb3B0aW9uLXRsdi0wMCAod29yayBpbgogICAgICAgICAgICAg IHByb2dyZXNzKSwgSnVseSAyMDE5LgoKICAgW0ktRC5pZXRmLWlwcG0tc3RhbXAteWFuZ10KICAg ICAgICAgICAgICBNaXJza3ksIEcuLCBYaWFvLCBNLiwgYW5kIFcuIEx1bywgIlNpbXBsZSBUd28t d2F5IEFjdGl2ZQogICAgICAgICAgICAgIE1lYXN1cmVtZW50IFByb3RvY29sIChTVEFNUCkgRGF0 YSBNb2RlbCIsIGRyYWZ0LWlldGYtaXBwbS0KICAgICAgICAgICAgICBzdGFtcC15YW5nLTAzICh3 b3JrIGluIHByb2dyZXNzKSwgTWFyY2ggMjAxOS4KCiAgIFtSRkMyMTA0XSAgS3Jhd2N6eWssIEgu LCBCZWxsYXJlLCBNLiwgYW5kIFIuIENhbmV0dGksICJITUFDOiBLZXllZC0KICAgICAgICAgICAg ICBIYXNoaW5nIGZvciBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIiwgUkZDIDIxMDQsCiAgICAgICAg ICAgICAgRE9JIDEwLjE3NDg3L1JGQzIxMDQsIEZlYnJ1YXJ5IDE5OTcsCiAgICAgICAgICAgICAg PGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMjEwND4uCgogICBbUkZDNDg2OF0g IEtlbGx5LCBTLiBhbmQgUy4gRnJhbmtlbCwgIlVzaW5nIEhNQUMtU0hBLTI1NiwgSE1BQy1TSEEt CiAgICAgICAgICAgICAgMzg0LCBhbmQgSE1BQy1TSEEtNTEyIHdpdGggSVBzZWMiLCBSRkMgNDg2 OCwKICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDNDg2OCwgTWF5IDIwMDcsCiAgICAgICAg ICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNDg2OD4uCgogICBbUkZD Nzc1MF0gIEhlZGluLCBKLiwgTWlyc2t5LCBHLiwgYW5kIFMuIEJhaWxsYXJnZW9uLCAiRGlmZmVy ZW50aWF0ZWQKICAgICAgICAgICAgICBTZXJ2aWNlIENvZGUgUG9pbnQgYW5kIEV4cGxpY2l0IENv bmdlc3Rpb24gTm90aWZpY2F0aW9uCiAgICAgICAgICAgICAgTW9uaXRvcmluZyBpbiB0aGUgVHdv LVdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wKICAgICAgICAgICAgICAoVFdBTVApIiwg UkZDIDc3NTAsIERPSSAxMC4xNzQ4Ny9SRkM3NzUwLCBGZWJydWFyeSAyMDE2LAogICAgICAgICAg ICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc3NTA+LgoKICAgW1JGQzgw ODVdICBFZ2dlcnQsIEwuLCBGYWlyaHVyc3QsIEcuLCBhbmQgRy4gU2hlcGhlcmQsICJVRFAgVXNh Z2UKICAgICAgICAgICAgICBHdWlkZWxpbmVzIiwgQkNQIDE0NSwgUkZDIDgwODUsIERPSSAxMC4x NzQ4Ny9SRkM4MDg1LAogICAgICAgICAgICAgIE1hcmNoIDIwMTcsIDxodHRwczovL3d3dy5yZmMt ZWRpdG9yLm9yZy9pbmZvL3JmYzgwODU+LgoKCgoKTWlyc2t5LCBldCBhbC4gICAgICAgICAgRXhw aXJlcyBGZWJydWFyeSAyNywgMjAyMCAgICAgICAgICAgICAgW1BhZ2UgMTRdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgICAgIFNUQU1QICAgICAgICAgICAgICAgICAgICAgIEF1Z3Vz dCAyMDE5CgoKQXV0aG9ycycgQWRkcmVzc2VzCgogICBHcmVnIE1pcnNreQogICBaVEUgQ29ycC4K CiAgIEVtYWlsOiBncmVnaW1pcnNreUBnbWFpbC5jb20KCgogICBHdW8gSnVuCiAgIFpURSBDb3Jw b3JhdGlvbgogICA2OCMgWmlqaW5naHVhIFJvYWQKICAgTmFuamluZywgSmlhbmdzdSAgMjEwMDEy CiAgIFAuUi5DaGluYQoKICAgUGhvbmU6ICs4NiAxODEwNTE4MzY2MwogICBFbWFpbDogZ3VvLmp1 bjJAenRlLmNvbS5jbgoKCiAgIEhlbnJpayBOeWRlbGwKICAgQWNjZWRpYW4gTmV0d29ya3MKCiAg IEVtYWlsOiBobnlkZWxsQGFjY2VkaWFuLmNvbQoKCiAgIFJpY2hhcmQgRm9vdGUKICAgTm9raWEK CiAgIEVtYWlsOiBmb290ZXIuZm9vdGVAbm9raWEuY29tCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK TWlyc2t5LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNywgMjAyMCAgICAgICAg ICAgICAgW1BhZ2UgMTVdCg== --000000000000681d2605910c6cc6 Content-Type: text/html; charset="UTF-8"; name="Diff_ draft-ietf-ippm-stamp-07.txt - draft-ietf-ippm-stamp-08.txt.html" Content-Disposition: attachment; filename="Diff_ draft-ietf-ippm-stamp-07.txt - draft-ietf-ippm-stamp-08.txt.html" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jzsyfu370 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPgo8IS0tIHNhdmVkIGZyb20gdXJsPSgwMDQyKWh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9y ZmNkaWZmL3JmY2RpZmYucHlodCAtLT4KPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5 OTkveGh0bWwiIGNsYXNzPSJncl9fd3d3Nl9pZXRmX29yZyI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPiAKICAg CiAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1TdHlsZS1UeXBlIiBjb250ZW50PSJ0ZXh0L2Nz cyI+IAogIDx0aXRsZT5EaWZmOiBkcmFmdC1pZXRmLWlwcG0tc3RhbXAtMDcudHh0IC0gZHJhZnQt aWV0Zi1pcHBtLXN0YW1wLTA4LnR4dDwvdGl0bGU+IAogIDxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+ IAogICAgYm9keSAgICB7IG1hcmdpbjogMC40ZXg7IG1hcmdpbi1yaWdodDogYXV0bzsgfSAKICAg IHRyICAgICAgeyB9IAogICAgdGQgICAgICB7IHdoaXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFtaWx5 OiBtb25vc3BhY2U7IHZlcnRpY2FsLWFsaWduOiB0b3A7IGZvbnQtc2l6ZTogMC44NmVtO30gCiAg ICB0aCAgICAgIHsgZm9udC1zaXplOiAwLjg2ZW07IH0gCiAgICAuc21hbGwgIHsgZm9udC1zaXpl OiAwLjZlbTsgZm9udC1zdHlsZTogaXRhbGljOyBmb250LWZhbWlseTogVmVyZGFuYSwgSGVsdmV0 aWNhLCBzYW5zLXNlcmlmOyB9IAogICAgLmxlZnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7 IH0gCiAgICAucmlnaHQgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgfSAKICAgIC5kaWZmICAg eyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NGOyB9IAogICAgLmxibG9jayB7IGJhY2tncm91bmQtY29s b3I6ICNCRkI7IH0gCiAgICAucmJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGODsgfSAKICAg IC5pbnNlcnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEZGOyB9IAogICAgLmRlbGV0ZSB7IGJhY2tn cm91bmQtY29sb3I6ICNBQ0Y7IH0gCiAgICAudm9pZCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZG QjsgfSAKICAgIC5jb250ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxpbmVi ciB7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0gCiAgICAubGluZW5vIHsgY29sb3I6IHJlZDsg YmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgZm9udC1zaXplOiAwLjdlbTsgdGV4dC1hbGlnbjogcmln aHQ7IHBhZGRpbmc6IDAgMnB4OyB9IAogICAgLmVsaXBzaXN7IGJhY2tncm91bmQtY29sb3I6ICNB QUE7IH0gCiAgICAubGVmdCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNEREQ7IH0gCiAgICAu cmlnaHQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxibG9jayAuY29u dCB7IGJhY2tncm91bmQtY29sb3I6ICM5RDk7IH0gCiAgICAucmJsb2NrIC5jb250IHsgYmFja2dy b3VuZC1jb2xvcjogI0RENjsgfSAKICAgIC5pbnNlcnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9y OiAjMEREOyB9IAogICAgLmRlbGV0ZSAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICM4QUQ7IH0g CiAgICAuc3RhdHMsIC5zdGF0cyB0ZCwgLnN0YXRzIHRoIHsgYmFja2dyb3VuZC1jb2xvcjogI0VF RTsgcGFkZGluZzogMnB4IDA7IH0gCiAgICBzcGFuLmhpZGUgeyBkaXNwbGF5OiBub25lOyBjb2xv cjogI2FhYTt9ICAgIGE6aG92ZXIgc3BhbiB7IGRpc3BsYXk6IGlubGluZTsgfSAgICB0ci5jaGFu Z2UgeyBiYWNrZ3JvdW5kLWNvbG9yOiBncmF5OyB9IAogICAgdHIuY2hhbmdlIGEgeyB0ZXh0LWRl Y29yYXRpb246IG5vbmU7IGNvbG9yOiBibGFjayB9IAogIDwvc3R5bGU+IAogICAgIDxzY3JpcHQ+ CnZhciBjaHVua19pbmRleCA9IDA7CnZhciBvbGRfY2h1bmsgPSBudWxsOwoKZnVuY3Rpb24gZm9y bWF0X2NodW5rKGluZGV4KSB7CiAgICB2YXIgcHJlZml4ID0gImRpZmYiOwogICAgdmFyIHN0ciA9 IGluZGV4LnRvU3RyaW5nKCk7CiAgICBmb3IgKHg9MDsgeDwoNC1zdHIubGVuZ3RoKTsgKyt4KSB7 CiAgICAgICAgcHJlZml4Kz0nMCc7CiAgICB9CiAgICByZXR1cm4gcHJlZml4ICsgc3RyOwp9Cgpm dW5jdGlvbiBmaW5kX2NodW5rKG4pewogICAgcmV0dXJuIGRvY3VtZW50LnF1ZXJ5U2VsZWN0b3Io J3RyW2lkJD0iJyArIG4gKyAnIl0nKTsKfQoKZnVuY3Rpb24gY2hhbmdlX2NodW5rKG9mZnNldCkg ewogICAgdmFyIGluZGV4ID0gY2h1bmtfaW5kZXggKyBvZmZzZXQ7CiAgICB2YXIgbmV3X3N0cjsK ICAgIHZhciBuZXdfY2h1bms7CgogICAgbmV3X3N0ciA9IGZvcm1hdF9jaHVuayhpbmRleCk7CiAg ICBuZXdfY2h1bmsgPSBmaW5kX2NodW5rKG5ld19zdHIpOwogICAgaWYgKCFuZXdfY2h1bmspIHsK ICAgICAgICByZXR1cm47CiAgICB9CiAgICBpZiAob2xkX2NodW5rKSB7CiAgICAgICAgb2xkX2No dW5rLnN0eWxlLm91dGxpbmUgPSAiIjsKICAgIH0KICAgIG9sZF9jaHVuayA9IG5ld19jaHVuazsK ICAgIG9sZF9jaHVuay5zdHlsZS5vdXRsaW5lID0gIjFweCBzb2xpZCByZWQiOwogICAgd2luZG93 LmxvY2F0aW9uLnJlcGxhY2UoIiMiICsgbmV3X3N0cikKICAgIHdpbmRvdy5zY3JvbGxCeSgwLC0x MDApOwogICAgY2h1bmtfaW5kZXggPSBpbmRleDsKfQoKZG9jdW1lbnQub25rZXlkb3duID0gZnVu Y3Rpb24oZSkgewogICAgc3dpdGNoIChlLmtleUNvZGUpIHsKICAgIGNhc2UgNzg6CiAgICAgICAg Y2hhbmdlX2NodW5rKDEpOwogICAgICAgIGJyZWFrOwogICAgY2FzZSA4MDoKICAgICAgICBjaGFu Z2VfY2h1bmsoLTEpOwogICAgICAgIGJyZWFrOwogICAgfQp9OwogICA8L3NjcmlwdD4gCjwvaGVh ZD4gCjxib2R5IGRhdGEtZ3ItYy1zLWxvYWRlZD0idHJ1ZSI+IAogIDx0YWJsZSBib3JkZXI9IjAi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+IAogIDx0Ym9keT48dHIgaWQ9InBhcnQt MSIgYmdjb2xvcj0ib3JhbmdlIj48dGg+PC90aD48dGg+PGEgaHJlZj0iaHR0cHM6Ly93d3c2Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWlwcG0tc3RhbXAtMDcudHh0IiBzdHlsZT0i Y29sb3I6IzAwODsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij4mbHQ7PC9hPiZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0tc3RhbXAtMDcudHh0 IiBzdHlsZT0iY29sb3I6IzAwOCI+ZHJhZnQtaWV0Zi1pcHBtLXN0YW1wLTA3LnR4dDwvYT4mbmJz cDs8L3RoPjx0aD4gPC90aD48dGg+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtaXBwbS1zdGFtcC0wOC50eHQiIHN0eWxlPSJjb2xvcjojMDA4Ij5k cmFmdC1pZXRmLWlwcG0tc3RhbXAtMDgudHh0PC9hPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3 Ni5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1pcHBtLXN0YW1wLTA4LnR4dCIgc3R5 bGU9ImNvbG9yOiMwMDg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Jmd0OzwvYT48L3RoPjx0aD48 L3RoPjwvdHI+IAogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEcuIE1pcnNreTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi Pk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEcuIE1pcnNreTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+SW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWlRFIENv cnAuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+SW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWlRFIENvcnAuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5JbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHLiBKdW48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij5JbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBHLiBKdW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDEiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+RXhwaXJlczogRmVicnVh cnkgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTM8L3NwYW4+LCAyMDIwICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFpURSBDb3Jwb3JhdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj5FeHBpcmVzOiBGZWJydWFyeSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4yNzwvc3Bhbj4sIDIw MjAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWlRFIENvcnBvcmF0aW9uPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBILiBOeWRlbGw8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBILiBOeWRlbGw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBY2Nl ZGlhbiBOZXR3b3JrczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBY2NlZGlhbiBOZXR3 b3JrczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIEZvb3RlPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIEZvb3RlPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgTm9raWE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTm9raWE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0ciBpZD0iZGlmZjAwMDIiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXVndXN0IDxzcGFuIGNsYXNzPSJkZWxldGUi PjEyPC9zcGFuPiwgMjAxOTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBdWd1c3Qg PHNwYW4gY2xhc3M9Imluc2VydCI+MjY8L3NwYW4+LCAyMDE5PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgIFNpbXBsZSBUd28td2F5IEFjdGl2ZSBNZWFzdXJl bWVudCBQcm90b2NvbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg ICAgIFNpbXBsZSBUd28td2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwMyI+PHRkPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWlwcG0tc3RhbXAtMDxzcGFuIGNs YXNzPSJkZWxldGUiPjc8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg ICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtaXBwbS1zdGFtcC0wPHNwYW4gY2xhc3M9 Imluc2VydCI+ODwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QWJzdHJh Y3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5BYnN0cmFjdDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIFNpbXBsZSBU d28td2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgU2ltcGxlIFR3by13YXkgQWN0 aXZlIE1lYXN1cmVtZW50IFByb3RvY29sPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3 aGljaCBlbmFibGVzIHRoZSBtZWFzdXJlbWVudCBvZiBib3RoIG9uZS13YXkgYW5kIHJvdW5kLXRy aXA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3aGljaCBlbmFibGVzIHRoZSBt ZWFzdXJlbWVudCBvZiBib3RoIG9uZS13YXkgYW5kIHJvdW5kLXRyaXA8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHBlcmZvcm1hbmNlIG1ldHJpY3MgbGlrZSBkZWxheSwgZGVsYXkgdmFy aWF0aW9uLCBhbmQgcGFja2V0IGxvc3MuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgcGVyZm9ybWFuY2UgbWV0cmljcyBsaWtlIGRlbGF5LCBkZWxheSB2YXJpYXRpb24sIGFuZCBw YWNrZXQgbG9zcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+U3RhdHVzIG9mIFRo aXMgTWVtbzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPlN0YXR1cyBvZiBUaGlzIE1l bW88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBJbnRlcm5ldC1EcmFm dCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGlu IGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTIiIGNsYXNzPSJjaGFuZ2UiPjx0ZD48L3RkPjx0 aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3 dzYuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC0yIj48ZW0+IHBhZ2UgMSwgbGlu ZSAzNzxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+ PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8v d3d3Ni5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTIiPjxlbT4gcGFnZSAxLCBs aW5lIDM3PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0 IEVuZ2luZWVyaW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQt RHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0 aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBz IG1heSBhbHNvIGRpc3RyaWJ1dGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHdvcmtp bmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50 ZXJuZXQtPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd29ya2luZyBkb2N1bWVu dHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC08L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERyYWZ0cyBpcyBhdCBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBEcmFmdHMgaXMgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMv Y3VycmVudC8uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUg ZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRoczwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Ig b2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQg Ynkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg dGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZl cmVuY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aW1lLiAgSXQgaXMgaW5h cHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4g YXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNz LiI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJk aWZmMDAwNCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9u IEZlYnJ1YXJ5IDxzcGFuIGNsYXNzPSJkZWxldGUiPjEzPC9zcGFuPiwgMjAyMC48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGly ZSBvbiBGZWJydWFyeSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4yNzwvc3Bhbj4sIDIwMjAuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij5Db3B5cmlnaHQgTm90aWNlPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIENvcHlyaWdodCAoYykgMjAxOSBJRVRGIFRydXN0IGFuZCB0aGUgcGVy c29ucyBpZGVudGlmaWVkIGFzIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IENvcHlyaWdodCAoYykgMjAxOSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVk IGFzIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4g IEFsbCByaWdodHMgcmVzZXJ2ZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5k IHRoZSBJRVRGIFRydXN0J3MgTGVnYWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdz IExlZ2FsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQcm92aXNpb25zIFJlbGF0aW5n IHRvIElFVEYgRG9jdW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUHJv dmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgKGh0dHBzOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVj dCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIChodHRw czovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUg b2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9j dW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2 aWV3IHRoZXNlIGRvY3VtZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHIgaWQ9InBhcnQtMyIgY2xhc3M9ImNoYW5nZSI+PHRkPjwvdGQ+PHRoPjxzbWFs bD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRm Lm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTMiPjxlbT4gcGFnZSAyLCBsaW5lIDIzPHNw YW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNt YWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2Lmll dGYub3JnL3JmY2RpZmYvcmZjZGlmZi5weWh0I3BhcnQtMyI+PGVtPiBwYWdlIDIsIGxpbmUgMjM8 c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAy LjIuICBSZXF1aXJlbWVudHMgTGFuZ3VhZ2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAyLjIuICBSZXF1 aXJlbWVudHMgTGFuZ3VhZ2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAz PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAzLiAgU29mdHdhcml6YXRpb24gb2YgUGVy Zm9ybWFuY2UgTWVhc3VyZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAzLiAgU29mdHdhcml6YXRpb24gb2YgUGVyZm9ybWFuY2Ug TWVhc3VyZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIDQuICBUaGVvcnkgb2YgT3BlcmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgNDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IDQuICBUaGVvcnkgb2YgT3BlcmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgNDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA0LjEuICBTZXNz aW9uLVNlbmRlciBCZWhhdmlvciBhbmQgUGFja2V0IEZvcm1hdCAuIC4gLiAuIC4gLiAuIC4gICA1 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA0LjEuICBTZXNzaW9uLVNlbmRl ciBCZWhhdmlvciBhbmQgUGFja2V0IEZvcm1hdCAuIC4gLiAuIC4gLiAuIC4gICA1PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgNC4xLjEuICBTZXNzaW9uLVNlbmRlciBQYWNrZXQg Rm9ybWF0IGluIFVuYXV0aGVudGljYXRlZCBNb2RlICAgIDU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgICAgNC4xLjEuICBTZXNzaW9uLVNlbmRlciBQYWNrZXQgRm9ybWF0IGlu IFVuYXV0aGVudGljYXRlZCBNb2RlICAgIDU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICA0LjEuMi4gIFNlc3Npb24tU2VuZGVyIFBhY2tldCBGb3JtYXQgaW4gQXV0aGVudGljYXRl ZCBNb2RlICAuICAgNjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICA0LjEu Mi4gIFNlc3Npb24tU2VuZGVyIFBhY2tldCBGb3JtYXQgaW4gQXV0aGVudGljYXRlZCBNb2RlICAu ICAgNjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA0LjIuICBTZXNzaW9uLVJlZmxl Y3RvciBCZWhhdmlvciBhbmQgUGFja2V0IEZvcm1hdCAgLiAuIC4gLiAuIC4gICA3PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA0LjIuICBTZXNzaW9uLVJlZmxlY3RvciBCZWhh dmlvciBhbmQgUGFja2V0IEZvcm1hdCAgLiAuIC4gLiAuIC4gICA3PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgNC4yLjEuICBTZXNzaW9uLVJlZmxlY3RvciBQYWNrZXQgRm9ybWF0 IGluIFVuYXV0aGVudGljYXRlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICA0LjIuMS4gIFNlc3Npb24tUmVmbGVjdG9yIFBhY2tldCBGb3JtYXQgaW4gVW5hdXRoZW50aWNh dGVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICBNb2RlICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDg8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICBNb2RlICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDg8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICA0LjIuMi4gIFNlc3Npb24tUmVmbGVjdG9yIFBhY2tldCBGb3JtYXQg aW4gQXV0aGVudGljYXRlZCBNb2RlICAgOTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgICA0LjIuMi4gIFNlc3Npb24tUmVmbGVjdG9yIFBhY2tldCBGb3JtYXQgaW4gQXV0aGVu dGljYXRlZCBNb2RlICAgOTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyIGlkPSJkaWZmMDAwNSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDQuMy4gIEludGVncml0eSA8c3BhbiBj bGFzcz0iZGVsZXRlIj5hbmQgQ29uZmlkZW50aWFsaXR5PC9zcGFuPiBQcm90ZWN0aW9uIGluIFNU QU1QIC4gLiAuIC4gIDEwPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgNC4z LiAgSW50ZWdyaXR5IFByb3RlY3Rpb24gaW4gU1RBTVAgLiAuIC4gLiA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4uIC4gLiAuIC4gLiAuIC4gLiAuPC9zcGFuPiAgMTA8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgICA0LjQuICBJbnRlcm9wZXJhYmlsaXR5IHdpdGggVFdBTVAgTGlnaHQgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgICAgNC40LiAgPHNwYW4gY2xhc3M9Imluc2VydCI+Q29uZmlkZW50aWFsaXR5IFByb3RlY3Rp b24gaW4gU1RBTVAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMTwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjExPC9z cGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gICAgIDQuNS48L3NwYW4+ICBJbnRlcm9wZXJhYmlsaXR5IHdpdGggVFdBTVAgTGlnaHQgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA1LiAgSUFOQSBDb25zaWRlcmF0aW9u cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9 Imluc2VydCI+MTI8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA2LiAgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMTI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA2LiAgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTI8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDcuICBBY2tub3dsZWRnbWVudHMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIDcuICBBY2tub3dsZWRnbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwNiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA4LiAgUmVmZXJl bmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg PHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTI8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgIDguICBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xMzwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICA4LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUi PjEyPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDguMS4gIE5v cm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg PHNwYW4gY2xhc3M9Imluc2VydCI+MTM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgIDguMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMTQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDgu Mi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0i ZGlmZjAwMDciPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE8c3BhbiBjbGFzcz0iZGVsZXRlIj40 PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBBdXRob3JzJyBBZGRy ZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTxz cGFuIGNsYXNzPSJpbnNlcnQiPjU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjEuICBJbnRyb2R1Y3Rpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4xLiAg SW50cm9kdWN0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERldmVsb3Bt ZW50IGFuZCBkZXBsb3ltZW50IG9mIFR3by1XYXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29s PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRGV2ZWxvcG1lbnQgYW5kIGRlcGxv eW1lbnQgb2YgVHdvLVdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2w8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIChUV0FNUCkgW1JGQzUzNTddIGFuZCBpdHMgZXh0ZW5zaW9ucywg ZS5nLiwgW1JGQzYwMzhdIHRoYXQgZGVmaW5lZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIChUV0FNUCkgW1JGQzUzNTddIGFuZCBpdHMgZXh0ZW5zaW9ucywgZS5nLiwgW1JGQzYw MzhdIHRoYXQgZGVmaW5lZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZmVhdHVyZXMg c3VjaCBhcyBSZWZsZWN0IE9jdGV0cyBhbmQgU3ltbWV0cmljYWwgU2l6ZSBmb3IgVFdBTVA8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBmZWF0dXJlcyBzdWNoIGFzIFJlZmxlY3Qg T2N0ZXRzIGFuZCBTeW1tZXRyaWNhbCBTaXplIGZvciBUV0FNUDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgcHJvdmlkZWQgaW52YWx1YWJsZSBleHBlcmllbmNlLiAgU2V2ZXJhbCBpbmRl cGVuZGVudCBpbXBsZW1lbnRhdGlvbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBwcm92aWRlZCBpbnZhbHVhYmxlIGV4cGVyaWVuY2UuICBTZXZlcmFsIGluZGVwZW5kZW50IGlt cGxlbWVudGF0aW9uczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy IGlkPSJkaWZmMDAwOCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBleGlzdCwgaGF2ZSBiZWVuIDxzcGFuIGNsYXNz PSJkZWxldGUiPmRlcGxveWVkPC9zcGFuPiBhbmQgcHJvdmlkZSBpbXBvcnRhbnQgb3BlcmF0aW9u YWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2Vy dCI+b2YgYm90aCBUV0FNUCBhbmQgVFdBTVAgTGlnaHQ8L3NwYW4+IGV4aXN0LCBoYXZlIGJlZW4g PHNwYW4gY2xhc3M9Imluc2VydCI+ZGVwbG95ZWQsPC9zcGFuPiBhbmQgcHJvdmlkZTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudHMuICA8c3Bh biBjbGFzcz0iZGVsZXRlIj5BdCB0aGUgc2FtZSB0aW1lLCB0aGVyZSBoYXMgYmVlbjwvc3Bhbj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgaW1wb3J0YW50IG9wZXJhdGlvbmFs IHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50cy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgbm90aWNlYWJsZSBpbnRlcmVzdCBpbiB1c2luZyBhIG1v cmUgc3RyYWlnaHRmb3J3YXJkIG1lY2hhbmlzbSBmb3I8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFz cz0iZGVsZXRlIj4gICBhY3RpdmUgcGVyZm9ybWFuY2UgbW9uaXRvcmluZyB0aGF0IGNhbiBwcm92 aWRlIGRldGVybWluaXN0aWMgYmVoYXZpb3I8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVs ZXRlIj4gICBhbmQgaW5oZXJpdCBzZXBhcmF0aW9uIG9mIGNvbnRyb2wgKHZlbmRvci1zcGVjaWZp YyBjb25maWd1cmF0aW9uIG9yPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAg b3JjaGVzdHJhdGlvbikgYW5kIHRlc3QgZnVuY3Rpb25zLiAgT25lIG9mIHN1Y2ggaXMgUGVyZm9y bWFuY2U8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBNZWFzdXJlbWVudCBm cm9tIElQIEVkZ2UgdG8gQ3VzdG9tZXIgRXF1aXBtZW50IHVzaW5nIFRXQU1QIExpZ2h0IGZyb208 L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBCcm9hZGJhbmQgRm9ydW0gW0JC Ri5UUi0zOTBdIHVzZWQgYXMgdGhlIHJlZmVyZW5jZSBUV0FNUCBMaWdodCB0aGF0LDwvc3Bhbj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIGFjY29yZGluZyB0byBbUkZDODU0NV0sIGlu Y2x1ZGVzIHN1Yi1zZXQgb2YgVFdBTVAtVGVzdCBmdW5jdGlvbnMgaW48L3NwYW4+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBjb21iaW5hdGlvbiB3aXRoIG90aGVyIGFwcGxpY2F0aW9u cyB0aGF0IHByb3ZpZGUsIGZvciBleGFtcGxlLDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJk ZWxldGUiPiAgIGNvbnRyb2wgYW5kIHNlY3VyaXR5LiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFu IGFjdGl2ZSBwZXJmb3JtYW5jZTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAg IG1lYXN1cmVtZW50IHRlc3QgcHJvdG9jb2wsIFNpbXBsZSBUd28td2F5IEFjdGl2ZSBNZWFzdXJl bWVudCBQcm90b2NvbDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIChTVEFN UCksIHRoYXQgZW5hYmxlcyBtZWFzdXJlbWVudCBvZiBib3RoIG9uZS13YXkgYW5kIHJvdW5kLXRy aXA8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBwZXJmb3JtYW5jZSBtZXRy aWNzIGxpa2UgZGVsYXksIGRlbGF5IHZhcmlhdGlvbiwgYW5kIHBhY2tldCBsb3NzLjwvc3Bhbj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIFNvbWUgVFdBTVAgZXh0ZW5zaW9ucywgZS5n LiwgW1JGQzc3NTBdIGFyZSBzdXBwb3J0ZWQgYnkgdGhlPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xh c3M9ImRlbGV0ZSI+ICAgZXh0ZW5zaW9ucyB0byBTVEFNUCBiYXNlIHNwZWNpZmljYXRpb24gaW48 L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBbSS1ELmlldGYtaXBwbS1zdGFt cC1vcHRpb24tdGx2XS48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj48L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4yLiAgQ29udmVudGlvbnMgdXNlZCBpbiB0aGlz IGRvY3VtZW50PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+PC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+Mi4xLiAgVGVybWlub2xvZ3k8L3NwYW4+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA5Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNz PSJkZWxldGUiPkFFUyBBZHZhbmNlZCBFbmNyeXB0aW9uIFN0YW5kYXJkPC9zcGFuPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5BdCB0aGUg c2FtZSB0aW1lLCB0aGVyZSBoYXMgYmVlbiBub3RpY2VhYmxlIGludGVyZXN0IGluIHVzaW5nIGEg bW9yZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHN0cmFpZ2h0Zm9yd2Fy ZCBtZWNoYW5pc20gZm9yIGFjdGl2ZSBwZXJmb3JtYW5jZSBtb25pdG9yaW5nIHRoYXQgY2FuPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgcHJvdmlkZSBkZXRlcm1pbmlzdGlj IGJlaGF2aW9yIGFuZCBpbmhlcml0IHNlcGFyYXRpb24gb2YgY29udHJvbDwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICh2ZW5kb3Itc3BlY2lmaWMgY29uZmlndXJhdGlvbiBv ciBvcmNoZXN0cmF0aW9uKSBhbmQgdGVzdCBmdW5jdGlvbnMuPC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4g Y2xhc3M9Imluc2VydCI+ICAgUmVjZW50IHdvcmsgb24gSVAgRWRnZSB0byBDdXN0b21lciBFcXVp cG1lbnQgdXNpbmcgVFdBTVAgTGlnaHQgZnJvbTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgIEJyb2FkYmFuZCBGb3J1bSBbQkJGLlRSLTM5MF0gZGVtb25zdHJhdGVkIHRoYXQg aW50ZXJvcGVyYWJpbGl0eSBhbW9uZzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgIGltcGxlbWVudGF0aW9ucyBvZiBUV0FNUCBMaWdodCBpcyBjaGFsbGVuZ2VkIGJlY2F1c2Ug dGhlIGNvbXBvc2l0aW9uPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgYW5k IG9wZXJhdGlvbiBvZiBUV0FNUCBMaWdodCB3ZXJlIG5vdCBzdWZmaWNpZW50bHkgc3BlY2lmaWVk IGluPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgW1JGQzUzNTddLiAgQWNj b3JkaW5nIHRvIFtSRkM4NTQ1XSwgVFdBTVAgTGlnaHQgaW5jbHVkZXMgc3ViLXNldCBvZjwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFRXQU1QLVRlc3QgZnVuY3Rpb25zIHRv IHByb3ZpZGUgY29tcHJlaGVuc2l2ZSBzb2x1dGlvbiByZXF1aXJlczwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPiAgIHN1cHBvcnQgYnkgb3RoZXIgYXBwbGljYXRpb25zIHRoYXQg cHJvdmlkZSwgZm9yIGV4YW1wbGUsIGNvbnRyb2wgYW5kPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICAgc2VjdXJpdHkuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDEwIj48dGQ+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFu IGNsYXNzPSJkZWxldGUiPkNCQyBDaXBoZXIgQmxvY2sgQ2hhaW5pbmc8L3NwYW4+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPlRoaXMgZG9j dW1lbnQgZGVmaW5lcyBhbiBhY3RpdmUgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgdGVzdDwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHByb3RvY29sLCBTaW1wbGUgVHdvLXdh eSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wgKFNUQU1QKSwgdGhhdDwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGVuYWJsZXMgbWVhc3VyZW1lbnQgb2YgYm90aCBvbmUt d2F5IGFuZCByb3VuZC10cmlwIHBlcmZvcm1hbmNlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+ICAgbWV0cmljcyBsaWtlIGRlbGF5LCBkZWxheSB2YXJpYXRpb24sIGFuZCBwYWNr ZXQgbG9zcy4gIFNvbWUgVFdBTVA8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICBleHRlbnNpb25zLCBlLmcuLCBbUkZDNzc1MF0gYXJlIHN1cHBvcnRlZCBieSB0aGUgZXh0ZW5z aW9ucyB0byBTVEFNUDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGJhc2Ug c3BlY2lmaWNhdGlvbiBpbiBbSS1ELmlldGYtaXBwbS1zdGFtcC1vcHRpb24tdGx2XS48L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlm ZjAwMTEiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgRUNCIEVsZWN0cm9uaWMg Q29va2Jvb2s8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPjIuICBDb252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQ8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlm ZjAwMTIiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgS0VLIEtleS1lbmNyeXB0 aW9uIEtlPC9zcGFuPnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+Mi4xLiAgVGVybWlub2xvZzwvc3Bhbj55PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIFNUQU1QIC0gU2ltcGxlIFR3by13YXkgQWN0aXZlIE1lYXN1cmVtZW50 IFByb3RvY29sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgU1RBTVAgLSBTaW1w bGUgVHdvLXdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2w8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgTlRQIC0gTmV0d29yayBUaW1lIFByb3RvY29sPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTlRQIC0gTmV0d29yayBUaW1lIFByb3RvY29sPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFBUUCAtIFByZWNpc2lvbiBUaW1lIFByb3Rv Y29sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUFRQIC0gUHJlY2lzaW9uIFRp bWUgUHJvdG9jb2w8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSE1BQyBIYXNo ZWQgTWVzc2FnZSBBdXRoZW50aWNhdGlvbiBDb2RlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgSE1BQyBIYXNoZWQgTWVzc2FnZSBBdXRoZW50aWNhdGlvbiBDb2RlPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE9XQU1QIE9uZS1XYXkgQWN0aXZlIE1lYXN1cmVt ZW50IFByb3RvY29sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgT1dBTVAgT25l LVdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2w8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTQiIGNsYXNzPSJjaGFuZ2UiPjx0ZD48 L3RkPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRw czovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC00Ij48ZW0+IHBhZ2Ug NCwgbGluZSA0NzxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+ IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0 dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTQiPjxlbT4gcGFn ZSA0LCBsaW5lIDQ1PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0 ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHN1cHBvcnRzIHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNUIGJlIGFibGUgdG8gZGVm aW5lIHRoZSBwb3J0IG51bWJlciB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IHN1cHBvcnRzIHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNUIGJlIGFibGUgdG8gZGVmaW5lIHRoZSBw b3J0IG51bWJlciB0bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcmVjZWl2ZSBTVEFN UCB0ZXN0IHBhY2tldHMgZnJvbSBVc2VyIFBvcnRzIGFuZCBEeW5hbWljIFBvcnRzIHJhbmdlczwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHJlY2VpdmUgU1RBTVAgdGVzdCBwYWNr ZXRzIGZyb20gVXNlciBQb3J0cyBhbmQgRHluYW1pYyBQb3J0cyByYW5nZXM8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIHRoYXQgYXJlIGRlZmluZWQgaW4gW1JGQzYzMzVdLiAgU1RBTVAg ZGVmaW5lcyB0d28gZGlmZmVyZW50IHRlc3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICB0aGF0IGFyZSBkZWZpbmVkIGluIFtSRkM2MzM1XS4gIFNUQU1QIGRlZmluZXMgdHdvIGRp ZmZlcmVudCB0ZXN0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwYWNrZXQgZm9ybWF0 cywgb25lIGZvciBwYWNrZXRzIHRyYW5zbWl0dGVkIGJ5IHRoZSBTVEFNUC1TZXNzaW9uLTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHBhY2tldCBmb3JtYXRzLCBvbmUgZm9yIHBh Y2tldHMgdHJhbnNtaXR0ZWQgYnkgdGhlIFNUQU1QLVNlc3Npb24tPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBTZW5kZXIgYW5kIG9uZSBmb3IgcGFja2V0cyB0cmFuc21pdHRlZCBieSB0 aGUgU1RBTVAtU2Vzc2lvbi08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBTZW5k ZXIgYW5kIG9uZSBmb3IgcGFja2V0cyB0cmFuc21pdHRlZCBieSB0aGUgU1RBTVAtU2Vzc2lvbi08 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFJlZmxlY3Rvci48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBSZWZsZWN0b3IuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIFNUQU1QIHN1cHBvcnRzIHR3byBtb2RlczogdW5hdXRoZW50aWNhdGVkIGFuZCBh dXRoZW50aWNhdGVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNUQU1QIHN1 cHBvcnRzIHR3byBtb2RlczogdW5hdXRoZW50aWNhdGVkIGFuZCBhdXRoZW50aWNhdGVkLjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVW5hdXRoZW50aWNhdGVkIFNUQU1QIHRlc3QgcGFj a2V0cywgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMS4xIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIFVuYXV0aGVudGljYXRlZCBTVEFNUCB0ZXN0IHBhY2tldHMsIGRlZmluZWQg aW4gU2VjdGlvbiA0LjEuMSBhbmQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNlY3Rp b24gNC4yLjEsIGVuc3VyZSBpbnRlcndvcmtpbmcgYmV0d2VlbiBTVEFNUCBhbmQgVFdBTVAgTGln aHQgYXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBTZWN0aW9uIDQuMi4xLCBl bnN1cmUgaW50ZXJ3b3JraW5nIGJldHdlZW4gU1RBTVAgYW5kIFRXQU1QIExpZ2h0IGFzPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDEzIj48dGQ+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NDwv c3Bhbj4gcGFja2V0IGZvcm1hdHMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuPHNwYW4gY2xhc3M9Imluc2VydCI+NTwvc3Bhbj4gcGFj a2V0IGZvcm1hdHMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEJ5IGRlZmF1 bHQsIFNUQU1QIHVzZXMgc3ltbWV0cmljYWwgcGFja2V0cywgaS5lLiwgc2l6ZSBvZiB0aGUgcGFj a2V0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQnkgZGVmYXVsdCwgU1RBTVAg dXNlcyBzeW1tZXRyaWNhbCBwYWNrZXRzLCBpLmUuLCBzaXplIG9mIHRoZSBwYWNrZXQ8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRyYW5zbWl0dGVkIGJ5IFNlc3Npb24tUmVmbGVjdG9y IGVxdWFscyB0aGUgc2l6ZSBvZiB0aGUgcGFja2V0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgdHJhbnNtaXR0ZWQgYnkgU2Vzc2lvbi1SZWZsZWN0b3IgZXF1YWxzIHRoZSBzaXpl IG9mIHRoZSBwYWNrZXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJlY2VpdmVkIGJ5 IHRoZSBTZXNzaW9uLVJlZmxlY3Rvci48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICByZWNlaXZlZCBieSB0aGUgU2Vzc2lvbi1SZWZsZWN0b3IuPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjQuMS4gIFNlc3Npb24tU2VuZGVyIEJlaGF2aW9yIGFuZCBQYWNrZXQgRm9y bWF0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NC4xLiAgU2Vzc2lvbi1TZW5kZXIg QmVoYXZpb3IgYW5kIFBhY2tldCBGb3JtYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgQmVjYXVzZSBTVEFNUCBzdXBwb3J0cyBzeW1tZXRyaWNhbCB0ZXN0IHBhY2tldHMsIFNU QU1QIFNlc3Npb24tU2VuZGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQmVj YXVzZSBTVEFNUCBzdXBwb3J0cyBzeW1tZXRyaWNhbCB0ZXN0IHBhY2tldHMsIFNUQU1QIFNlc3Np b24tU2VuZGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwYWNrZXQgaGFzIGEgbWlu aW11bSBzaXplIG9mIDQ0IG9jdGV0cyBpbiB1bmF1dGhlbnRpY2F0ZWQgbW9kZSwgc2VlPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcGFja2V0IGhhcyBhIG1pbmltdW0gc2l6ZSBv ZiA0NCBvY3RldHMgaW4gdW5hdXRoZW50aWNhdGVkIG1vZGUsIHNlZTwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgRmlndXJlIDIsIGFuZCAxMTIgb2N0ZXRzIGluIHRoZSBhdXRoZW50aWNh dGVkIG1vZGUsIHNlZSBGaWd1cmUgNC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBGaWd1cmUgMiwgYW5kIDExMiBvY3RldHMgaW4gdGhlIGF1dGhlbnRpY2F0ZWQgbW9kZSwgc2Vl IEZpZ3VyZSA0LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHIgaWQ9InBhcnQtNSIgY2xhc3M9ImNoYW5nZSI+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGlu ZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNk aWZmL3JmY2RpZmYucHlodCNwYXJ0LTUiPjxlbT4gcGFnZSA2LCBsaW5lIDc8c3BhbiBjbGFzcz0i aGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBp bmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZj ZGlmZi9yZmNkaWZmLnB5aHQjcGFydC01Ij48ZW0+IHBhZ2UgNiwgbGluZSA0PHNwYW4gY2xhc3M9 ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHBhY2tldC48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBwYWNrZXQuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIFRpbWVzdGFtcCBpcyBlaWdodCBvY3RldHMgbG9uZyBm aWVsZC4gIFNUQU1QIG5vZGUgTVVTVCBzdXBwb3J0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgbyAgVGltZXN0YW1wIGlzIGVpZ2h0IG9jdGV0cyBsb25nIGZpZWxkLiAgU1RBTVAg bm9kZSBNVVNUIHN1cHBvcnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIE5ldHdv cmsgVGltZSBQcm90b2NvbCAoTlRQKSB2ZXJzaW9uIDQgNjQtYml0IHRpbWVzdGFtcCBmb3JtYXQ8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBOZXR3b3JrIFRpbWUgUHJvdG9j b2wgKE5UUCkgdmVyc2lvbiA0IDY0LWJpdCB0aW1lc3RhbXAgZm9ybWF0PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICBbUkZDNTkwNV0sIHRoZSBmb3JtYXQgdXNlZCBpbiBbUkZDNTM1 N10uICBTVEFNUCBub2RlIE1BWSBzdXBwb3J0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgW1JGQzU5MDVdLCB0aGUgZm9ybWF0IHVzZWQgaW4gW1JGQzUzNTddLiAgU1RBTVAg bm9kZSBNQVkgc3VwcG9ydDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgSUVFRSAx NTg4djIgUHJlY2lzaW9uIFRpbWUgUHJvdG9jb2wgdHJ1bmNhdGVkIDY0LWJpdCB0aW1lc3RhbXA8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBJRUVFIDE1ODh2MiBQcmVjaXNp b24gVGltZSBQcm90b2NvbCB0cnVuY2F0ZWQgNjQtYml0IHRpbWVzdGFtcDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgZm9ybWF0IFtJRUVFLjE1ODguMjAwOF0sIHRoZSBmb3JtYXQg dXNlZCBpbiBbUkZDODE4Nl0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg Zm9ybWF0IFtJRUVFLjE1ODguMjAwOF0sIHRoZSBmb3JtYXQgdXNlZCBpbiBbUkZDODE4Nl0uPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIEVycm9yIEVzdGltYXRlIGlzIHR3 byBvY3RldHMgbG9uZyBmaWVsZCB3aXRoIGZvcm1hdCBkaXNwbGF5ZWQgaW48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvICBFcnJvciBFc3RpbWF0ZSBpcyB0d28gb2N0ZXRzIGxv bmcgZmllbGQgd2l0aCBmb3JtYXQgZGlzcGxheWVkIGluPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgICBGaWd1cmUgMzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg IEZpZ3VyZSAzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9 ImRpZmYwMDE0Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgMCAgICAgICAgICAgICAgICAgICAxPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgMCAgICAgICAgICAgICAgICAgICAx PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMSAyIDMgNCA1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAg ICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICB8U3xa fCAgIFNjYWxlICAgfCAgIE11bHRpcGxpZXIgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICAgIHxTfFp8ICAgU2NhbGUgICB8ICAgTXVsdGlwbGllciAgfDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDM6IEVycm9yIEVzdGltYXRlIEZvcm1h dDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICBG aWd1cmUgMzogRXJyb3IgRXN0aW1hdGUgRm9ybWF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgIHdoZXJlIFMsIFNjYWxlLCBhbmQgTXVsdGlwbGllciBmaWVsZHMgYXJlIGlu dGVycHJldGVkIGFzIHRoZXkgaGF2ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICAgIHdoZXJlIFMsIFNjYWxlLCBhbmQgTXVsdGlwbGllciBmaWVsZHMgYXJlIGludGVycHJldGVk IGFzIHRoZXkgaGF2ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy IGlkPSJkaWZmMDAxNSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICBiZWVuIGRlZmluZWQgaW4gc2VjdGlvbiA0 LjEuMiBbUkZDNDY1Nl07IGFuZCBaIGY8c3BhbiBjbGFzcz0iZGVsZXRlIj5pZWxkPC9zcGFuPiAt IGFzIGhhcyBiZWVuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIGJlZW4g ZGVmaW5lZCBpbiBzZWN0aW9uIDQuMS4yIFtSRkM0NjU2XTsgYW5kIFogZjxzcGFuIGNsYXNzPSJp bnNlcnQiPmxhZzwvc3Bhbj4gLSBhcyBoYXMgYmVlbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgZGVmaW5lZCBpbiBzZWN0aW9uIDIuMyBbUkZDODE4Nl06PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgZGVmaW5lZCBpbiBzZWN0aW9uIDIuMyBbUkZDODE4Nl06 PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICogIDAgLSBOVFAgNjQgYml0 IGZvcm1hdCBvZiBhIHRpbWVzdGFtcDs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICAqICAwIC0gTlRQIDY0IGJpdCBmb3JtYXQgb2YgYSB0aW1lc3RhbXA7PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICogIDEgLSBQVFB2MiB0cnVuY2F0ZWQgZm9ybWF0 IG9mIGEgdGltZXN0YW1wLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICog IDEgLSBQVFB2MiB0cnVuY2F0ZWQgZm9ybWF0IG9mIGEgdGltZXN0YW1wLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBUaGUgU1RBTVAgU2Vzc2lvbi1TZW5kZXIgYW5kIFNl c3Npb24tUmVmbGVjdG9yIE1BWSB1c2UsIG5vdCB1c2UsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgVGhlIFNUQU1QIFNlc3Npb24tU2VuZGVyIGFuZCBTZXNzaW9uLVJlZmxl Y3RvciBNQVkgdXNlLCBub3QgdXNlLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyIGlkPSJkaWZmMDAxNiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICBvciBzZXQgdmFsdWUgb2Yg dGhlIFogPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZmllbGQ8L3NwYW4+IGluIGFjY29yZGFuY2Ugd2l0 aCB0aGUgdGltZXN0YW1wPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIG9y IHNldCB2YWx1ZSBvZiB0aGUgWiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5mbGFnPC9zcGFuPiBpbiBh Y2NvcmRhbmNlIHdpdGggdGhlIHRpbWVzdGFtcCBmb3JtYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgICAgZm9ybWF0IGluIHVzZS4gIFRoaXMgb3B0aW9uYWwgZmllbGQgaXMgdG8g ZW5oYW5jZSBvcGVyYXRpb25zLCBidXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgICAgaW4gdXNlLiAgVGhpcyBvcHRpb25hbCBmaWVsZCBpcyB0byBlbmhhbmNlIG9wZXJhdGlv bnMsIGJ1dCBsb2NhbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICBsb2NhbCBj b25maWd1cmF0aW9uIG9yIGRlZmF1bHRzIGNvdWxkIGJlIHVzZWQgaW4gaXRzIHBsYWNlLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICBjb25maWd1cmF0aW9uIG9yIGRlZmF1 bHRzIGNvdWxkIGJlIHVzZWQgaW4gaXRzIHBsYWNlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBvICBNYXktYmUtWmVybyAoTUJaKSBmaWVsZCBpbiB0aGUgc2Vzc2lvbi1zZW5k ZXIgdW5hdXRoZW50aWNhdGVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAg TWF5LWJlLVplcm8gKE1CWikgZmllbGQgaW4gdGhlIHNlc3Npb24tc2VuZGVyIHVuYXV0aGVudGlj YXRlZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgcGFja2V0IGlzIDMwIG9jdGV0 cyBsb25nLiAgSXQgTUFZIGJlIGFsbCB6ZXJvZWQgb24gdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgcGFja2V0IGlzIDMwIG9jdGV0cyBsb25nLiAgSXQgTUFZIGJlIGFs bCB6ZXJvZWQgb24gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB0cmFuc21p c3Npb24gYW5kIE1VU1QgYmUgaWdub3JlZCBvbiByZWNlaXB0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgIHRyYW5zbWlzc2lvbiBhbmQgTVVTVCBiZSBpZ25vcmVkIG9uIHJl Y2VpcHQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjQuMS4yLiAgU2Vzc2lvbi1T ZW5kZXIgUGFja2V0IEZvcm1hdCBpbiBBdXRoZW50aWNhdGVkIE1vZGU8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij40LjEuMi4gIFNlc3Npb24tU2VuZGVyIFBhY2tldCBGb3JtYXQgaW4g QXV0aGVudGljYXRlZCBNb2RlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNU QU1QIFNlc3Npb24tU2VuZGVyIHBhY2tldCBmb3JtYXQgaW4gYXV0aGVudGljYXRlZCBtb2RlOjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNUQU1QIFNlc3Npb24tU2VuZGVyIHBh Y2tldCBmb3JtYXQgaW4gYXV0aGVudGljYXRlZCBtb2RlOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAy ICAgICAgICAgICAgICAgICAgIDM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg IDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAg ICAgIDM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlk PSJwYXJ0LTYiIGNsYXNzPSJjaGFuZ2UiPjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcgdG8g Y2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9y ZmNkaWZmLnB5aHQjcGFydC02Ij48ZW0+IHBhZ2UgMTAsIGxpbmUgNDE8c3BhbiBjbGFzcz0iaGlk ZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBpbmcg dG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlm Zi9yZmNkaWZmLnB5aHQjcGFydC02Ij48ZW0+IHBhZ2UgMTAsIGxpbmUgNDE8c3BhbiBjbGFzcz0i aGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBtb2RlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb2RlPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIFRoZSBmaWVsZCBkZWZpbml0aW9ucyBhcmUgdGhlIHNhbWUgYXMgdGhl IHVuYXV0aGVudGljYXRlZCBtb2RlLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFRoZSBmaWVsZCBkZWZpbml0aW9ucyBhcmUgdGhlIHNhbWUgYXMgdGhlIHVuYXV0aGVudGljYXRl ZCBtb2RlLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbGlzdGVkIGluIFNlY3Rpb24g NC4yLjEuICBBZGRpdGlvbmFsbHksIHRoZSBNQlogZmllbGQgaXMgdXNlZCB0bzwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGxpc3RlZCBpbiBTZWN0aW9uIDQuMi4xLiAgQWRkaXRp b25hbGx5LCB0aGUgTUJaIGZpZWxkIGlzIHVzZWQgdG88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIGFsaWduIHRoZSBwYWNrZXQgb24gMTYgb2N0ZXRzIGJvdW5kYXJ5LiAgVGhlIHZhbHVl IG9mIHRoZSBmaWVsZCBNQVk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbGln biB0aGUgcGFja2V0IG9uIDE2IG9jdGV0cyBib3VuZGFyeS4gIFRoZSB2YWx1ZSBvZiB0aGUgZmll bGQgTUFZPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBiZSB6ZXJvZWQgb24gdHJhbnNt aXNzaW9uIGFuZCBNVVNUIGJlIGlnbm9yZWQgb24gcmVjZWlwdC4gIEFsc28sPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYmUgemVyb2VkIG9uIHRyYW5zbWlzc2lvbiBhbmQgTVVT VCBiZSBpZ25vcmVkIG9uIHJlY2VpcHQuICBBbHNvLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgU1RBTVAgU2Vzc2lvbi1SZWZsZWN0b3IgdGVzdCBwYWNrZXQgZm9ybWF0IGluIGF1dGhl bnRpY2F0ZWQgbW9kZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNUQU1QIFNl c3Npb24tUmVmbGVjdG9yIHRlc3QgcGFja2V0IGZvcm1hdCBpbiBhdXRoZW50aWNhdGVkIG1vZGU8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGluY2x1ZGVzIGEga2V5IChITUFDKSAoW1JG QzIxMDRdKSBoYXNoIGF0IHRoZSBlbmQgb2YgdGhlIFBEVS4gIFRoZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIGluY2x1ZGVzIGEga2V5IChITUFDKSAoW1JGQzIxMDRdKSBoYXNo IGF0IHRoZSBlbmQgb2YgdGhlIFBEVS4gIFRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgZGV0YWlsZWQgdXNlIG9mIHRoZSBITUFDIGZpZWxkIGlzIGluIFNlY3Rpb24gNC4zLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRldGFpbGVkIHVzZSBvZiB0aGUgSE1BQyBm aWVsZCBpcyBpbiBTZWN0aW9uIDQuMy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxNyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj40LjMuICBJbnRlZ3JpdHkg PHNwYW4gY2xhc3M9ImRlbGV0ZSI+YW5kIENvbmZpZGVudGlhbGl0eSA8L3NwYW4+UHJvdGVjdGlv biBpbiBTVEFNUDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj40LjMuICBJbnRlZ3Jp dHkgUHJvdGVjdGlvbiBpbiBTVEFNUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBUbyBwcm92aWRlIGludGVncml0eSBwcm90ZWN0aW9uLCBlYWNoIFNUQU1QIG1lc3NhZ2UgaXMg YmVpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUbyBwcm92aWRlIGludGVn cml0eSBwcm90ZWN0aW9uLCBlYWNoIFNUQU1QIG1lc3NhZ2UgaXMgYmVpbmc8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIGF1dGhlbnRpY2F0ZWQgYnkgYWRkaW5nIEhhc2hlZCBNZXNzYWdl IEF1dGhlbnRpY2F0aW9uIENvZGUgKEhNQUMpLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGF1dGhlbnRpY2F0ZWQgYnkgYWRkaW5nIEhhc2hlZCBNZXNzYWdlIEF1dGhlbnRpY2F0 aW9uIENvZGUgKEhNQUMpLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU1RBTVAgdXNl cyBITUFDLVNIQS0yNTYgdHJ1bmNhdGVkIHRvIDEyOCBiaXRzIChzaW1pbGFybHkgdG8gdGhlIHVz ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNUQU1QIHVzZXMgSE1BQy1TSEEt MjU2IHRydW5jYXRlZCB0byAxMjggYml0cyAoc2ltaWxhcmx5IHRvIHRoZSB1c2U8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9mIGl0IGluIElQU2VjIGRlZmluZWQgaW4gW1JGQzQ4Njhd KTsgaGVuY2UgdGhlIGxlbmd0aCBvZiB0aGUgSE1BQzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIG9mIGl0IGluIElQU2VjIGRlZmluZWQgaW4gW1JGQzQ4NjhdKTsgaGVuY2UgdGhl IGxlbmd0aCBvZiB0aGUgSE1BQzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZmllbGQg aXMgMTYgb2N0ZXRzLiAgSE1BQyB1c2VzIGl0cyBvd24ga2V5LCBhbmQgdGhlIGRlZmluaXRpb24g b2YgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZmllbGQgaXMgMTYgb2N0 ZXRzLiAgSE1BQyB1c2VzIGl0cyBvd24ga2V5LCBhbmQgdGhlIGRlZmluaXRpb24gb2YgdGhlPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtZWNoYW5pc20gdG8gZGlzdHJpYnV0ZSB0aGUg SE1BQyBrZXkgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpczwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIG1lY2hhbmlzbSB0byBkaXN0cmlidXRlIHRoZSBITUFDIGtleSBpcyBv dXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBz cGVjaWZpY2F0aW9uLiAgT25lIGV4YW1wbGUgaXMgdG8gdXNlIGFuIG9yY2hlc3RyYXRvciB0byBj b25maWd1cmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzcGVjaWZpY2F0aW9u LiAgT25lIGV4YW1wbGUgaXMgdG8gdXNlIGFuIG9yY2hlc3RyYXRvciB0byBjb25maWd1cmU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEhNQUMga2V5IGJhc2VkIG9uIFNUQU1QIFlBTkcg ZGF0YSBtb2RlbCBbSS1ELmlldGYtaXBwbS1zdGFtcC15YW5nXS48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBITUFDIGtleSBiYXNlZCBvbiBTVEFNUCBZQU5HIGRhdGEgbW9kZWwg W0ktRC5pZXRmLWlwcG0tc3RhbXAteWFuZ10uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIEhNQUMgTVVTVCBiZSB2ZXJpZmllZCBhcyBlYXJseSBhcyBwb3NzaWJsZSB0byBhdm9p ZCB1c2luZyBvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEhNQUMgTVVTVCBi ZSB2ZXJpZmllZCBhcyBlYXJseSBhcyBwb3NzaWJsZSB0byBhdm9pZCB1c2luZyBvcjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHJvcGFnYXRpbmcgY29ycnVwdGVkIGRhdGEuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJvcGFnYXRpbmcgY29ycnVwdGVkIGRhdGEu PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlm ZjAwMTgiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+SWYgY29uZmlkZW50aWFs aXR5IHByb3RlY3Rpb24gZm9yIFNUQU1QIGlzIHJlcXVpcmVkLCBlbmNyeXB0aW9uIGF0PC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij40 LjQuICBDb25maWRlbnRpYWxpdHkgUHJvdGVjdGlvbjwvc3Bhbj4gaW4gPHNwYW4gY2xhc3M9Imlu c2VydCI+U1RBTVA8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNs YXNzPSJkZWxldGUiPiAgIHRoZSBoaWdoZXIgbGV2ZWwgTVVTVCBiZSB1c2VkLiAgRm9yIGV4YW1w bGUsIFNUQU1QIHBhY2tldHMgY291bGQgYmU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVs ZXRlIj4gICB0cmFuc21pdHRlZDwvc3Bhbj4gaW4gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+dGhlIGRl ZGljYXRlZCBJUHNlYyB0dW5uZWwgb3Igc2hhcmUgdGhlIElQc2VjIHR1bm5lbDwvc3Bhbj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIHdpdGggdGhlIG1vbml0b3JlZCBmbG93Ljwvc3Bh bj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTkiPjx0ZD48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNw YW4gY2xhc3M9ImRlbGV0ZSI+NC40Ljwvc3Bhbj4gIEludGVyb3BlcmFiaWxpdHkgd2l0aCBUV0FN UCBMaWdodDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5JZiBjb25maWRlbnRpYWxpdHkgcHJvdGVjdGlvbiBmb3IgU1RBTVAgaXMgcmVxdWly ZWQsIGEgU1RBTVAgdGVzdDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHNl c3Npb24gTVVTVCB1c2UgYSBzZWN1cmVkIHRyYW5zcG9ydC4gIEZvciBleGFtcGxlLCBTVEFNUCBw YWNrZXRzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgY291bGQgYmUgdHJh bnNtaXR0ZWQgaW4gdGhlIGRlZGljYXRlZCBJUHNlYyB0dW5uZWwgb3Igc2hhcmUgdGhlIElQc2Vj PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgdHVubmVsIHdpdGggdGhlIG1v bml0b3JlZCBmbG93LiAgQWxzbywgRGF0YWdyYW0gVHJhbnNwb3J0IExheWVyPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgU2VjdXJpdHkgcHJvdG9jb2wgd291bGQgcHJvdmlk ZSB0aGUgZGVzaXJlZCBjb25maWRlbnRpYWxpdHk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICBwcm90ZWN0aW9uLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi Pjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjQuNS48L3NwYW4+ICBJbnRlcm9w ZXJhYmlsaXR5IHdpdGggVFdBTVAgTGlnaHQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgT25lIG9mIHRoZSBlc3NlbnRpYWwgcmVxdWlyZW1lbnRzIHRvIFNUQU1QIGlzIHRoZSBh YmlsaXR5IHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgT25lIG9mIHRoZSBl c3NlbnRpYWwgcmVxdWlyZW1lbnRzIHRvIFNUQU1QIGlzIHRoZSBhYmlsaXR5IHRvPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbnRlcndvcmsgd2l0aCBhIFRXQU1QIExpZ2h0IGRldmlj ZS4gIFRoZXJlIGFyZSB0d28gcG9zc2libGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBpbnRlcndvcmsgd2l0aCBhIFRXQU1QIExpZ2h0IGRldmljZS4gIFRoZXJlIGFyZSB0d28g cG9zc2libGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNvbWJpbmF0aW9ucyBmb3Ig c3VjaCB1c2UgY2FzZTo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjb21iaW5h dGlvbnMgZm9yIHN1Y2ggdXNlIGNhc2U6PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIG8gIFNUQU1QIFNlc3Npb24tU2VuZGVyIHdpdGggVFdBTVAgTGlnaHQgU2Vzc2lvbi1SZWZs ZWN0b3I7PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgU1RBTVAgU2Vzc2lv bi1TZW5kZXIgd2l0aCBUV0FNUCBMaWdodCBTZXNzaW9uLVJlZmxlY3Rvcjs8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgVFdBTVAgTGlnaHQgU2Vzc2lvbi1TZW5kZXIgd2l0 aCBTVEFNUCBTZXNzaW9uLVJlZmxlY3Rvci48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBvICBUV0FNUCBMaWdodCBTZXNzaW9uLVNlbmRlciB3aXRoIFNUQU1QIFNlc3Npb24tUmVm bGVjdG9yLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbiB0aGUgZm9ybWVy IGNhc2UsIHRoZSBTZXNzaW9uLVNlbmRlciBNQVkgbm90IGJlIGF3YXJlIHRoYXQgaXRzPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW4gdGhlIGZvcm1lciBjYXNlLCB0aGUgU2Vz c2lvbi1TZW5kZXIgTUFZIG5vdCBiZSBhd2FyZSB0aGF0IGl0czwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KCiAgICAgPHRyPjx0ZD48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQ+PC90ZD48L3RyPgogICAgIDx0ciBp ZD0iZW5kIiBiZ2NvbG9yPSJncmF5Ij48dGggY29sc3Bhbj0iNSIgYWxpZ249ImNlbnRlciI+Jm5i c3A7RW5kIG9mIGNoYW5nZXMuIDE5IGNoYW5nZSBibG9ja3MuJm5ic3A7PC90aD48L3RyPgogICAg IDx0ciBjbGFzcz0ic3RhdHMiPjx0ZD48L3RkPjx0aD48aT40NyBsaW5lcyBjaGFuZ2VkIG9yIGRl bGV0ZWQ8L2k+PC90aD48dGg+PGk+IDwvaT48L3RoPjx0aD48aT40OCBsaW5lcyBjaGFuZ2VkIG9y IGFkZGVkPC9pPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICA8dHI+PHRkIGNvbHNwYW49IjUiIGFs aWduPSJjZW50ZXIiIGNsYXNzPSJzbWFsbCI+PGJyPlRoaXMgaHRtbCBkaWZmIHdhcyBwcm9kdWNl ZCBieSByZmNkaWZmIDEuNDcuIFRoZSBsYXRlc3QgdmVyc2lvbiBpcyBhdmFpbGFibGUgZnJvbSA8 YSBocmVmPSJodHRwOi8vd3d3LnRvb2xzLmlldGYub3JnL3Rvb2xzL3JmY2RpZmYvIj5odHRwOi8v dG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi88L2E+IDwvdGQ+PC90cj4KICAgPC90Ym9keT48 L3RhYmxlPgogICAKICAgCjwvYm9keT48L2h0bWw+ --000000000000681d2605910c6cc6-- From nobody Tue Aug 27 00:38:42 2019 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 BC295120018; Tue, 27 Aug 2019 00:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNwuh9w10iIU; Tue, 27 Aug 2019 00:38:17 -0700 (PDT) Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C74112004A; Tue, 27 Aug 2019 00:38:17 -0700 (PDT) Received: by mail-vk1-xa2e.google.com with SMTP id p5so2598219vkm.5; Tue, 27 Aug 2019 00:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hhhPnl+OpHv6OxRZVTbdQR8bDj5CNpx/X/FoABqSaqk=; b=gb4CgM9ReOAthj8NtGHFVtxnn1LC0YVF15XUsntyBb0OhdSd7dTSJkM1pmFF8KmnXg JKBoYSnABeIuafaTSFaC9GVCDUpZbZxBIXYfKrHPjoAVvwNsYuwq9ZR/ntiS3whU8LMP 6CdI/VBqktksgBm/9bGCMmxv8rGbbP+lYlMDlufOtfH97EnOLAcaTO5wIcsCDgXXzaXB ovYbxQLDIAhBu6Rj+AUjeL0Uo8nkj7IBAAMXFKtg1ytxNXjgRuCwYSuh21cXbWRBgxSt J2yZPXswoN8K6437oZOE2sph56xcRWIZrw9L8sKi9LSR9srIYPSdjU3IIUdLbGt8/9fY 4JFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hhhPnl+OpHv6OxRZVTbdQR8bDj5CNpx/X/FoABqSaqk=; b=hFVtQndzt4D067qrgdmeXBOA4yh+7jimAgZe6K73kY427iL8qGWito+RZjRCPGV3rF eupONf6l10fWzbDGQfHzF9waQSmoWpSe0+pFFKd8eK8X53QRiXMGHbGviAl+j9eR/C3j psHt0ZEgXR8lCROYSdXDEYcPaHQheY43sIwcdjeZ6wNzHpsDGZuGvifGV36/eSxChMhJ qKssiddDnrDHdWpJGv53ht+wN2g0eD/uYWxihPvBql4VtyBwMak4OcABO9tUkCdsnn68 yDWW/sJgxaW0zehWQWNuF9c/w/P19ClJQudYcWzzl3S0dYC3E+uiVnE4NeSXkFq1eRhh WG7Q== X-Gm-Message-State: APjAAAWJJFfjlCWho2Lcgaegysfi4Ix5Dar1JI2y5bBlH71ijpIeMRld ye7p9hKl4akETqoFVf8a3uCcVeV7iNw/qtBVFck= X-Google-Smtp-Source: APXvYqywH4jiL5Rsob6GP0NhyZvvxhaLXMeEDGV3pldQwEbvXLSeXqOjS/6XfALTCt+0V690m5oxxw0+goC29yd+h9A= X-Received: by 2002:a1f:1c0c:: with SMTP id c12mr10383664vkc.44.1566891495572; Tue, 27 Aug 2019 00:38:15 -0700 (PDT) MIME-Version: 1.0 References: <156683976148.30653.13816124126977906406@ietfa.amsl.com> In-Reply-To: <156683976148.30653.13816124126977906406@ietfa.amsl.com> From: "Ori Finkelman (IETF)" Date: Tue, 27 Aug 2019 10:37:58 +0300 Message-ID: To: Linda Dunbar Cc: secdir@ietf.org, draft-ietf-cdni-request-routing-extensions.all@ietf.org, ietf@ietf.org, "" Content-Type: multipart/alternative; boundary="000000000000feca020591145af1" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-cdni-request-routing-extensions-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 07:38:29 -0000 --000000000000feca020591145af1 Content-Type: text/plain; charset="UTF-8" Hi Linda, Thank you for your time and comments. I will address them in the next revision. Best regards, Ori On Mon, Aug 26, 2019 at 8:16 PM Linda Dunbar via Datatracker < noreply@ietf.org> wrote: > Reviewer: Linda Dunbar > Review result: Has Nits > > 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 terminology RR (Request Router) and CP (Content Provider) specified by > the > Terminology are not used for the entire document. I assume that RR would > be the > one request content, isn't? is RR same as Client? Is RR part of > Downstream CDN > Provider? is the CP same as Downstream CDN provider or Upstream CDN > Provider? > > who issued the Redirect Target? > > It would be good for the document to clearly specify the relationship of > all > the entities, such as who makes request and who respond, and who use the > Redirect Target capability, etc. > > Thank you very much. > Linda Dunbar > > > --000000000000feca020591145af1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Linda,
Thank you for your time and comments.
<= div>I will address them in the next revision.

Best= regards,
Ori

On Mon, Aug 26, 2019 at 8:16 PM Linda Dunbar = via Datatracker <noreply@ietf.org> wrote:
Rev= iewer: Linda Dunbar
Review result: Has Nits

I have reviewed this document as part of the security directorate's ong= oing
effort to review all IETF documents being processed by the IESG.=C2=A0 Thes= e
comments were written primarily for the benefit of the security area direct= ors.
=C2=A0Document editors and WG chairs should treat these comments just like = any other
last call comments.

The terminology RR (Request Router) and CP (Content Provider) specified by = the
Terminology are not used for the entire document. I assume that RR would be= the
one request content, isn't? is RR same as Client?=C2=A0 Is RR part of D= ownstream CDN
Provider? is the CP same as Downstream CDN provider or Upstream CDN Provide= r?

who issued the Redirect Target?

It would be good for the document to clearly specify the relationship of al= l
the entities, such as who makes request and who respond, and who use the Redirect Target capability, etc.

Thank you very much.
Linda Dunbar


--000000000000feca020591145af1-- From nobody Tue Aug 27 09:31:19 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EB11200D7; Sun, 25 Aug 2019 17:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1566779143; bh=/NtqLqS8eMoAzwNhGpSvfR5VWL7DsNnSPO68RLwfZ2I=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=JG6pdTCuw3DjbNCzRiv2FDoujOtseEWEvJc0Gq1PGFN0IZoQvCUoevOQZrvKfFWmi iQB8Hh1Q4tedkDAXY7PdZL49EhuqSk1vfHZgWUZoHqTW8uKtMhExi5/KucC5urSN2D SIde0gOV3f+B4KZqwB4CRseUT0+2Ncz3MlhAkp4k= X-Mailbox-Line: From new-work-bounces@ietf.org Sun Aug 25 17:25:42 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6D8120052; Sun, 25 Aug 2019 17:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1566779142; bh=/NtqLqS8eMoAzwNhGpSvfR5VWL7DsNnSPO68RLwfZ2I=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=Wf66t0cRnN/PZagE7JUwKJar4nNBzKdjt95cSxxCSyEqL9XfWXit7m3Xnp+V15uLo TFfWk24Wwtz9zHqTw6a0ynBcbjsUUVQVAxUwzmRhXmbrWWd1e+UwwPbTgZnH6S6fbP Y89M+ishk2QNw7OEKul2xQWM8xZQatQADfX6NyvU= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81FB120052 for ; Sun, 25 Aug 2019 17:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKbpGPBziCKR for ; Sun, 25 Aug 2019 17:25:39 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8BE5120020 for ; Sun, 25 Aug 2019 17:25:38 -0700 (PDT) Received: from [42.100.7.85] (helo=[192.168.1.4]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1i22pE-0006oO-QI for new-work@ietf.org; Mon, 26 Aug 2019 00:25:37 +0000 To: new-work@ietf.org From: xueyuan Message-ID: Date: Mon, 26 Aug 2019 08:25:33 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 27 Aug 2019 09:31:18 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Cascading Style Sheets (CSS) Working Group (until 2019-09-22) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 00:25:46 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgQ2FzY2Fk aW5nIFN0eWxlIFNoZWV0cyAoQ1NTKSBXb3JraW5nIApHcm91cDoKIMKgIGh0dHBzOi8vd3d3Lncz Lm9yZy8yMDE5LzA4L3Byb3Bvc2VkLWNzcy0yMDE5Lmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJpbmcg dGhhdCB0aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0aGlz IGRyYWZ0IGNoYXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVlIHJl dmlldyBwZXJpb2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAyMDE5LTA5 LTIyIG9uIHRoZQpwcm9wb3NlZCBjaGFydGVyLiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0bwpwdWJs aWMtbmV3LXdvcmtAdzMub3JnLCB3aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToKIMKgIGh0dHA6 Ly9saXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90aGVyIHRo YW4gY29tbWVudHMgc2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeQpDb21t aXR0ZWUgUmVwcmVzZW50YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRv CmNvbW1lbnRzLiBJZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3Jk aW5hdGUKeW91ciBjb21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2Vu dGF0aXZlLiBGb3IKZXhhbXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1lbnRz IHZpYSB0aGlzIGxpc3QgYW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50 YXRpdmUgcmVmZXIgdG8gaXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMu CgpUaGUgV29ya2luZyBHcm91cCBpcyBhbHNvIGV4dGVuZGVkIHVudGlsIDMwIFNlcHRlbWJlciAy MDE5CnRvIGFjY29tbW9kYXRlIGZvciB0aGUgY2hhcnRlciByZXZpZXcgcGVyaW9kLgoKSWYgeW91 IHNob3VsZCBoYXZlIGFueSBxdWVzdGlvbnMgb3IgbmVlZCBmdXJ0aGVyIGluZm9ybWF0aW9uLCBw bGVhc2UKY29udGFjdCBGdXFpYW8gWHVlIDx4ZnFAdzMub3JnPiBvciBDaHJpcyBMaWxsZXkgPGNo cmlzQHczLm9yZz4sClczQyBUZWFtIENvbnRhY3RzLgoKVGhhbmsgeW91LAoKWHVleXVhbiBKaWEs IFczQyBNYXJrZXRpbmcgJiBDb21tdW5pY2F0aW9ucwoKWzFdIGh0dHA6Ly93d3cudzMub3JnL0Nv bnNvcnRpdW0vTWVtYmVyL0xpc3QKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Tue Aug 27 15:32:38 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AE91207FE; Tue, 27 Aug 2019 15:32:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell via Datatracker To: Cc: pce@ietf.org, ietf@ietf.org, draft-ietf-pce-stateful-hpce.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stephen Farrell Message-ID: <156694513536.5875.13874927498225306603@ietfa.amsl.com> Date: Tue, 27 Aug 2019 15:32:15 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-pce-stateful-hpce-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 22:32:16 -0000 Reviewer: Stephen Farrell Review result: Has Nits Hiya, This draft doesn't define new protocol but rather describes a way to use existing PCE stuff in what I guess is a new way. The nit I see is the usual, presumably fictional, reference to TCP-AO. I mean, if nobody actually does that, why bother? Esp. if you have a TLS option that's (I hope) less fictional. (Is TLS less fictional for PCEP btw?) OTOH, I guess that nearly everyone now knows that referring to TCP-AO is just a figleaf to try keep security nerds happy, so maybe it's ok that we all suspend disbelief;-( Other than that, I did have two questions that occurred to me, but that are by no means a reason to hold up this draft - if answers required some action, it'd almost certainly not be something that'd be fixed here. But I'm still curious:-) 1. Has anyone spent any significant amount of time/effort attempting to attack an H-PCE network as a PCEP speaker? (And written that up:-) It looks to me like there're enough moving parts here that any real stateful hierarchical PCE network could be fairly likely to have interestingly exploitable problems in the face of such an attacker. 2. I see a reference to SPEAKER-IDENTITY-TLV. I wondered if the ability to e.g. use different SubjectAltNames in x.509 certificates might create the potential for some kind of deliberate or accidental loops to be created somewhere. Again, there's no reason to hold this up to try answer (or even to understand) those questions. I'd be happy to chat over a beer with someone at IETF106 about 'em as that might be easier than a bunch of mail. Cheers, S. From nobody Tue Aug 27 15:42:19 2019 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 742C512011F; Tue, 27 Aug 2019 15:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BNIO2DwcaWy; Tue, 27 Aug 2019 15:42:03 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33CE12004D; Tue, 27 Aug 2019 15:42:02 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id x7RMfxB6032602; Tue, 27 Aug 2019 23:41:59 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BD0EA22044; Tue, 27 Aug 2019 23:41:59 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id A7B2122042; Tue, 27 Aug 2019 23:41:59 +0100 (BST) Received: from LAPTOPK7AS653V ([87.112.232.99]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x7RMfwEQ002710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 27 Aug 2019 23:41:58 +0100 Reply-To: From: "Adrian Farrel" To: "'Stephen Farrell'" , Cc: , , References: <156694513536.5875.13874927498225306603@ietfa.amsl.com> In-Reply-To: <156694513536.5875.13874927498225306603@ietfa.amsl.com> Date: Tue, 27 Aug 2019 23:41:56 +0100 Organization: Old Dog Consulting Message-ID: <009d01d55d28$a1e40d10$e5ac2730$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJA/rGZjHAHMn7bUKOY+SCX9DHKzKY4UmcQ Content-Language: en-gb X-Originating-IP: 87.112.232.99 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24874.003 X-TM-AS-Result: No--17.709-10.0-31-10 X-imss-scan-details: No--17.709-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24874.003 X-TMASE-Result: 10--17.708700-10.000000 X-TMASE-MatchedRID: x2HXvaraFomWfDtBOz4q23FPUrVDm6jtK2Xp5E/r/sDDOS0FhcAXSiVd 0zWceCJ5eEMcfhapRN8CqkfgFNTEWeCpYE4Zw1NnUPktDdOX0fseRZr2cxRELsuSXx71bvSL5xK d2UyY/9aXhTtgl0lKrQ7mOhsG9JpUG6D1Oij+NwkHRzaQbsazqLJEo6RFXaMBa73+XlYDLuxGYv UFUejPpwFjHc0ldSMGX7VX/Yyk1YPsrfmvTLX/noS/TV9k6ppAPXu1L28jSnFEvDDW7fraa6DSF bNSvOcnUlYzUd2VQCjdjgC/mVZqxbgDo+qmynoTN19PjPJahlI+2wh5SKLNTr59Yrw3aQCHqzsf 3Jwr9ugvL6wN3NwNB4dhR5KNGoGn281ysgK8tlPY89Y3rjOSOjmKihe1K2IeuHvAyOPMssxKOLA aWF/XN5c0cjL5IGjpS5wwTxCFN2yvMyWwzFWyi0XDLbZtboYDChdI4sLlrjiZj6vI4Rf7hGlys1 PDhWLoCIUHXTihi6sW0Cobj/6ySGthr6NhZ4UuCuDAUX+yO6Y+4xdAglpjoNC+brZibJmzU1LXq VLalgNPbhexfXCKb/7ewXL4WrSICqKeazYPYcKeAiCmPx4NwFkMvWAuahr8i2QFaYS1v20qtq5d 3cxkNQP90fJP9eHt X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-pce-stateful-hpce-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 22:42:06 -0000 You had me at the mention of beer. Actually, that would be a useful conversation both in a PCE context and = in a wider SDN context. (Always said that the SDN architecture was = missing a bit of security work). I'd also love us to have some clarity about TCP-AO. It's like we were = all told we must use TCP-AO in our protocol specifications as the silver = bullet, and now the shiny outer layer has tarnished a bit. But that is = worthy of a separate thread. Best, Adrian -----Original Message----- From: Stephen Farrell via Datatracker =20 Sent: 27 August 2019 23:32 To: secdir@ietf.org Cc: pce@ietf.org; ietf@ietf.org; = draft-ietf-pce-stateful-hpce.all@ietf.org Subject: Secdir last call review of draft-ietf-pce-stateful-hpce-11 Reviewer: Stephen Farrell Review result: Has Nits Hiya, This draft doesn't define new protocol but rather describes a way to use = existing=20 PCE stuff in what I guess is a new way.=20 The nit I see is the usual, presumably fictional, reference to TCP-AO. = I mean, if nobody actually does that, why bother? Esp. if you have a TLS option = that's (I hope) less fictional. (Is TLS less fictional for PCEP btw?) OTOH, I = guess that nearly everyone now knows that referring to TCP-AO is just a figleaf to = try keep security nerds happy, so maybe it's ok that we all suspend disbelief;-(=20 Other than that, I did have two questions that occurred to me, but that = are by=20 no means a reason to hold up this draft - if answers required some = action, it'd almost certainly not be something that'd be fixed here. But I'm still = curious:-) 1. Has anyone spent any significant amount of time/effort attempting to=20 attack an H-PCE network as a PCEP speaker? (And written that up:-) It=20 looks to me like there're enough moving parts here that any real = stateful=20 hierarchical PCE network could be fairly likely to have interestingly exploitable problems in the face of such an attacker. 2. I see a reference to SPEAKER-IDENTITY-TLV. I wondered if the=20 ability to e.g. use different SubjectAltNames in x.509 certificates might create the potential for some kind of deliberate or accidental loops to be created somewhere.=20 Again, there's no reason to hold this up to try answer (or even to understand) those questions. I'd be happy to chat over a beer with=20 someone at IETF106 about 'em as that might be easier than a bunch=20 of mail.=20 Cheers, S. From nobody Tue Aug 27 15:53:57 2019 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 CEA7812012E; Tue, 27 Aug 2019 15:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.964 X-Spam-Level: X-Spam-Status: No, score=-0.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjkIS-uNv0s5; Tue, 27 Aug 2019 15:53:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BB9B12001A; Tue, 27 Aug 2019 15:53:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0F0CABE53; Tue, 27 Aug 2019 23:53:50 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlcXLxzNrTEn; Tue, 27 Aug 2019 23:53:48 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3173EBE2E; Tue, 27 Aug 2019 23:53:48 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1566946428; bh=tvL5r7BOvtnYVPxftcpm12wtdZAjkQLfe+agPwb0eCk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=v3DendElxAN04OMNz8gPOceXizy9I/DAMfHgiNB6vkz7tNjXFifWchm+lOrRpnwmb y9msVl7fV9ujuZijrgnGEx52xlTHYJ6chLDjt/R8z7VuLynKQrRVl3DTdgLf94ixjx RERG7+8+xBxMioadMgtKELidbz3Vrnl5Bfea3jYk= To: adrian@olddog.co.uk, secdir@ietf.org Cc: pce@ietf.org, ietf@ietf.org, draft-ietf-pce-stateful-hpce.all@ietf.org References: <156694513536.5875.13874927498225306603@ietfa.amsl.com> <009d01d55d28$a1e40d10$e5ac2730$@olddog.co.uk> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Tue, 27 Aug 2019 23:53:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <009d01d55d28$a1e40d10$e5ac2730$@olddog.co.uk> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oUFTTkidFpRTEkXzGRQOwtWSECAiLt3zG" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-pce-stateful-hpce-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 22:53:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oUFTTkidFpRTEkXzGRQOwtWSECAiLt3zG Content-Type: multipart/mixed; boundary="NpRFYk06M3WTnCduIYOq7GFA7xKKlmQgh"; protected-headers="v1" From: Stephen Farrell To: adrian@olddog.co.uk, secdir@ietf.org Cc: pce@ietf.org, ietf@ietf.org, draft-ietf-pce-stateful-hpce.all@ietf.org Message-ID: Subject: Re: Secdir last call review of draft-ietf-pce-stateful-hpce-11 References: <156694513536.5875.13874927498225306603@ietfa.amsl.com> <009d01d55d28$a1e40d10$e5ac2730$@olddog.co.uk> In-Reply-To: <009d01d55d28$a1e40d10$e5ac2730$@olddog.co.uk> --NpRFYk06M3WTnCduIYOq7GFA7xKKlmQgh Content-Type: multipart/mixed; boundary="------------3724F9CDC400A19CA5487336" Content-Language: en-GB This is a multi-part message in MIME format. --------------3724F9CDC400A19CA5487336 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 27/08/2019 23:41, Adrian Farrel wrote: > You had me at the mention of beer. That's a deal then:-) > Actually, that would be a useful conversation both in a PCE context > and in a wider SDN context. (Always said that the SDN architecture > was missing a bit of security work). > > I'd also love us to have some clarity about TCP-AO. It's like we were > all told we must use TCP-AO in our protocol specifications as the > silver bullet, and now the shiny outer layer has tarnished a bit. But > that is worthy of a separate thread. Yeah. TCP-AO is a fine thing and would've solved some problems had it been deployed but I guess reality chose otherwise and it has now been 9 years so maybe it's time to call that one. But I guess that's a question that the esteemed routing and sec ADs can figure out. I think the main downside of text such as is in this draft is that some RFC readers may waste effort on it for no benefit so it seems a bit of a disservice for us to keep on pretending. OTOH, maybe all the relevant implementers already know to ignore it already. (Or ignore all crypto stuff all the time;-) BTW - I'd still love to know if TLS is as fictional as TCP-AO for PCEP:-) Cheers, S. >=20 > Best, Adrian >=20 > -----Original Message----- From: Stephen Farrell via Datatracker > Sent: 27 August 2019 23:32 To: secdir@ietf.org Cc: > pce@ietf.org; ietf@ietf.org; > draft-ietf-pce-stateful-hpce.all@ietf.org Subject: Secdir last call > review of draft-ietf-pce-stateful-hpce-11 >=20 > Reviewer: Stephen Farrell Review result: Has Nits >=20 >=20 > Hiya, >=20 > This draft doesn't define new protocol but rather describes a way to > use existing PCE stuff in what I guess is a new way. >=20 > The nit I see is the usual, presumably fictional, reference to > TCP-AO. I mean, if nobody actually does that, why bother? Esp. if > you have a TLS option that's (I hope) less fictional. (Is TLS less > fictional for PCEP btw?) OTOH, I guess that nearly everyone now knows > that referring to TCP-AO is just a figleaf to try keep security nerds > happy, so maybe it's ok that we all suspend disbelief;-( >=20 > Other than that, I did have two questions that occurred to me, but > that are by no means a reason to hold up this draft - if answers > required some action, it'd almost certainly not be something that'd > be fixed here. But I'm still curious:-) >=20 > 1. Has anyone spent any significant amount of time/effort attempting > to attack an H-PCE network as a PCEP speaker? (And written that > up:-) It looks to me like there're enough moving parts here that any > real stateful hierarchical PCE network could be fairly likely to > have interestingly exploitable problems in the face of such an > attacker. >=20 > 2. I see a reference to SPEAKER-IDENTITY-TLV. I wondered if the=20 > ability to e.g. use different SubjectAltNames in x.509 certificates=20 > might create the potential for some kind of deliberate or accidental=20 > loops to be created somewhere. >=20 > Again, there's no reason to hold this up to try answer (or even to=20 > understand) those questions. I'd be happy to chat over a beer with=20 > someone at IETF106 about 'em as that might be easier than a bunch of > mail. >=20 > Cheers, S. >=20 >=20 >=20 --------------3724F9CDC400A19CA5487336 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------3724F9CDC400A19CA5487336-- --NpRFYk06M3WTnCduIYOq7GFA7xKKlmQgh-- --oUFTTkidFpRTEkXzGRQOwtWSECAiLt3zG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl1ltHsACgkQWrL68XsX K+oo5BAAj0t3bIOrdTAzu9llxf+/J3SlVkTYAA1BMc5lC5TWLF6gEI3LlWdy8i0Q DIA3ZCSdr9Xqih4kDB+viockO7k2pUxlHl93QwmV/xUP49ticiLsw1lCjZT4+81p /v67FNjFf2NkS3Ec2OcOFkQWShKPrvJyU3xbGRz3roFeQHytYwbZxNGZmzN+OEYd GCJteQkV4iXQywJc1gW3KN+HYYGV88V/pSiOWP7OeIc26ki22QKZG41jWbciyxmK pLx75irvRVI77//vlyfbdLLQ6UYVv9Ay1xuHpP5WqNlawqfhwvSa7xE5+HH2olG8 2yUux3RzPuZSkGs+0AGYwa1BT0Gztmc3v8DI97M+3YdYJV6PHEhok9uUvOt4cgFg x8lPveMBTDMvAlsaIuO4jrc6po6UpIL+zuIQ4vIQDgV6uSuNPGDpJmt+GVnLz2us U2nL8uOcYEB4eCbAtDCGq/HTA0qj28r0TvuPf4GD6z6G++67YR2kN3JZSyIyencZ 86WTVxXecCFKdJz1Br80siuBpKlAhx6XEFtp1a4YM7ANdFkHU2ua4lx1ZoIg+hrJ IBUDa2Ci/YknInV4mPpgVB70EaGphpWpVWKJofOM0D90FkvhzjzKAKIyZhpoGRqW cR2MFMwOCb3wcLomU+8s+1QxZY3J4yrAcqIjrE9mRAsNzMZsf7M= =19bx -----END PGP SIGNATURE----- --oUFTTkidFpRTEkXzGRQOwtWSECAiLt3zG-- From nobody Wed Aug 28 12:43:08 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 418711200E3; Wed, 28 Aug 2019 12:43:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Franke via Datatracker To: Cc: pce@ietf.org, ietf@ietf.org, draft-ietf-pce-stateful-pce-auto-bandwidth.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Daniel Franke Message-ID: <156702138622.1106.12957431760424204090@ietfa.amsl.com> Date: Wed, 28 Aug 2019 12:43:06 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-pce-stateful-pce-auto-bandwidth-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 19:43:06 -0000 Reviewer: Daniel Franke Review result: Ready 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 protocol that this draft extends is one intended to be run over TLS and conducted between two endpoints controlled by the same administrative authority. The Security Considerations section duly makes this explicit and references another RFC which thoroughly discusses what can occur when these assumptions are violated. When the protocol is run as intended, there is no communication across trust boundaries and therefore the potential security concerns are minimal. From nobody Thu Aug 29 04:46:47 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD573120025 for ; Thu, 29 Aug 2019 04:46:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <156707920570.21016.5184748711560095975.idtracker@ietfa.amsl.com> Date: Thu, 29 Aug 2019 04:46:45 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 11:46:46 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-09-05 Reviewer LC end Draft Christian Huitema 2019-09-02 draft-ietf-core-senml-etch-05 David Waltermire 2019-08-07 draft-ietf-oauth-jwt-introspection-response-06 Brian Weis 2019-08-05 draft-ietf-oauth-resource-indicators-05 Last calls: Reviewer LC end Draft Derek Atkins 2019-08-15 draft-ietf-opsec-urpf-improvements-03 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Donald Eastlake 2019-08-28 draft-ietf-pce-stateful-path-protection-08 Daniel Gillmor 2019-08-27 draft-ietf-lsr-isis-rfc5306bis-05 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Steve Hanna 2019-09-05 draft-ietf-cbor-array-tags-07 Dan Harkins 2019-09-03 draft-ietf-pim-reserved-bits-03 Leif Johansson 2019-09-02 draft-ietf-tls-sni-encryption-05 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-17 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Tim Polk 2019-08-01 draft-ietf-acme-star-08 Christopher Wood 2019-08-30 draft-klensin-idna-unicode-review-02 Paul Wouters 2019-08-30 draft-klensin-idna-rfc5891bis-04 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-12 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Next in the reviewer rotation: Scott Kelly Stephen Kent Tero Kivinen Watson Ladd Ben Laurie Barry Leiba Chris Lonvick Aanchal Malhotra David Mandelberg Catherine Meadows From nobody Thu Aug 29 07:51:08 2019 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 5AAD812085C; Thu, 29 Aug 2019 07:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aydrC6xs4-B2; Thu, 29 Aug 2019 07:50:57 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6754120127; Thu, 29 Aug 2019 07:50:56 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id u185so3638546iod.10; Thu, 29 Aug 2019 07:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=72jdzGhiMlSJ6+tGzbPiBBaMaJD8zlgQjNASUR056Ec=; b=D5F2XDaSxR6TdYHCvy+o2F/EzbMtJ9OFI8D5yKmpVqHTdC8WLsVZD0V9ZfKoXv9Ehi 5qMh7HzYL+KcfKh/yjL8009ty+/YScHIkdkHzQPPDihN+XknseIsaIvcnpnIURCZhxWP FvuN5mmivGVeQEC8dr/Rk/Ac5hS2Z4Jf/+aX/PrvXsETYCFfH05EFqQO8iCfRKBQgO0p N6XR1hxpkdDSDHuak24jiCNtUJkDTL6sd8U8GocmoH+kKf3tOGT2fm015raL7SSpTnQU dhp7mc2ynUAhAbWF3YFNWUhJxgDQE1onrx151J6GalpcX0EKuQbrxwUT6A9HuaKeAo8s kwDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=72jdzGhiMlSJ6+tGzbPiBBaMaJD8zlgQjNASUR056Ec=; b=EE8BwNrRvQGb6D5d+HneQOAgzYSyIBqQXQPd9m/+kgBaRzPl3vZBYwrWFOuIZaqe22 xx23JnyMx1esA4+C6+JHYBq8xXmKhOrOm07z9FDyfx8/t7q0jAbzDrx2KUUC4BvVrX28 u6zvtrnkQ2IWmJNKVy3a/Ek+i3drAvAxkOHMC9v5xPErat5JDJAOyOuPGRpWEOSCgksQ Mf7dVOoE40NiacILDmt6vTbt7fSEfBkbNCiwgETgzQc5S6KJiLMBD0hrobxCmCmAmWD4 iakZbcgG1OddmVPzgEi2NhoppgjQCRmImkuvBse0l+I5WB+GUB6Lhg+/1FOTLbBwvYSu iyeg== X-Gm-Message-State: APjAAAUuXbzU0Yi1Sc9lkg88RsybTzzen6WZXLJ8kd5oajqDU4HtEkm2 GkNIhIjDhnM1VDwSvk0DCyydqGn8LWpGtDK1Jbszcw== X-Google-Smtp-Source: APXvYqz2N8jNmFUmkouIhts3/mO8kR/09mB7IyZoPw6575aK8a529ogEChwlP9IvV4eOmu4rKcygH8iQ+gbLWSuRZNw= X-Received: by 2002:a5e:9741:: with SMTP id h1mr406585ioq.24.1567090255706; Thu, 29 Aug 2019 07:50:55 -0700 (PDT) MIME-Version: 1.0 From: Donald Eastlake Date: Thu, 29 Aug 2019 10:50:44 -0400 Message-ID: To: "iesg@ietf.org" , draft-ietf-pce-stateful-path-protection.all@ietf.org Cc: secdir , pce@ietf.org Content-Type: multipart/alternative; boundary="00000000000005bd58059142a2ff" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-pce-stateful-path-protection X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 14:51:01 -0000 --00000000000005bd58059142a2ff Content-Type: text/plain; charset="UTF-8" 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. The summary of the review is Almost Ready. This document specifies an extension to the stateful Path Computation Element Communication Protocol to associate two or more Label Switched Paths for the purpose of setting up path protection. This is not at all my area of expertise. The Security Considerations section primarily refers to the Security Considerations in existing RFCs and one draft, draft-ietf-pce-association-group (which is already in the RFC Editor queue). I think these references are pretty thorough and provide good security coverage and advice with one possible exception. Given that this document specifies a new facility, it seems likely that a few narrow sentences would be in order about the damage an adversary could cause by specifically monkeying with that new facility. Tiny nits: In abstract and other places when referring to what this standards track draft does: "describes" -> "specifies" or "defines" Draft references draft-ietf-pce-association-diversity-08 when latest version is -09 Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com --00000000000005bd58059142a2ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the Security Dire= ctorate's=C2=A0ongoing effort to review all IETF documents being proces= sed by the IESG.=C2=A0 Document editors and WG chairs should treat these co= mments just like any other last call comments.

The summary of the re= view is Almost Ready.

This document specifies an extensi= on to the stateful Path Computation Element Communication Protocol to assoc= iate two or more Label Switched Paths for the purpose of setting up path pr= otection.

This is not at all my area of expertise. T= he Security Considerations section primarily refers to the Security Conside= rations in existing RFCs and one draft, draft-ietf-pce-association-group (w= hich is already in the RFC Editor queue). I think these references are pret= ty thorough and provide good security coverage and advice with one possible= exception. Given that this document specifies a new facility, it seems lik= ely that a few narrow sentences would be in order about the damage an adver= sary could cause by specifically monkeying with that new facility.

Tiny nits:=C2=A0
In abstract and other places wh= en referring to what this standards track draft does: "describes"= -> "specifies" or "defines"
 --00000000000005bd58059142a2ff-- From nobody Thu Aug 29 14:17:26 2019 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 80804120803; Thu, 29 Aug 2019 14:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58fyMN-Z77dV; Thu, 29 Aug 2019 14:17:11 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-oln040092004094.outbound.protection.outlook.com [40.92.4.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93DC2120073; Thu, 29 Aug 2019 14:17:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZTVKlgfLLMd1pju6PE1zK/o2V3N2DuWpJOKzkCIbWtl+9rXJ0ft/hAHo2Xvg02gWH6zP15p7Ngje8xAaIV+N9c4Wh5ci8Wm/cbV/LaLxTKadP+3nAMdQ26TxTRIsPcy6xLgUWqxNe9AYkKtbzuwT5PQA4Ta7cA/dFm1z+1Wb4I2n7zte0iFtuUC+Zy2UsxwCeLO/WAuBwClM9kgo83Pkhcro3hu1pzDyKUxCH+F7X3BavpZCOKD4kwfVlG+JKaBVI5JBZ24o3RgccrIgod+9UM0hCVzDRdrv0FF78YKHWBN4WtgRl6ziFFrGGZQCOgCdbGWWS5mOO4FpWiOYbSfMpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lqfDJjp/vIqiqtyt0HNB2QzCQufw2GtJMEgA2UZU3x0=; b=oVTDz+qwOrFfE/GhY+JKOh4kOHq3jUhy9uxlBuF7YwtZPuJHEovIkcJQ1DtDhy+0VC623Uny7O0OZbE0ufwaTU0r1gBhq293kJNqzy1U3iC1ZqtUQ+K5nWxlacdz6SQJReE5mQh0s+Zt5bWFP5rl0LQq+czBnfwTluTwV/kGa3SFFxafwAEbSoHLhcp7b8zjC8Uz4kZkJLy+RbNBlELsjVREocQ/V9UYE69zxHy53PosAX7tqqlzaD9k9pz2WTebuof1WPYvvsG+Ya6KohBMg4ZDOYtiZEkrDFiOupQE24/EYKM4L/Hqr+MQ53XLHiaMr+pib4h1GJCCCza7D/AL2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lqfDJjp/vIqiqtyt0HNB2QzCQufw2GtJMEgA2UZU3x0=; b=B1O4YrvbfZnGPCaeIwo+xIxpQnSKQ3GmFu2eyIOSGecaJuqV12+wteVZb221nrY45gKNxgb/YAAlx+K1EPNQ2LiAx2IteSuJGpLTiZNJnMUTvke05tYCeURnZrE1dlKLEkaqT3qeNb386v5As0ZpaGbyPHwkwEP/mUBNF+m/evG1PArS2kzGsMxlGVF/eG7gHfBJDEpgMloh5LBDFCNC/KL9zmjQYQXX3pMg0BqNvd5gqrbBVrElAZGqgHL+Y+CMCY5D2qbphDue16eZu97ErKHHmyw2WinMfM1rSys23wSKx2HsGYQuJye7xgTyqCFOR+9payYQSwyhlkAYkkFmJw== Received: from SN1NAM02FT051.eop-nam02.prod.protection.outlook.com (10.152.72.59) by SN1NAM02HT189.eop-nam02.prod.protection.outlook.com (10.152.72.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2220.16; Thu, 29 Aug 2019 21:17:10 +0000 Received: from MWHPR04MB0367.namprd04.prod.outlook.com (10.152.72.60) by SN1NAM02FT051.mail.protection.outlook.com (10.152.73.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.16 via Frontend Transport; Thu, 29 Aug 2019 21:17:10 +0000 Received: from MWHPR04MB0367.namprd04.prod.outlook.com ([fe80::f019:9a3e:4580:6163]) by MWHPR04MB0367.namprd04.prod.outlook.com ([fe80::f019:9a3e:4580:6163%10]) with mapi id 15.20.2220.013; Thu, 29 Aug 2019 21:17:10 +0000 From: Charlie Kaufman To: Brian Rosen CC: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ecrit-data-only-ea.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-ecrit-data-only-ea-18 Thread-Index: AQHVWrVSYrXYcnS0SkGl7pu26H6ueacN5f6AgAS+JZ0= Date: Thu, 29 Aug 2019 21:17:10 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:F2FA7D359EE27EFE341DD520161893FE06996FCEE4A317B3F061863488171CCE; UpperCasedChecksum:0202776B1821EAB52B0D2199FCC5B7E0FC945C68FC68949B1C2294346C3388E4; SizeAsReceived:7115; Count:44 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [ttr/i2OKYgvpzRkgCuIhjDqiaobV+vhzD8DHqdrDpT/RC3XSq23f0CmFmuOHljIL] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031323274)(2017031324274)(1601125500)(1603101475)(1701031045); SRVR:SN1NAM02HT189; x-ms-traffictypediagnostic: SN1NAM02HT189: x-ms-exchange-purlcount: 3 x-microsoft-antispam-message-info: tHIdR4VdajhiPffjA5y8Tb+yiKdzqJ2mhe9J6vFrETqY6wWk+EAUkANTDkhZLxcsBNfydGUl2vBlUDGeMHN+UT93d9m6Ok+RZnWwgJma8Nyg1u5t89eIciEkXLac85ULuX0eSNIp8kbJL3/pq+AqNcmrUy+Lgwtxg+SvfM3TgxpuZ+Gjkxri6jdqR/85DNZ3 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR04MB036724650A0D208BE4D22D58DFA20MWHPR04MB0367namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 39064291-ff9a-447d-ed82-08d72cc640fd X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 21:17:10.0984 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT189 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 21:17:16 -0000 --_000_MWHPR04MB036724650A0D208BE4D22D58DFA20MWHPR04MB0367namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable My confusion had to do with whether this is adding new functionality or whe= ther this is a profiling of existing functionality to enable a lightweight = interaction. For example, is it possible to send a CAP message within a SIP= transaction when there is going to follow interactive two way media in the= existing protocol? If so, this could have been done with the previous prot= ocol just by ending after the first exchange. If not, this is something tha= t couldn't have been done before and this is new functionality (and I would= wonder why the old protocol did not allow this). My confusion might be based on my lack of understanding of the layering of = CAP, SIP, and MIME, and it could be that anyone with a legitimate reason to= read this document would not be confused. --Charlie p.s. Apologies for the formatting. I'm using Outlook's web interface, which= tends to be overly clever and mess things up. Sent from Outlook ________________________________ From: Brian Rosen Sent: Monday, August 26, 2019 1:34 PM To: Charlie Kaufman Cc: secdir@ietf.org ; iesg@ietf.org ; draft= -ietf-ecrit-data-only-ea.all@ietf.org Subject: Re: Secdir review of draft-ietf-ecrit-data-only-ea-18 Hi Charlie Thanks for the review, I appreciate it. The introduction section has this text Data-only emergency calls are similar to regular emergency calls in the sense that they require the emergency indications, emergency call routing functionality and may even have the same location requirements. However, the communication interaction will not lead to the exchange of interactive media, that is, Real-Time Protocol packets, such as voice, video data or real-time text. ... This document describes a method of including a CAP message in a SIP transaction by defining it as a block of "additional data" as defined in [RFC7852]. The CAP message is i= ncluded either by value (the CAP message is in the body of the message, using a CID) or by reference (a URI is included in the message, which when dereferenced returns the CAP message). The additional data mechanism is also used to send alert specific data beyond that available in the CAP message. This document also describes how a SIP MESSAGE [RFC3428] transaction can be used to send a data-only call. This says that this document describes how to send an emergency call when t= here is not two way interactive media (voice, video and/or text), and it sa= ys that the way you do that is to send a SIP MESSAGE, with a CAP message po= inted to by a Call-Info header. That text seems very clear to me, and yet you didn=92t read what we hoped i= nto what we wrote. I would really like to fix this, but I=92m at a loss to= understand what I need to do. I=92ll improve the acronym stuff. On Aug 24, 2019, at 3:53 PM, Charlie Kaufman > 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 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. This document defines a new MIME type: 'application/EmergencyCallData.cap+x= ml' for use primarily by sensors to send alert messages to emergency servic= es providers. It also defines a new Emergency Call Data Type: 'cap' in orde= r to embed this data efficiently in a SIP transaction. I saw no new securit= y issues beyond those already noted for the protocols carrying these messag= es. I do have some editorial suggestions: There is a lot of context that the authors assumed any reader would have th= at could have been stated in the introduction. I believe from context that = the purpose of this new MIME type is to support simple (IoT) sensors that d= on't want to implement a more heavyweight protocol, but I don't believe tha= t was stated anywhere. I got the impression that the functionality provided could have been done w= ith existing protocols by sending the CAP message over a SIP session, but t= hat doing so would place an unnecessary burden on simple (IoT) sensors, and= that this protocol would be easier for such sensors to implement for the l= imited cases such sensors need to deal with. If that's true, it should be s= tated. If not, the purpose of this protocol should be more clearly stated. These acronyms were used but never defined: SIP CID LoST These acronyms were expanded, but not in an easy to find place: Common Alerting Protocol (CAP) Public Safety Answering Points (PSAPs) Emergency Services Routing Proxy (ESRP) It would be nice to include them in the terminology section, ideally with a= reference to the RFC where more information is available. Typo: p17 "security mechanism" -> "security mechanisms" --Charlie --_000_MWHPR04MB036724650A0D208BE4D22D58DFA20MWHPR04MB0367namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
My confusion had to do with whether this is adding new functionality or whe= ther this is a profiling of existing functionality to enable a lightweight = interaction. For example, is it possible to send a CAP message within a SIP= transaction when there is going to follow interactive two way media in the existing protocol? If so, this = could have been done with the previous protocol just by ending after the fi= rst exchange. If not, this is something that couldn't have been done before= and this is new functionality (and I would wonder why the old protocol did not allow this).

My confusion might be based on my lack of understanding of the layering of = CAP, SIP, and MIME, and it could be that anyone with a legitimate reason to= read this document would not be confused.

--Charlie

p.s. Apologies for the formatting. I'm using Outlook's web interface, which= tends to be overly clever and mess things up.

Sent from Outlook


From: Brian Rosen <br@= brianrosen.net>
Sent: Monday, August 26, 2019 1:34 PM
To: Charlie Kaufman <charliekaufman@outlook.com>
Cc: secdir@ietf.org <secdir@ietf.org>; iesg@ietf.org <iesg@= ietf.org>; draft-ietf-ecrit-data-only-ea.all@ietf.org <draft-ietf-ecr= it-data-only-ea.all@ietf.org>
Subject: Re: Secdir review of draft-ietf-ecrit-data-only-ea-18
 
Hi Charlie

Thanks for the review, I appreciate it.

The introduction section has this text
   Data-only emergency calls are similar to regula=
r emergency calls in=0A=
   the sense that they require the emergency indications, emergency call=0A=
   routing functionality and may even have the same location=0A=
   requirements.  However, the communication interaction will not lead=0A=
   to the exchange of interactive media, that is, Real-Time Protocol=0A=
   packets, such as voice, video data or real-time text.=0A=
=0A=
   ...=0A=
=0A=
   This document describes a method of including a CAP message in a SIP=0A=
   transaction by defining it as a block of "additional data" as =
defined=0A=
   in [RFC7852].  The CAP messa=
ge is included either by value (the CAP=0A=
   message is in the body of the message, using a CID) or by reference=0A=
   (a URI is included in the message, which when dereferenced returns=0A=
   the CAP message).  The additional data mechanism is also used to send=0A=
   alert specific data beyond that available in the CAP message.  This=0A=
   document also describes how a SIP MESSAGE [RFC3428] transaction can=0A=
   be used to send a data-only call.


This says that this document describes how to send an emergency c= all when there is not two way interactive media (voice, video and/or text),= and it says that the way you do that is to send a SIP MESSAGE, with a CAP = message pointed to by a Call-Info header.

That text seems very clear to me, and yet you didn=92t read what we ho= ped into what we wrote.  I would really like to fix this, but I=92m at= a loss to understand what I need to do.

I=92ll improve the acronym stuff.


On Aug 24, 2019, at 3:53 PM, Charlie Kaufman <charliekaufman@outlook.com> wrote:

I have reviewed this document as part of the security directorate's on= going effort to review all IETF documents being processed by the IESG. = ; These comments were written primarily for the benefit of the security are= a directors.  Document editors and WG chairs should treat these comments just like any other last call comments.=

This document defines a new MIME type: 'application/EmergencyCallData.= cap+xml' for use primarily by sensors to send alert messages to emergen= cy services providers. It also defines a new Emergency Call Data Type: 'cap= ' in order to embed this data efficiently in a SIP transaction. I saw no new security issues beyond those already no= ted for the protocols carrying these messages.

I do have some editorial suggestions:

There is a lot of context that the authors assumed any reader would ha= ve that could have been stated in the introduction. I believe from context = that the purpose of this new MIME type is to support simple (IoT) sensors t= hat don't want to implement a more heavyweight protocol, but I don't believe that was stated anywhere.

I got the impression that the functionality provided could have been d= one with existing protocols by sending the CAP message over a SIP session, = but that doing so would place an unnecessary burden on simple (IoT) sensors= , and that this protocol would be easier for such sensors to implement for the limited cases such sensors ne= ed to deal with. If that's true, it should be stated. If not, the purpose o= f this protocol should be more clearly stated.

These acronyms were used but never defined:

SIP
CID
LoST

These acronyms were expanded, but not in an easy to find place:

Common Alerting Protocol (CAP)
Public Safety Answering Points (PSAPs)
Emergency Services Routing Proxy (ESRP)

It would be nice to include them in the terminology section, ideally w= ith a reference to the RFC where more information is available.

Typo:

p17 "security mechanism" -> "security mechanisms&quo= t;

 --Charlie

--_000_MWHPR04MB036724650A0D208BE4D22D58DFA20MWHPR04MB0367namp_-- From nobody Thu Aug 29 14:48:12 2019 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 5795C1200CE for ; Thu, 29 Aug 2019 14:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fk0R_hmoqt73 for ; Thu, 29 Aug 2019 14:47:49 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1AA120824 for ; Thu, 29 Aug 2019 14:47:49 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id d23so4417863qko.3 for ; Thu, 29 Aug 2019 14:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=odg6dpKij/LmHrS2Ds0OllMn7Rdvh+ENHikA91oO+zw=; b=GLFPvKfXicijOD6QoKr4vUOukryMV7rZ0nWi4wQIZE123TC22sb8bLj86sovlB0TF8 eTYzE/JLX1jF2Df45w/0/OjmnlXQZrQPIgvui0UpVNdJdnNrFvEM9LsQWU7NiudMPhE2 lAu1I/8Nd8cN7d6oBwtB2iPge5Qk2GCoUoxBUO2jrH7PHztcnG05noqIZMBF/SKY/xtS yT+MOC/lKZ0j9/vs0Az355eJajxcWsz3kDoCchNyICCHSMKI8qjhRtFn3Igp2JWeTJJO nn6M7evdKO9r0onKQkWZIRP3bP149YBJA7VNI6E3jF29SJdSySJ+N1USzwIFGlerCp4T WZrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=odg6dpKij/LmHrS2Ds0OllMn7Rdvh+ENHikA91oO+zw=; b=UzC66rDFW1ZPgM5utiM6o+wYOIQcWh8fF/qY2j2lIiAf4wre6Ep78lSXknz2nNfhMX FuzQTOR0RY8ufq70KOypYY/sC7WWyx4+n6JRpmhNgX3MfsU1gI9ZduSaJ/KjjQ9SNDb7 O8JeLUGrl2n6zsSPPIwt6EkyQA9iPTSTfFCAAQzTDZgAzDDFjBUZuR87jiO1iLC+Ir9y B1UY/lgLkh3jYN3XInvYiwLVPqj9QreAuJiehOvpzpiFR3i+5m1awZOZ1UunlTUyMyNr XTwRJEgn56fYdsYPr8kTWeGh6nWXvGkhGN/z1LKPjFiPJQE/h3EFQNagzPeHMKDVkccj df+g== X-Gm-Message-State: APjAAAUKHJXzrCtLCsYvdUjtcGeMs4P6BsnSiYGmG761wp/0eMxJ0ioX /UZP2/08In7VFNHejxm+/UeScg== X-Google-Smtp-Source: APXvYqx6RkdYwpPngDSyxaNuClliKzu+fPVzNFft/+uFQHx951tNpcpXw+5Tzhah6lZ8skdVORo+aA== X-Received: by 2002:a37:4a0b:: with SMTP id x11mr12078508qka.395.1567115268455; Thu, 29 Aug 2019 14:47:48 -0700 (PDT) Received: from brians-mbp-2388.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id r189sm1875773qkc.60.2019.08.29.14.47.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Aug 2019 14:47:47 -0700 (PDT) From: Brian Rosen Message-Id: <1D728931-DCCE-4A87-A247-A4A7FE1D8BE7@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_93D6D405-21E2-400A-84BF-6D9B1923FE1F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 29 Aug 2019 17:47:45 -0400 In-Reply-To: Cc: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ecrit-data-only-ea.all@ietf.org" To: Charlie Kaufman References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-data-only-ea-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 21:47:55 -0000 --Apple-Mail=_93D6D405-21E2-400A-84BF-6D9B1923FE1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It=E2=80=99s new functionality. RFC6881 defines an interactive = emergency call that uses SIP INVITE. It does not have a CAP message. = This document defines a non-interactive (in the real time media sense) = call that uses SIP MESSAGE and includes the CAP message. To get CAP into any SIP transaction, you put it in.a =E2=80=98body=E2=80=99= which is MIME encoded. So the layering is: SIP MESSAGE bodypart MIME CAP Brian > On Aug 29, 2019, at 5:17 PM, Charlie Kaufman = wrote: >=20 > My confusion had to do with whether this is adding new functionality = or whether this is a profiling of existing functionality to enable a = lightweight interaction. For example, is it possible to send a CAP = message within a SIP transaction when there is going to follow = interactive two way media in the existing protocol? If so, this could = have been done with the previous protocol just by ending after the first = exchange. If not, this is something that couldn't have been done before = and this is new functionality (and I would wonder why the old protocol = did not allow this). >=20 > My confusion might be based on my lack of understanding of the = layering of CAP, SIP, and MIME, and it could be that anyone with a = legitimate reason to read this document would not be confused. >=20 > --Charlie >=20 > p.s. Apologies for the formatting. I'm using Outlook's web interface, = which tends to be overly clever and mess things up. >=20 > Sent from Outlook >=20 > From: Brian Rosen > Sent: Monday, August 26, 2019 1:34 PM > To: Charlie Kaufman > Cc: secdir@ietf.org ; iesg@ietf.org ; = draft-ietf-ecrit-data-only-ea.all@ietf.org = > Subject: Re: Secdir review of draft-ietf-ecrit-data-only-ea-18 > =20 > Hi Charlie >=20 > Thanks for the review, I appreciate it. >=20 > The introduction section has this text > Data-only emergency calls are similar to regular emergency calls in > the sense that they require the emergency indications, emergency = call > routing functionality and may even have the same location > requirements. However, the communication interaction will not lead > to the exchange of interactive media, that is, Real-Time Protocol > packets, such as voice, video data or real-time text. >=20 > ... >=20 > This document describes a method of including a CAP message in a = SIP > transaction by defining it as a block of "additional data" as = defined > in [RFC7852 ]. The CAP = message is included either by value (the CAP > message is in the body of the message, using a CID) or by reference > (a URI is included in the message, which when dereferenced returns > the CAP message). The additional data mechanism is also used to = send > alert specific data beyond that available in the CAP message. This > document also describes how a SIP MESSAGE [RFC3428 = ] transaction can > be used to send a data-only call. >=20 >=20 > This says that this document describes how to send an emergency call = when there is not two way interactive media (voice, video and/or text), = and it says that the way you do that is to send a SIP MESSAGE, with a = CAP message pointed to by a Call-Info header. >=20 > That text seems very clear to me, and yet you didn=E2=80=99t read what = we hoped into what we wrote. I would really like to fix this, but I=E2=80= =99m at a loss to understand what I need to do. >=20 > I=E2=80=99ll improve the acronym stuff. >=20 >=20 >> On Aug 24, 2019, at 3:53 PM, Charlie Kaufman = > wrote: >>=20 >> 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. >>=20 >> This document defines a new MIME type: = 'application/EmergencyCallData.cap+xml' for use primarily by sensors to = send alert messages to emergency services providers. It also defines a = new Emergency Call Data Type: 'cap' in order to embed this data = efficiently in a SIP transaction. I saw no new security issues beyond = those already noted for the protocols carrying these messages. >>=20 >> I do have some editorial suggestions: >>=20 >> There is a lot of context that the authors assumed any reader would = have that could have been stated in the introduction. I believe from = context that the purpose of this new MIME type is to support simple = (IoT) sensors that don't want to implement a more heavyweight protocol, = but I don't believe that was stated anywhere. >>=20 >> I got the impression that the functionality provided could have been = done with existing protocols by sending the CAP message over a SIP = session, but that doing so would place an unnecessary burden on simple = (IoT) sensors, and that this protocol would be easier for such sensors = to implement for the limited cases such sensors need to deal with. If = that's true, it should be stated. If not, the purpose of this protocol = should be more clearly stated. >>=20 >> These acronyms were used but never defined: >>=20 >> SIP >> CID >> LoST >>=20 >> These acronyms were expanded, but not in an easy to find place: >>=20 >> Common Alerting Protocol (CAP) >> Public Safety Answering Points (PSAPs) >> Emergency Services Routing Proxy (ESRP) >>=20 >> It would be nice to include them in the terminology section, ideally = with a reference to the RFC where more information is available. >>=20 >> Typo: >>=20 >> p17 "security mechanism" -> "security mechanisms" >>=20 >> --Charlie --Apple-Mail=_93D6D405-21E2-400A-84BF-6D9B1923FE1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It=E2=80=99s new functionality.  RFC6881 defines an = interactive emergency call that uses SIP INVITE.  It does not have = a CAP message.  This document defines a non-interactive (in the = real time media sense) call that uses SIP MESSAGE and includes the CAP = message.

To get CAP = into any SIP transaction, you put it in.a =E2=80=98body=E2=80=99 which = is MIME encoded.  So the layering is:
SIP = MESSAGE
bodypart MIME
= CAP

Brian

On Aug 29, 2019, at 5:17 PM, = Charlie Kaufman <charliekaufman@outlook.com> wrote:

My = confusion had to do with whether this is adding new functionality or = whether this is a profiling of existing functionality to enable a = lightweight interaction. For example, is it possible to send a CAP = message within a SIP transaction when there is going to follow = interactive two way media in the existing protocol? If so, this could = have been done with the previous protocol just by ending after the first = exchange. If not, this is something that couldn't have been done before = and this is new functionality (and I would wonder why the old protocol = did not allow this).

My = confusion might be based on my lack of understanding of the layering of = CAP, SIP, and MIME, and it could be that anyone with a legitimate reason = to read this document would not be confused.

--Charlie

p.s. = Apologies for the formatting. I'm using Outlook's web interface, which = tends to be overly clever and mess things up.

Sent from Outlook

From: Brian Rosen <br@brianrosen.net>
Sent: Monday, August 26, 2019 = 1:34 PM
To: Charlie Kaufman <charliekaufman@outlook.com>
Cc: secdir@ietf.org <secdir@ietf.org>; iesg@ietf.org <iesg@ietf.org>; draft-ietf-ecrit-data-only-ea.all@ietf.org <draft-ietf-ecrit-data-only-ea.all@ietf.org>
Subject: Re: Secdir review of = draft-ietf-ecrit-data-only-ea-18
 
Hi Charlie
Thanks for the review, I appreciate = it.

The = introduction section has this text
   Data-only emergency calls are similar to regular =
emergency calls in
   the sense that they require the emergency indications, emergency call
   routing functionality and may even have the same location
   requirements.  However, the communication interaction will not lead
   to the exchange of interactive media, that is, Real-Time Protocol
   packets, such as voice, video data or real-time text.

   ...

   This document describes a method of including a CAP message in a SIP
   transaction by defining it as a block of "additional data" as defined
   in [RFC7852].  The CAP message is included either by value =
(the CAP
   message is in the body of the message, using a CID) or by reference
   (a URI is included in the message, which when dereferenced returns
   the CAP message).  The additional data mechanism is also used to send
   alert specific data beyond that available in the CAP message.  This
   document also describes how a SIP MESSAGE [RFC3428] =
transaction can
   be used to send a data-only call.


This says that this document describes how to send an = emergency call when there is not two way interactive media (voice, video = and/or text), and it says that the way you do that is to send a SIP = MESSAGE, with a CAP message pointed to by a Call-Info header.

That text seems very = clear to me, and yet you didn=E2=80=99t read what we hoped into what we = wrote.  I would really like to fix this, but I=E2=80=99m at a loss = to understand what I need to do.

I=E2=80=99ll improve the acronym = stuff.


On Aug = 24, 2019, at 3:53 PM, Charlie Kaufman <charliekaufman@outlook.com> 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 defines a new MIME type: = 'application/EmergencyCallData.cap+xml' for use primarily by sensors to = send alert messages to emergency services providers. It also defines a = new Emergency Call Data Type: 'cap' in order to embed this data = efficiently in a SIP transaction. I saw no new security issues beyond = those already noted for the protocols carrying these messages.

I do have some editorial = suggestions:

There is a lot of context that the authors assumed any reader = would have that could have been stated in the introduction. I believe = from context that the purpose of this new MIME type is to support simple = (IoT) sensors that don't want to implement a more heavyweight protocol, = but I don't believe that was stated anywhere.

I got the impression that the = functionality provided could have been done with existing protocols by = sending the CAP message over a SIP session, but that doing so would = place an unnecessary burden on simple (IoT) sensors, and that this = protocol would be easier for such sensors to implement for the limited = cases such sensors need to deal with. If that's true, it should be = stated. If not, the purpose of this protocol should be more clearly = stated.

These = acronyms were used but never defined:

SIP
CID
LoST

These acronyms were expanded, but not in an easy to find = place:

Common = Alerting Protocol (CAP)
Public Safety Answering Points = (PSAPs)
Emergency Services Routing Proxy (ESRP)

It would be nice to = include them in the terminology section, ideally with a reference to the = RFC where more information is available.

Typo:

p17 "security mechanism" -> = "security mechanisms"

 --Charlie

= --Apple-Mail=_93D6D405-21E2-400A-84BF-6D9B1923FE1F--