From nobody Sun Jan 1 08:26:36 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D85B71293F4; Sun, 1 Jan 2017 08:26:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148328799488.25220.17994465220699555250.idtracker@ietfa.amsl.com> Date: Sun, 01 Jan 2017 08:26:34 -0800 Archived-At: Cc: draft-ietf-sidr-bgpsec-pki-profiles.all@ietf.org, sidr@ietf.org Subject: [sidr] Review of draft-ietf-sidr-bgpsec-pki-profiles-19 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2017 16:26:35 -0000 Reviewer: Yaron Sheffer Review result: Has Nits * 3.1.1: The serial number in RFC 6487 is still a real, unique serial number that uniquely identifies the certificate. Here it is used as something other than a serial number, which is explicitly NOT unique, and the CA is left to decide how to make it unique in the face of potentially repeating BGP IDs. If this is not a real issue (e.g. because duplicate IDs are rare and never within a RIR), please say so. * 3.2: earlier we said that Basic Constraints must not be included in the EE cert. Now we are saying that only a particular boolean flag must not be honored when processing the Cert Request. What happens if Basic Constraints is included in the Cert Request but with other flags? * 3.3: ID.sidr-rfc6485bis -> RFC 7935 * 6: in the paragraph that discusses hash functions, please spell out the names of the two key identifiers, because I cannot determine what they are from the document. From nobody Sun Jan 1 11:15:57 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C422126B6D; Sun, 1 Jan 2017 11:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 CTB72VH1oXOQ; Sun, 1 Jan 2017 11:15:55 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [IPv6:2001:418:8006::30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD9312941E; Sun, 1 Jan 2017 11:15:55 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 5223B1399E; Sun, 1 Jan 2017 19:15:53 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id ADABC4576F68; Sun, 1 Jan 2017 14:16:11 -0500 (EST) Date: Sun, 01 Jan 2017 14:16:11 -0500 From: Rob Austein To: Yaron Sheffer In-Reply-To: <148328799488.25220.17994465220699555250.idtracker@ietfa.amsl.com> References: <148328799488.25220.17994465220699555250.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170101191611.ADABC4576F68@minas-ithil.hactrn.net> Archived-At: Cc: sidr@ietf.org, draft-ietf-sidr-bgpsec-pki-profiles.all@ietf.org, secdir@ietf.org Subject: Re: [sidr] Review of draft-ietf-sidr-bgpsec-pki-profiles-19 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2017 19:15:56 -0000 At Sun, 01 Jan 2017 08:26:34 -0800, Yaron Sheffer wrote: > > Reviewer: Yaron Sheffer > Review result: Has Nits > > * 3.1.1: The serial number in RFC 6487 is still a real, unique serial > number that uniquely identifies the certificate. Here it is used as > something other than a serial number, which is explicitly NOT unique, > and the CA is left to decide how to make it unique in the face of > potentially repeating BGP IDs. If this is not a real issue (e.g. > because duplicate IDs are rare and never within a RIR), please say > so. Er, I suspect you're confusing serial numbers with serial numbers. 3.1.1 of this draft is talking about the id-at-serialNumber attribute in the Subject field (RFC 5280 4.1.2.6, naming attribute type X520SerialNumber), a different thing entirely from the certificate Serial Number (RFC 5280 4.1.2.2, type CertificateSerialNumber). Just to make things more interesting, both are called serialNumber in different contexts. Clear as mud, I know. So, agreed that this probably does need clarification, but perhaps not quite the clarification you thought it needed. From nobody Mon Jan 2 03:10:24 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246631294FF; Mon, 2 Jan 2017 03:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 x6XDaEQvcwqU; Mon, 2 Jan 2017 03:10:19 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 4A82D129437; Mon, 2 Jan 2017 03:10:19 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cO0VN-0006mj-TS; Mon, 02 Jan 2017 11:10:18 +0000 Date: Mon, 02 Jan 2017 20:10:15 +0900 Message-ID: From: Randy Bush To: Yaron Sheffer In-Reply-To: <148328799488.25220.17994465220699555250.idtracker@ietfa.amsl.com> References: <148328799488.25220.17994465220699555250.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr@ietf.org, draft-ietf-sidr-bgpsec-pki-profiles.all@ietf.org, secdir@ietf.org Subject: Re: [sidr] Review of draft-ietf-sidr-bgpsec-pki-profiles-19 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 11:10:20 -0000 > potentially repeating BGP IDs not weighing in on the rest. but i am not sure what you mean by bgp id. if it is routerID, those are unique within an AS. randy From nobody Mon Jan 2 05:29:42 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F2D1293F5; Mon, 2 Jan 2017 05:29:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148336377615.21819.15119186800162780376.idtracker@ietfa.amsl.com> Date: Mon, 02 Jan 2017 05:29:36 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-bgpsec-ops@ietf.org, sidr@ietf.org Subject: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-bgpsec-ops-12=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 13:29:36 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-sidr-bgpsec-ops-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Quick question: I'm by far not an expert here, but I remember that there used to be some concerns that it is practical not possible to disable BGPsec once enabled. If that's (still) true, should this be mentioned here? From nobody Mon Jan 2 05:45:32 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFCD129463; Mon, 2 Jan 2017 05:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 ZmTlSqaHbSBs; Mon, 2 Jan 2017 05:45:26 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 C7E26124281; Mon, 2 Jan 2017 05:45:26 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cO2vP-0007Gf-Td; Mon, 02 Jan 2017 13:45:20 +0000 Date: Mon, 02 Jan 2017 22:45:16 +0900 Message-ID: From: Randy Bush To: "Mirja Kuehlewind" In-Reply-To: <148336377615.21819.15119186800162780376.idtracker@ietfa.amsl.com> References: <148336377615.21819.15119186800162780376.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: draft-ietf-sidr-bgpsec-ops@ietf.org, Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org Subject: Re: [sidr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-sidr-bgpsec-ops-12=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 13:45:28 -0000 > Quick question: I'm by far not an expert here, but I remember that > there used to be some concerns that it is practical not possible to > disable BGPsec once enabled. If that's (still) true, should this be > mentioned here? i am not sure what you mean, so let me guess. an established bgp session has negotiated simplex or duplex bgpsec via bgp capability exchange. one can not change the agreement without tearing down and restarting the session. a router which is bgpsec enabled, receives a signed path from the left, but on the right it had a non-sec session, strips the bgpsec info from the path. these are discussed in the bgpsec protocol document. section 6, appended to save dumster diving, shows some of the operational uses of this. do you have suggestions for other examples worth enumerating? randy 6. Considerations for Edge Sites An edge site which does not provide transit and trusts its upstream(s) SHOULD only originate a signed prefix announcement and need not validate received announcements. An Operator might need to use hardware with limited resources. In such cases, BGPsec protocol capability negotiation allows for a resource constrained edge router to hold only its own signing key(s) and sign its announcements, but not receive signed announcements. Therefore, the router would not have to deal with the majority of the RPKI, potentially saving the need for additional hardware. As the vast majority (84%) of ASs are stubs, and they announce the majority of prefixes, this allows for simpler and less expensive incremental deployment. It may also mean that edge sites concerned with routing security will be attracted to upstreams which support BGPsec. From nobody Mon Jan 2 06:01:20 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9128F1295F3 for ; Mon, 2 Jan 2017 06:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 bBzkapj-OWit for ; Mon, 2 Jan 2017 06:01:19 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97651295F6 for ; Mon, 2 Jan 2017 06:01:17 -0800 (PST) Received: (qmail 18098 invoked from network); 2 Jan 2017 15:01:16 +0100 Received: from p5dec2761.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.39.97) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 Jan 2017 15:01:16 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Mon, 2 Jan 2017 15:01:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <563AAA29-82F7-4202-8A54-855CD7702595@kuehlewind.net> References: <148336377615.21819.15119186800162780376.idtracker@ietfa.amsl.com> To: Randy Bush X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ietf-sidr-bgpsec-ops@ietf.org, Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org Subject: Re: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-bgpsec-ops-12=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 14:01:19 -0000 Hi Randy, thanks for you quick reply. I actually might be mixing this up with some discussion about DNSsec a = while ago, where the problem was that once enable others will remember = that it was supported and will not accept non secured requests anymore.=20= But as we are talking about this, could there be a similar case here, = where a router is known to support BGPsec and others would ignore/drop = non-signed announcements? (Sorry if that=E2=80=99s all discussed in the = protocol doc; in this case just ignore my questions ;-); didn=E2=80=99t = review the protocol spec yet but it=E2=80=99s the next doc on my list; = probably should have read that one first=E2=80=A6) Mirja > Am 02.01.2017 um 14:45 schrieb Randy Bush : >=20 >> Quick question: I'm by far not an expert here, but I remember that >> there used to be some concerns that it is practical not possible to >> disable BGPsec once enabled. If that's (still) true, should this be >> mentioned here? >=20 > i am not sure what you mean, so let me guess. >=20 > an established bgp session has negotiated simplex or duplex bgpsec via > bgp capability exchange. one can not change the agreement without > tearing down and restarting the session. >=20 > a router which is bgpsec enabled, receives a signed path from the = left, > but on the right it had a non-sec session, strips the bgpsec info from > the path. >=20 > these are discussed in the bgpsec protocol document. section 6, > appended to save dumster diving, shows some of the operational uses of > this. do you have suggestions for other examples worth enumerating? >=20 > randy >=20 > 6. Considerations for Edge Sites >=20 > An edge site which does not provide transit and trusts its > upstream(s) SHOULD only originate a signed prefix announcement and > need not validate received announcements. >=20 > An Operator might need to use hardware with limited resources. In > such cases, BGPsec protocol capability negotiation allows for a > resource constrained edge router to hold only its own signing key(s) > and sign its announcements, but not receive signed announcements. > Therefore, the router would not have to deal with the majority of = the > RPKI, potentially saving the need for additional hardware. >=20 > As the vast majority (84%) of ASs are stubs, and they announce the > majority of prefixes, this allows for simpler and less expensive > incremental deployment. It may also mean that edge sites concerned > with routing security will be attracted to upstreams which support > BGPsec. From nobody Mon Jan 2 07:32:56 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3A3120727 for ; Mon, 2 Jan 2017 07:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 xAIdyknN4sxQ for ; Mon, 2 Jan 2017 07:32:53 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0126.outbound.protection.outlook.com [23.103.200.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4962A12965B for ; Mon, 2 Jan 2017 07:32:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Sa3wD3RiiUzspqX9sQpuoOpeEUPlWFxK/nU7FXT9T40=; b=LfmKVRIl07SB+c0F3IcvxWFv6R4OEBO+CEZLqRFbmjFROdDj+kH8ruW8zKdqkCuaY64A/yPBFesU/aJRfJid6X0fFDxtDXpbjJ/zFPyrX2Ub+8DJ6zt4/EaPSxvgVU3cxHFo9DqTmsr6BLnh2IpdLy/RWZ+Gfd98TmF9V44eVPc= Received: from BL2PR09MB0996.namprd09.prod.outlook.com (10.167.102.15) by CY1PR09MB0443.namprd09.prod.outlook.com (10.160.150.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Mon, 2 Jan 2017 15:32:50 +0000 Received: from BL2PR09MB0996.namprd09.prod.outlook.com ([10.167.102.15]) by BL2PR09MB0996.namprd09.prod.outlook.com ([10.167.102.15]) with mapi id 15.01.0817.009; Mon, 2 Jan 2017 15:32:49 +0000 From: "Borchert, Oliver (Fed)" To: Randy Bush , "Sriram, Kotikalapudi (Fed)" Thread-Topic: [sidr] Confederations and Private ASNs (WAS: AD Review of draft-ietf-sidr-bgpsec-protocol-18) Thread-Index: AQHSUmenE2EHhTbiU0q7IXrD4ZYx2aEfNZ3QgAB6v4CABXIAAA== Date: Mon, 2 Jan 2017 15:32:48 +0000 Message-ID: References: <7055D209-5BF7-4B5D-A675-356CD2CBFF4D@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [108.56.241.51] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0443; 7:7ddYX8RRNpZLHKFMXslSKz7X44npLmszGAS6nwhAd/sC+nxfAXOEkL/xmuiD0miMkv1Hh5YXoa0o7DAvCwC8JEMoHKSx9pDoWZFynxXCkm1XXeW2rzzumzYMGXkB1ziI5DP4y8Tjko0y1H8t5EvHo/GEmoWX4B6fgX+D2rzQndzCutsXFGi4lwXKkcrMal5oKSRwslYsFw6H/iZ9/MAhdXPJ2tvnyONG4qV1ZcET6AKMHkpK7RtIpjNix+Lp2TQAFgktbRUYdSE+VWsCMLLfFiWWfz2EUTZAjcqB8Lqc0Gsh/hOsPopq5IH4H7l6WgXJy9h+gR5a4VYgTzpxuNMaawOeGXaTi+XebggnTC/UXjC8F3/yeO0U6bjbEqv/egNu0QzNyHYhZJ9FsFANpbANBlMZ3bfuNDTcaUkHZL/Q7JWcTsUWf6/6bz/+dUmmEFUsMJkGzRD0X0Iqyk5IbEJAWw== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39410400002)(39450400003)(39850400002)(377454003)(199003)(189002)(24454002)(76176999)(6506006)(230783001)(25786008)(54356999)(82746002)(83506001)(36756003)(2900100001)(6436002)(38730400001)(5001770100001)(83716003)(66066001)(81166006)(99286003)(229853002)(68736007)(33656002)(81156014)(101416001)(106356001)(2950100002)(8676002)(86362001)(77096006)(97736004)(102836003)(50986999)(6512006)(6486002)(7736002)(122556002)(3660700001)(2906002)(189998001)(106116001)(3280700002)(5660300001)(105586002)(8936002)(4326007)(3846002)(6862003)(6636002)(4001350100001)(305945005)(92566002)(6116002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0443; H:BL2PR09MB0996.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: ad8b376e-3eaf-43f4-20ed-08d433249bbb x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558021)(20161123560025)(6072148); SRVR:CY1PR09MB0443; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0443; x-forefront-prvs: 017589626D received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <24267A3314DF11498AD0761CC600C81A@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2017 15:32:48.9162 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0443 Archived-At: Cc: sidr wg list Subject: Re: [sidr] Confederations and Private ASNs (WAS: AD Review of draft-ietf-sidr-bgpsec-protocol-18) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 15:32:55 -0000 U2VlIG15IGNvbW1lbnRzIGlubGluZQ0KDQpPbiAxMi8yOS8xNiwgNjoyMyBQTSwgInNpZHIgb24g YmVoYWxmIG9mIFJhbmR5IEJ1c2giIDxzaWRyLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IHJhbmR5QHBzZy5jb20+IHdyb3RlOg0KDQogICAgPj4+IDEuIEl0IGlzIGNvbW1vbiB0byB1c2Ug cHJpdmF0ZSBBU05zIGluIENvbmZlZGVyYXRpb25zLCANCiAgICA+PiBidXQgdGhlIGdsb2JhbCBS UEtJIGNhbuKAmXQgc3VwcG9ydCB0aGF0LiAgZHJhZnQtaWV0Zi1zaWRyLXNsdXJtIHNlZW1zDQog ICAgPj4gdG8gYWRkcmVzcyB0aGUgaXNzdWUgb2YgbG9jYWwgbWFuYWdlbWVudCBvZiBwcml2YXRl IHJlc291cmNlcyBpbiB0aGUNCiAgICA+PiBSUEtJLiAg4oCmDQogICAgDQogICAgPnRoZSBpc3N1 ZSBpcyBub3QgaG93IHRoZSBjb25mZWQgQVMgdmFsaWRhdGVzIFJPQXMgb2YgdGhlIHByaXZhdGUg QVNzIGluDQogICAgPnRoZSBjb25mZWQuICB0aGF0IGlzIHRyaXZpYWwgYW5kIHN1cHBvcnRlZCBi eSBleGlzdGluZyBzb2Z0d2FyZS4gIG15DQogICAgPnF1ZXN0aW9ucyByZXZvbHZlIGFyb3VuZCBw YXRoIHByb2Nlc3NpbmcuDQoNCg0KSSBiZWxpZXZlIHRoZSBhbnN3ZXIgdG8geW91ciBxdWVzdGlv biBpcyBmb3VuZCBpbiBzZWN0aW9uIDcsIHBhcmFncmFwaCAjOCBhbmQgZm9sbG93aW5nLiANClRo ZXJlIEkgc2VlIGV4cGxhbmF0aW9uIG9uIGhvdyB0byBwcm9jZXNzIHRoZSBwYXRoIHVzaW5nIHBy aXZhdGUgQVMgbnVtYmVycywgZXRjLg0KDQogICAgDQogICAgPjQuMyBjb25mdXNlcyBtZSBieSB1 c2luZyAncHJpdmF0ZScgYW1iaWd1b3VzbHkuICBpIGhhdmUgdHJpZWQgdG8gcmVhZA0KICAgID50 aGF0IHNlY3Rpb24geWV0IGFnYWluIGFuZCBkcm93bmVkIGluIHRoZSBtYXNzIG9mIHdvcmRzLiAg cGVyaGFwcyBtb3JlDQogICAgPmNvZmZlZSB3aWxsIGhlbHA7IGJ1dCBpIGFtIG5vdCBvcHRpbWlz dGljLiAgaSBwaXR5IHRoZSBpbXBsZW1lbnRvcnMuIA0KICAgID4NCiAgICA+cmFuZHkgICAgDQoN ClJldmlzaXRpbmcgU2VjdGlvbiA0LjMsIEkgbWFkZSB0aGUgZm9sbG93aW5nIG9ic2VydmF0aW9u czoNCkluIG15IG9waW5pb24gdGhlIHNlY29uZCBQYXJhZ3JhcGggZXhwbGFpbnMgY2xlYXJseSB0 aGUgcHJvY2VzcyBvZiB0aGUgaW5ncmVzcyBCR1BTZWMgDQpyb3V0ZXIgYXQgdGhlIGNvbmZlZGVy YXRpb24gYm91bmRhcnkuIEkgYmVsaWV2ZSB0aGUgcHJvY2VzcyBkZXNjcmliZWQgb2YgYWRkaW5n IGEgDQpzaWduYXR1cmUgd2l0aCBwQ291bnQ9MCB3aWxsIHJlc29sdmUgdGhlIGlzc3VlIHRoYXQg QWx2YXJvIG9ic2VydmVkLg0KDQpTYWlkIHRoYXQsIEkgZmVlbCB0aGF0IHRoZSBleHBsYW5hdGlv bnMgaW4gcGFyYWdyYXBocyAjMyBhbmQgIzQgYXJlIG5vdCB2ZXJ5IGhlbHBmdWwuIA0KVGhlcmUg SSBkbyBhZ3JlZSB3aXRoIFJhbmR5J3MgIm1hc3Mgb2Ygd29yZHMiIGNvbW1lbnQuIEkgc3VnZ2Vz dCB0byBlaXRoZXIgc2hvcnRlbiANCnRoZW0gb3IgY29tcGxldGVseSByZW1vdmUgdGhlbS4gVGhl c2UgdHdvIHBhcmFncmFwaHMgYXJlIG5vdCBuZWVkZWQsIGluIGNvbnRyYXJ5IA0KdGhleSBtaWdo dCBhZGQgdW5uZWNlc3NhcnkgY29uZnVzaW9uLg0KDQpXaGVuIHJlbW92ZWQgdGhlIGZvbGxvd2lu ZyBjdXJyZW50IHBhcmFncmFwaHMgNSBhbmQgZm9sbG93aW5nIGRvIGV4cGxhaW4gY2xlYXJseSB0 aGUNCnByb2Nlc3MgaW4gdGhlIGludGVybWVkaWF0ZSBBUy1tZW1iZXJzIGFuZCB0aGUgZWdyZXNz IEJHUFNlYyByb3V0ZXIgb2YgdGhlIA0KY29uZmVkZXJhdGlvbi4NCg0KSW4gc2hvcnQgSSB0aGlu ayBwYXJhZ3JhcGhzICMzIGFuZCAjNCBkaXNydXB0IHRoZSBmbG93IGFuZCBhcmUgbm90IHNvIGhl bHBmdWwsDQpzbyBJIHByb3Bvc2UgdG8gcmVtb3ZlIHRoZW0uDQoNClRvIGF2b2lkIHVubmVjZXNz YXJ5IGNvbmZ1c2lvbiB3aXRoIHRoZSBhbWJpZ3VpdHkgb2YgdGhlIHdvcmQgcHJpdmF0ZSwgSSB3 b3VsZCBjaGFuZ2UgDQp0aGUgd29yZGluZyBvZiDigJx0aGUgKHByaXZhdGUpIE1lbWJlci1BUyBO dW1iZXLigJ0gdG8g4oCcdGhlIE1lbWJlci1BUyBOdW1iZXLigJ0gYnkgDQpyZW1vdmluZyB0aGUg d29yZGluZyBvZiDigJwocHJpdmF0ZSnigJ0gd2l0aGluIHBhcmVudGhlc2lzLiANClRoaXMgbGVh dmVzIHRoZSB1c2FnZSBvZiBwcml2YXRlIG9ubHkgZm9yIHRoZSBzaWduaW5nIHBhcnRpZXMgcHJp dmF0ZSBrZXkgd2hpY2ggSSB0aGluayANCmlzIHdlbGwgdW5kZXJzdG9vZC4NCg0KT2xpdmVyIA0K DQo= From nobody Mon Jan 2 07:34:00 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D8A12965F; Mon, 2 Jan 2017 07:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 I4saIfB7LsXM; Mon, 2 Jan 2017 07:33:58 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 E76A4120727; Mon, 2 Jan 2017 07:33:57 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cO4cT-0007jf-3l; Mon, 02 Jan 2017 15:33:53 +0000 Date: Tue, 03 Jan 2017 00:33:49 +0900 Message-ID: From: Randy Bush To: "Mirja Kuehlewind (IETF)" In-Reply-To: <563AAA29-82F7-4202-8A54-855CD7702595@kuehlewind.net> References: <148336377615.21819.15119186800162780376.idtracker@ietfa.amsl.com> <563AAA29-82F7-4202-8A54-855CD7702595@kuehlewind.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: draft-ietf-sidr-bgpsec-ops@ietf.org, Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org Subject: Re: [sidr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-sidr-bgpsec-ops-12=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 15:33:59 -0000 hi mirja, > could there be a similar case here, where a router is known to support > BGPsec and others would ignore/drop non-signed announcements? hmmmm. as far as i can remember, this has not actually been discussed. how would a router be known to support bgpsec? well, if i saw it on a signed path. (for the moment, let's ignore changes over time). but it might have an out-degree of O(100) and some portion are signed and the rest not. the ones that are not signed are due to the peer not negotiating bgpsec, or that one or the other is configured to not have the peering be bgpsec. and it's way too late here for me to do the necessary deep dive into draft-ietf-sidr-bgpsec-pki-profiles-18.txt to know if i can definitively identify a router, especially as one router can have multiple ASs and therefore multiple certs and therefore multiple skis. maybe someone on the us beast coast has had enough coffee to hit me with a clue by four when i wake. randy From nobody Mon Jan 2 16:35:30 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23BC12951D; Mon, 2 Jan 2017 16:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 Lu4DHR3yCldQ; Mon, 2 Jan 2017 16:35:28 -0800 (PST) Received: from relay.kvm02.ops-netman.net (relay.kvm02.ops-netman.net [IPv6:2606:700:e:550:5c82:28ff:fe25:4960]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F69129513; Mon, 2 Jan 2017 16:35:28 -0800 (PST) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id F3CF43FF82; Tue, 3 Jan 2017 00:35:26 +0000 (UTC) Received: from morrowc-glaptop4.roam.corp.google.com.ops-netman.net (static-96-241-182-39.washdc.fios.verizon.net [96.241.182.39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 34530BA989F6; Tue, 3 Jan 2017 00:35:26 +0000 (UTC) Date: Mon, 02 Jan 2017 19:35:25 -0500 Message-ID: From: Chris Morrow To: Randy Bush In-Reply-To: References: <148336377615.21819.15119186800162780376.idtracker@ietfa.amsl.com> <563AAA29-82F7-4202-8A54-855CD7702595@kuehlewind.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: draft-ietf-sidr-bgpsec-ops@ietf.org, Chris Morrow , sidr-chairs@ietf.org, "Mirja Kuehlewind \(IETF\)" , The IESG , sidr@ietf.org Subject: Re: [sidr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-sidr-bgpsec-ops-12=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 00:35:29 -0000 At Tue, 03 Jan 2017 00:33:49 +0900, Randy Bush wrote: > > hi mirja, > > > could there be a similar case here, where a router is known to support > > BGPsec and others would ignore/drop non-signed announcements? > > hmmmm. as far as i can remember, this has not actually been discussed. i think this is correct. (I don't remember discussing something like this in the past) I can imagine a future where the operations staff decides: "We only do bgpsec (with peers x, y, z) turn on the knob that requires bgpsec at peer establishment!" In that case, if it were to be true, the operator would have chosen to only do bgpsec and not fallback to normal bgp... The router(s) aren't really remembering that their peer did bgpsec in the past as much as requiring the bgpsec capability at peer 'connect'. > how would a router be known to support bgpsec? well, if i saw it on a > signed path. (for the moment, let's ignore changes over time). but it > might have an out-degree of O(100) and some portion are signed and the > rest not. the ones that are not signed are due to the peer not > negotiating bgpsec, or that one or the other is configured to not have > the peering be bgpsec. I bet with a distant view of one ASN (or all ASN) you could tell, over time, whom the ASN peers with via 'bgpsec' vs 'bgp'. You MAY choose to do some policy stuff that says: "ASN X, Y, Z seem to always do bgpsec with +XX% of their peers in my view of them... so only accept routes originated by these ASN if the routes arrive on bgpsec-enabled peerings." This seems dangerous, today anyway, but maybe tomorrow it'd be more feasible? I also don't know that you could easily tell: "the router" vs "the asn", because as you get further away on the network your entrypoint (and whom in that ASN you hear routes FROM) to the remote ASN is less guaranteed. > and it's way too late here for me to do the necessary deep dive into > draft-ietf-sidr-bgpsec-pki-profiles-18.txt to know if i can definitively > identify a router, especially as one router can have multiple ASs and > therefore multiple certs and therefore multiple skis. > > maybe someone on the us beast coast has had enough coffee to hit me with > a clue by four when i wake. > > randy From nobody Mon Jan 2 17:37:54 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4E11293F3; Mon, 2 Jan 2017 17:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 8VNXcXecPYYd; Mon, 2 Jan 2017 17:37:47 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 8056A126CD8; Mon, 2 Jan 2017 17:37:47 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cOE2n-0001NH-AA; Tue, 03 Jan 2017 01:37:41 +0000 Date: Tue, 03 Jan 2017 10:37:38 +0900 Message-ID: From: Randy Bush To: Chris Morrow In-Reply-To: References: <148336377615.21819.15119186800162780376.idtracker@ietfa.amsl.com> <563AAA29-82F7-4202-8A54-855CD7702595@kuehlewind.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Mirja Kuehlewind , The IESG , sidr wg list Subject: Re: [sidr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-sidr-bgpsec-ops-12=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 01:37:48 -0000 ok, i have had coffee. as a bif gedanken experiment, posit a global registry where r0 can say "i can speak bgpsec." i am a distant r1 and receive an unsigned path with r0 in it. o did someone before r0 on the path not speak bgpsec, so the path was never signed? o did someone between us not speak bgpsec, so the path was stripped? o was there a monkey in the middle? i think we did discuss this problem space, and decided that, as long as we allow islands of partial deployment, and therefore path stripping, the monkey is on our back. we might have been wrong in this; but even with coffee i do not see a way out. and i do not think the idea of partial path signing, r0 signing a received unsigned path, would have helped a lot. it is not clear to me that this is a space where the ops doc can help much. i am open to ideas. randy From nobody Mon Jan 2 22:10:42 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8A91294C5; Mon, 2 Jan 2017 22:10:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roni Even To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148342384112.21835.5114992888706304694.idtracker@ietfa.amsl.com> Date: Mon, 02 Jan 2017 22:10:41 -0800 Archived-At: Cc: draft-ietf-sidr-rpki-oob-setup.all@ietf.org, ietf@ietf.org, sidr@ietf.org Subject: [sidr] Review of draft-ietf-sidr-rpki-oob-setup-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 06:10:41 -0000 Reviewer: Roni Even Review result: Ready I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-sidr-rpki-oob-setup-05 Reviewer: Roni Even Review Date:2017-1-3 IETF LC End Date: 2017–1-10 IESG Telechat date: Summary: This draft is ready for publication as a standard track RFC. Major issues: Minor issues: Nits/editorial comments: From nobody Mon Jan 2 23:17:39 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC96129457 for ; Mon, 2 Jan 2017 23:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 gHN-oThkWIsV for ; Mon, 2 Jan 2017 23:17:36 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0124.outbound.protection.outlook.com [23.103.201.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22162129405 for ; Mon, 2 Jan 2017 23:17:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zsrhnBw9suC6qx0maysEyJMqhustbPOw77Z/KO62vhc=; b=J1q2vZNVyD5+XTJJNN0FrVRmjjxT/p95OYJKL5cqC4oiQAm6qzzbQTutTKqaxbqVDfj28CX2i/xRrogVr+kD7G6N08PxMnOYxkN0AEMTj9ebJxg6bxKdJlT1Imlr/cr38lvyXCAzbeRB7udBewrnRRbFnO3jXH0aF78GY21lXH8= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0448.namprd09.prod.outlook.com (10.161.252.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Tue, 3 Jan 2017 07:17:33 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0817.009; Tue, 3 Jan 2017 07:17:33 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Randy Bush Thread-Topic: [sidr] Confederations and Private ASNs (WAS: AD Review of draft-ietf-sidr-bgpsec-protocol-18) Thread-Index: AQHSUmenE2EHhTbiU0q7IXrD4ZYx2aEfNZ3QgAB0ygCABtAc/A== Date: Tue, 3 Jan 2017 07:17:32 +0000 Message-ID: References: <7055D209-5BF7-4B5D-A675-356CD2CBFF4D@cisco.com> , In-Reply-To: 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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.219.133] x-ms-office365-filtering-correlation-id: 6d6b2d87-9cf7-4242-0053-08d433a8960e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0448; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0448; 7:Ds8dV/MVZmF21C0ALz2jgbxgIpyhlLxne5mpF28tKFlFwbU2XeIzSGWFfWlYywlQpaz5TcSfwn6sNIkC+jCHVw4DoSC1DPXFO8Sc9NSYvCT6YWFxQM7UTsmdJUfP7cpY78QHiaX5e6KUHQ+NLM6In4OoHSU7ZV9EsImxM9Z3c4fjY1YGC+JV8FB5PVOxL9/juYiKGvGvvvYhDOOeXnUIVhm5MFvkJ1LN56p7lkqGulpnkoCXX9dvgLCIi2Q0hthkfDGAgwMGPgAi+l24IGHvhl5RuKKb/uUp4JLetGKAlhJKFPSS+YWSrgXQ4qilowq74wJyWMYvBOuc0g3pKlByPwEYlJF7EXgVCjXsaCJaqOiA/CavFW2+GfukkToJh8n+oByJR8MB2VIldD0tQSUAHzYYYHnryPeEXonZZdaYaxLwEVRBDXzm0/OmfdETHNEUZpXtBUcXPt+4N13scgxeMA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:DM2PR09MB0448; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0448; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39840400002)(39450400003)(377454003)(189002)(199003)(81166006)(38730400001)(5660300001)(6506006)(110136003)(81156014)(99286003)(92566002)(3280700002)(8936002)(3660700001)(55016002)(189998001)(101416001)(7696004)(54906002)(6916009)(2900100001)(33656002)(66066001)(50986999)(25786008)(106116001)(102836003)(86362001)(9686002)(2950100002)(97736004)(68736007)(2906002)(54356999)(7736002)(230783001)(122556002)(229853002)(74316002)(305945005)(77096006)(105586002)(106356001)(6116002)(76176999)(8676002)(6436002)(3846002)(4326007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0448; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2017 07:17:32.8793 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0448 Archived-At: Cc: sidr wg list Subject: Re: [sidr] Confederations and Private ASNs (WAS: AD Review of draft-ietf-sidr-bgpsec-protocol-18) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 07:17:38 -0000 >From: Randy Bush >Sent: Thursday, December 29, 2016 6:02 PM >that is not the core of the problem. the bgpsec protocol doc has to >specifically say that the public AS upon receiving the update from the >private AS > o if the private signed to the public, public should check sig, then > strip it and then might sign as the originating AS or might not. on > what criteria does it decide? > o if the private did not sign, the public might sign or it might not. > on what criteria does it decide? >as i said, once you burn that in, i will hack the ops doc Does this change (in Section 7 in the document) work for you? [OLD] It is possible that a stub customer of an ISP employs a private AS number. Such a stub customer cannot publish a ROA in the global RPKI for the private AS number and the prefixes that they use. Also, the stub customer cannot become a BGPsec speaker. If a BGPsec speaker in the ISP's AS receives an announcement for a prefix from the stub customer and chooses to propagate it to BGPsec peers, then it MUST strip the private AS and re-originate the prefix. In order to do this, the prefix MUST have a ROA authorizing the ISP's AS to originate it. [NEW] It is possible that a stub customer of an ISP employs a private AS number. Such a stub customer cannot publish a ROA in the global RPKI for the private AS number and the prefixes that they use. Also, the global RPKI cannot support private AS numbers for issuing router certificates for eBGP routers in the private AS. For interactions between the stub customer and the ISP, the following two scenarios are possible: 1. The stub customer sends an unsigned BGP update for a prefix to the ISP's AS. An edge BGPsec speaker in the ISP's AS may choose to propagate the prefix to its non-BGPsec and BGPsec peers. If so, the ISP's edge BGPsec speaker MUST strip the AS_PATH with the private AS number, and then (a) re-originate the prefix without any signatures towards its non-BGPsec peer and (b) re-originate the prefix including its own signature towards its BGPsec peer. In both cases (i.e. (a) and (b)), the prefix MUST have a ROA in the global RPKI authorizing the ISP's AS to originate it. 2. The ISP and the stub customer may use a local RPKI repository (using a mechanism such as described in [I-D.ietf-sidr-slurm]). Then there can be a ROA for the prefix originated by the sub AS, and the eBGP speaker in the stub AS can be a BGPsec speaker having a router certificate, albeit the ROA and router certificate are valid only locally. With this arrangement, the stub AS sends a signed update for the prefix to the ISP's AS. An edge BGPsec speaker in the ISP's AS validates the update using RPKI data based the local RPKI view. Further, it may choose to propagate the prefix to its non-BGPsec and BGPsec peers. If so, the ISP's edge BGPsec speaker MUST strip the Secure_Path and the Signature Segment received from the stub AS with the private AS number, and then (a) re-originate the prefix without any signatures towards its non-BGPsec peer and (b) re-originate the prefix including its own signature towards its BGPsec peer. In both cases (i.e. (a) and (b)), the prefix MUST have a ROA in the global RPKI authorizing the ISP's AS to originate it. Sriram =20 =20 From nobody Tue Jan 3 00:39:16 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E936B129429; Tue, 3 Jan 2017 00:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_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 kc9fzKPgyB3i; Tue, 3 Jan 2017 00:39:10 -0800 (PST) Received: from gir.theapt.org (gir.theapt.org [IPv6:2001:470:1f0b:8b2::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E825129417; Tue, 3 Jan 2017 00:39:10 -0800 (PST) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id 92EE9788E9; Tue, 3 Jan 2017 09:39:08 +0100 (CET) Date: Tue, 3 Jan 2017 09:39:07 +0100 From: Peter Hessler To: Randy Bush Message-ID: <20170103083907.GE5069@gir.theapt.org> References: <148336377615.21819.15119186800162780376.idtracker@ietfa.amsl.com> <563AAA29-82F7-4202-8A54-855CD7702595@kuehlewind.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Chris Morrow , Mirja Kuehlewind , The IESG , sidr wg list Subject: Re: [sidr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-sidr-bgpsec-ops-12=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 08:39:12 -0000 On 2017 Jan 03 (Tue) at 10:37:38 +0900 (+0900), Randy Bush wrote: :ok, i have had coffee. : :as a bif gedanken experiment, posit a global registry where r0 can say :"i can speak bgpsec." i am a distant r1 and receive an unsigned path :with r0 in it. : o did someone before r0 on the path not speak bgpsec, so the path was : never signed? : o did someone between us not speak bgpsec, so the path was stripped? : o was there a monkey in the middle? : :i think we did discuss this problem space, and decided that, as long as :we allow islands of partial deployment, and therefore path stripping, :the monkey is on our back. we might have been wrong in this; but even :with coffee i do not see a way out. : :and i do not think the idea of partial path signing, r0 signing a :received unsigned path, would have helped a lot. : :it is not clear to me that this is a space where the ops doc can help :much. i am open to ideas. : :randy : I'm currently not using bgpsec (or rpki for that matter). BUT, if there was no path to go back, I would never ever use it. Destroying my ASN because I wasn't ready to migrate is a straight-up No Go(tm). Mistakes will be made. Rolling back will happen. Preventing rolling back will kill the baby and will guarentee this will never be rolled out. -- Help fight continental drift. From nobody Tue Jan 3 06:26:39 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187771295BD; Tue, 3 Jan 2017 06:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 1FmzpxWRFZ0j; Tue, 3 Jan 2017 06:26:36 -0800 (PST) Received: from relay.kvm02.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF2901294C1; Tue, 3 Jan 2017 06:26:36 -0800 (PST) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id AC5023FFD8; Tue, 3 Jan 2017 14:26:34 +0000 (UTC) Received: from donkey.her.corp.google.com.ops-netman.net (unknown [104.132.12.94]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 98D16BBC9521; Tue, 3 Jan 2017 14:26:34 +0000 (UTC) Date: Tue, 03 Jan 2017 09:26:33 -0500 Message-ID: From: Chris Morrow To: Peter Hessler In-Reply-To: <20170103083907.GE5069@gir.theapt.org> References: <148336377615.21819.15119186800162780376.idtracker@ietfa.amsl.com> <563AAA29-82F7-4202-8A54-855CD7702595@kuehlewind.net> <20170103083907.GE5069@gir.theapt.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Chris Morrow , Mirja Kuehlewind , The IESG , sidr wg list Subject: Re: [sidr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-sidr-bgpsec-ops-12=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 14:26:38 -0000 At Tue, 3 Jan 2017 09:39:07 +0100, Peter Hessler wrote: > > I'm currently not using bgpsec (or rpki for that matter). BUT, if there > was no path to go back, I would never ever use it. Destroying my ASN > because I wasn't ready to migrate is a straight-up No Go(tm). yup, I think this was part of the original thought process for bgpsec. > Mistakes will be made. Rolling back will happen. Preventing rolling > back will kill the baby and will guarentee this will never be rolled > out. one (me) hopes that we can rollout over time, and make progress on a better network. From nobody Tue Jan 3 07:20:55 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD4C12961E; Tue, 3 Jan 2017 07:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 XBE9b7ZaYlOq; Tue, 3 Jan 2017 07:20:52 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 745AC129616; Tue, 3 Jan 2017 07:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5426; q=dns/txt; s=iport; t=1483456852; x=1484666452; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gKGIOYP/gIVKQyoAMUfwPLdfN40MI/7GGQfeyEp5PjA=; b=ES3pLJ9jaaBAErOBL5et0+uOKURawoijXbXfkaBLGNkfjAHq1JN7hU2v ANpa98i5zHCOPiFwdM/kRMLr4NKEj7V6oqcoYtgGR3BJmjjt2zP1oq3Dk D8BoweDgIgYugay0XrtdZ3IpyI/MI4caAafSWeRr4VjMmFeAZSEEMWfR5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9AQDMv2tY/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnFGAQEBAQEfX4EMB41QpDlQgkmCD4IIhiICGoEtPxQBAgEBAQE?= =?us-ascii?q?BAQFiKIRpBiNWEAIBCD8DAgICMBQGCwIEAQ0FiHCvEYIlK4oXAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYZFggKCX4dKLYIwBZUJhXQBkT2QVZI8AR84gSo8AYQIgUZ?= =?us-ascii?q?yhzGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,455,1477958400"; d="scan'208,217";a="189742947" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Jan 2017 15:20:51 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v03FKpji002123 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Jan 2017 15:20:51 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 3 Jan 2017 09:20:50 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 3 Jan 2017 09:20:50 -0600 From: "Alvaro Retana (aretana)" To: Randy Bush , Chris Morrow Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-sidr-bgpsec-ops-12:_(with_COMMENT)?= Thread-Index: AQHSZPxE+x5HO3zeTEq/vZ3Txn1KiqEll4IAgAAEdgCAABnegIAAl1KAgAARYgCAAJIvAA== Date: Tue, 3 Jan 2017 15:20:50 +0000 Message-ID: <9A40617C-EB4E-40FD-A8D2-65C292BAC08A@cisco.com> References: <148336377615.21819.15119186800162780376.idtracker@ietfa.amsl.com> <563AAA29-82F7-4202-8A54-855CD7702595@kuehlewind.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: multipart/alternative; boundary="_000_9A40617CEB4E40FDA8D265C292BAC08Aciscocom_" MIME-Version: 1.0 Archived-At: Cc: Mirja Kuehlewind , The IESG , sidr wg list Subject: Re: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-bgpsec-ops-12=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 15:20:54 -0000 --_000_9A40617CEB4E40FDA8D265C292BAC08Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkhDQoNCkkgZG9u4oCZdCB0aGluayB0aGVyZeKAmXMgYW55dGhpbmcgdG8gYmUgZG9uZSwgYmVz aWRlcyB0aGUgZ3VpZGFuY2UgYWxyZWFkeSBpbiB0aGUgZHJhZnQgYWJvdXQgcGF0aCBwcmVmZXJl bmNlOiBwcmVmZXIgVmFsaWQgcGF0aHMuICBJZiB0aGUgdmFsaWRpdHkgc3RhdGUgY2hhbmdlcyBs YXRlciwgdGhlbiBpdCBiZWNvbWVzIGEgbG9jYWwgcG9saWN5IHRvIHVzZSBvciBub3QuDQoNCkFs dmFyby4NCg0KT24gMS8yLzE3LCA4OjM3IFBNLCAiUmFuZHkgQnVzaCIgPHJhbmR5QHBzZy5jb208 bWFpbHRvOnJhbmR5QHBzZy5jb20+PiB3cm90ZToNCg0KaXQgaXMgbm90IGNsZWFyIHRvIG1lIHRo YXQgdGhpcyBpcyBhIHNwYWNlIHdoZXJlIHRoZSBvcHMgZG9jIGNhbiBoZWxwDQptdWNoLiAgaSBh bSBvcGVuIHRvIGlkZWFzLg0KDQo= --_000_9A40617CEB4E40FDA8D265C292BAC08Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3Rl eHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNv SW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5IaSE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5JIGRvbuKAmXQg dGhpbmsgdGhlcmXigJlzIGFueXRoaW5nIHRvIGJlIGRvbmUsIGJlc2lkZXMgdGhlIGd1aWRhbmNl IGFscmVhZHkgaW4gdGhlIGRyYWZ0IGFib3V0IHBhdGggcHJlZmVyZW5jZTogcHJlZmVyIFZhbGlk IHBhdGhzLiZuYnNwOyBJZiB0aGUgdmFsaWRpdHkgc3RhdGUgY2hhbmdlcyBsYXRlciwgdGhlbiBp dCBiZWNvbWVzIGEgbG9jYWwNCiBwb2xpY3kgdG8gdXNlIG9yIG5vdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj5BbHZhcm8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEvMi8xNywgODozNyBQTSwgJnF1b3Q7UmFuZHkgQnVz aCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJhbmR5QHBzZy5jb20iPnJhbmR5QHBzZy5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtp dC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+aXQgaXMgbm90 IGNsZWFyIHRvIG1lIHRoYXQgdGhpcyBpcyBhIHNwYWNlIHdoZXJlIHRoZSBvcHMgZG9jIGNhbiBo ZWxwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPm11Y2guJm5ic3A7Jm5ic3A7aSBhbSBv cGVuIHRvIGlkZWFzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_9A40617CEB4E40FDA8D265C292BAC08Aciscocom_-- From nobody Tue Jan 3 07:25:08 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1F0129A0D for ; Tue, 3 Jan 2017 07:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 gn87ygmAmxVn for ; Tue, 3 Jan 2017 07:25:02 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93250129A0C for ; Tue, 3 Jan 2017 07:25:01 -0800 (PST) Received: (qmail 20035 invoked from network); 3 Jan 2017 16:24:59 +0100 Received: from p5dec2e6d.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.46.109) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 3 Jan 2017 16:24:59 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <9A40617C-EB4E-40FD-A8D2-65C292BAC08A@cisco.com> Date: Tue, 3 Jan 2017 16:24:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <35FB8869-1BCE-4C3B-9546-2581EC79F868@kuehlewind.net> References: <148336377615.21819.15119186800162780376.idtracker@ietfa.amsl.com> <563AAA29-82F7-4202-8A54-855CD7702595@kuehlewind.net> <9A40617C-EB4E-40FD-A8D2-65C292BAC08A@cisco.com> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Chris Morrow , The IESG , sidr wg list Subject: Re: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-bgpsec-ops-12=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 15:25:04 -0000 Agreed. I guess you could in addition be very clear that a router that = once negotiated (and/or send) BGPsec (attributes) should not be expected = to always do so. This is implicitly said already, so please decide on = your own if you=E2=80=99d like to add anymore text. Thanks! Mirja > Am 03.01.2017 um 16:20 schrieb Alvaro Retana (aretana) = : >=20 > Hi! > =20 > I don=E2=80=99t think there=E2=80=99s anything to be done, besides the = guidance already in the draft about path preference: prefer Valid paths. = If the validity state changes later, then it becomes a local policy to = use or not. > =20 > Alvaro. > =20 >> On 1/2/17, 8:37 PM, "Randy Bush" wrote: >> =20 >> it is not clear to me that this is a space where the ops doc can help >> much. i am open to ideas. >> =20 From nobody Tue Jan 3 07:42:02 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB09A129653; Tue, 3 Jan 2017 07:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 9gZ9EiTVcNpB; Tue, 3 Jan 2017 07:41:57 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0108.outbound.protection.outlook.com [23.103.200.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23B8B129639; Tue, 3 Jan 2017 07:41:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZNOdT9BotqzMiJra01RID5zoKTJ7j79LtI+5ZgqYM7E=; b=AhanXHVKH+gpVKCH3ZysYwuc0zq/xZDLxIfeQYPDWFTUpjWkl8FFHkBqebhng6B8FJjMvJ1CAyaD20KfgkjNIzte5sJQgA09zBduRkNGy24YB46YBoqNU2sym5FsnToHcS/x9Xe+bTcpwtGDZv5olXgwZr7CZWVQF6IrajY/Fy4= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Tue, 3 Jan 2017 15:41:54 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0817.009; Tue, 3 Jan 2017 15:41:54 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "Mirja Kuehlewind (IETF)" , Randy Bush , Peter Hessler Thread-Topic: =?Windows-1252?Q?[sidr]_Mirja_K=FChlewind's_No_Objection_on_draft-ietf-si?= =?Windows-1252?Q?dr-bgpsec-ops-12:_(with_COMMENT)?= Thread-Index: AQHSZPxJO8Vpc8AXSkOM8RcY2nC42KElMu0AgAAEdgCAAaC6QQ== Date: Tue, 3 Jan 2017 15:41:53 +0000 Message-ID: References: <148336377615.21819.15119186800162780376.idtracker@ietfa.amsl.com> , <563AAA29-82F7-4202-8A54-855CD7702595@kuehlewind.net> In-Reply-To: <563AAA29-82F7-4202-8A54-855CD7702595@kuehlewind.net> 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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.222.94] x-ms-office365-filtering-correlation-id: 7bbe1cec-4d77-45e8-3f2d-08d433ef0b1e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0446; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 7:PQOQgcYJySM7TKvA7oqcXVWcGBrPmeflNzT0hF3zZP7GTCsNST7ab2qtWnkvEqKlwyoryCW0qi6LGeIHIfquEGX6Tr349RMNhs14oJsipSy4CKi+RBrq9MymcS2TQ85qWyroMXuVgzdacxmd8ptk6768CyLrjzvWd+YMZ2O0mU2n/2R8F4DU9smIljVxqpS52qETUBkCR7z7A2EceZe5VR37TOtG1hNxXT2r4oMEOKBV7I+Ez4dKVl6mCCaTKWf1G+KPlMq5XTxALqtwEJVTHm9u0S3Q54zjK4OwAXvTVk9bDu+N4ZqRoz+NXRPVgbAl1RvgN/I0+BWwaXq2FDo1fIQiK3ktKNpURxXnZs0eHGBCYf+GkK2/GBlX39fPwatRxWo1I4MTxBla5N9ddI1z+MES8sNPzooS04Hi5cC7Eo5aB2DnmTun2a+R6rQ/CBdSKp/GsIkokvphVHA8MBpvJw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123558021)(20161123564025)(20161123562025)(6072148); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39840400002)(39450400003)(199003)(189002)(5660300001)(74316002)(101416001)(3660700001)(66066001)(3280700002)(5890100001)(8936002)(122556002)(4326007)(2950100002)(6506006)(9686002)(25786008)(77096006)(81156014)(54356999)(6436002)(99286003)(81166006)(68736007)(7696004)(50986999)(54906002)(38730400001)(105586002)(229853002)(86362001)(76176999)(55016002)(224313004)(106356001)(224303003)(106116001)(6116002)(33656002)(230783001)(7736002)(305945005)(2906002)(92566002)(5001770100001)(3846002)(2900100001)(97736004)(102836003)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2017 15:41:53.9011 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0446 Archived-At: Cc: Chris Morrow , "sidr-chairs@ietf.org" , The IESG , "draft-ietf-sidr-bgpsec-ops@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] =?windows-1252?q?Mirja_K=FChlewind=27s_No_Objection_on_dra?= =?windows-1252?q?ft-ietf-sidr-bgpsec-ops-12=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 15:41:59 -0000 Hi Mirja, >I actually might be mixing this up with some discussion about DNSsec a whi= le ago, where the problem was that once enable others will remember that it= was supported and will not accept non secured requests anymore. >But as we are talking about this, could there be a similar case here, wher= e a router is known to support BGPsec and others would ignore/drop non-sign= ed announcements? (Sorry if that=92s all discussed in the protocol doc; in = this case just ignore my questions ;-); didn=92t review the protocol spec y= et but it=92s the next doc on my list; probably should have read that one f= irst=85) In BGPsec peering session, it is allowed to send signed updates for some pr= efixes and=20 unsigned updates for other prefixes. This is necessary for backward compati= bility and incremental deployment.=20 In this scenario, AS1-----BGP(unsigned)-----------------AS3---------------BGPsec(signed)-----= ---AS4=20 | AS2----BGPsec(signed)-------------------- AS3 forwards to AS4 unsigned updates originated from AS1=20 and also forwards signed updates originated from AS2. Just because an AS is known to support BGPsec, it is not required that it m= ust=20 send only signed updates.=20 On the receive side, it would be purely a matter of local policy to prefer = a signed update=20 over an unsigned update for the same prefix or how to treat an unsigned upd= ate in path selection process, etc. =20 Excerpt from Section 4.1 in the BGPsec protocol draft: =20 If a BGPsec router has received only a non-BGPsec update message containing the AS_PATH attribute (instead of the BGPsec_Path attribute) from a peer for a given prefix, then it MUST NOT attach a BGPsec_Path attribute when it propagates the update message. =20 ........ Conversely, if a BGPsec router has received a BGPsec update message (with the BGPsec_Path attribute) from a peer for a given prefix and it chooses to propagate that peer's route for the prefix, then it SHOULD propagate the route as a BGPsec update message containing the BGPsec_Path attribute. Does this answer your question? Thanks. Sriram= From nobody Tue Jan 3 08:12:06 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFB4129579; Tue, 3 Jan 2017 08:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 3XJUs2qcdRD2; Tue, 3 Jan 2017 08:11:49 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0098.outbound.protection.outlook.com [23.103.200.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D5B12965F; Tue, 3 Jan 2017 08:11:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XnsczztWmJk7EBOTu2lEMiwpL7OhqtnfQJIGi1T7wZo=; b=V1p2ziZ0oUHxz0d9XxO/2uVvNewAQaSjyAGWjoe9tgWDV97yiaZKJxNlPyH7+zxPdY/xFJFzcoPaXzhCV3cvDkUi3HWU1n60YyTjvI2vVTNItY3nDDDId6zPauj6y1FeXRMTMiUomMhhvwdkGr9KQdJI6cyCKZLCHQnehEc/EfY= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0448.namprd09.prod.outlook.com (10.161.252.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Tue, 3 Jan 2017 16:11:47 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0817.009; Tue, 3 Jan 2017 16:11:48 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Chris Morrow , Peter Hessler Thread-Topic: =?iso-8859-1?Q?[sidr]_Mirja_K=FChlewind's_No_Objection_on_draft-ietf-sidr?= =?iso-8859-1?Q?-bgpsec-ops-12:_(with_COMMENT)?= Thread-Index: AQHSZPxJO8Vpc8AXSkOM8RcY2nC42KElMu0AgAAEdgCAABnegIAAl1KAgAARYgCAAHXDgIAAYRKAgAAafr0= Date: Tue, 3 Jan 2017 16:11:47 +0000 Message-ID: References: <148336377615.21819.15119186800162780376.idtracker@ietfa.amsl.com> <563AAA29-82F7-4202-8A54-855CD7702595@kuehlewind.net> <20170103083907.GE5069@gir.theapt.org>, In-Reply-To: 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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.222.94] x-ms-office365-filtering-correlation-id: baa1f1df-a96a-4b5f-7832-08d433f3384d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0448; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0448; 7:jYx+qioIA0b8PYkdlxUGl60THEZcUWIYhuW13PyU7OjdqiOxOJHgr8hsL6CO8bFohBsJ3Xt5o2eNESACOBR0UNct+6BawHQApmDZoabk4MYpjWF8CsdswxlmVNQg7WCzNpKopdHUmw6guOgc+Zuzzo01ZwxKizLmBY5L/Fy7mPRvRb6rBEsckV9htPjoriZndFukhAw92dRT4Ri9dS+XsMcmtyHUnTBHvy9HoD+nFn0yr1RZcdLOQnkGMq7QIb33qg8XWm9dOPAjludNJCC6yH8kZGPkituXO0LLktsFL1CSd1D3t0gk2uJzC0+xl1dTojAb0szv4u7VSorQnSh5FERPyaakoYkDyMudSlgQrKlZDD4mC8NG3yQ/IOAb7drMU9FMyv1uIVX23hChwGXGYKJdVM7bzUO7aho8tjQZgavPofu6VW6WckZuysYegUrSY1q3AdLmw1M7/AOkEq3JPw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:DM2PR09MB0448; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0448; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39860400002)(39840400002)(39450400003)(24454002)(189002)(199003)(38730400001)(81166006)(6506006)(5660300001)(81156014)(3280700002)(8936002)(92566002)(99286003)(3660700001)(55016002)(189998001)(2900100001)(101416001)(5001770100001)(7696004)(54906002)(224303003)(33656002)(66066001)(50986999)(25786008)(106116001)(102836003)(86362001)(9686002)(2950100002)(97736004)(68736007)(2906002)(224313004)(54356999)(7736002)(230783001)(229853002)(122556002)(305945005)(74316002)(77096006)(105586002)(106356001)(6116002)(6436002)(76176999)(3846002)(4326007)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0448; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2017 16:11:47.7890 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0448 Archived-At: Cc: Mirja Kuehlewind , The IESG , sidr wg list Subject: Re: [sidr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-sidr-bgpsec-ops-12=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 16:11:54 -0000 Hi Peter, >At Tue, 3 Jan 2017 09:39:07 +0100, >Peter Hessler wrote: >> >> I'm currently not using bgpsec (or rpki for that matter). BUT, if there >> was no path to go back, I would never ever use it. Destroying my ASN >> because I wasn't ready to migrate is a straight-up No Go(tm). >yup, I think this was part of the original thought process for bgpsec. A BGP speaker always has the option to drop a BGPsec session, and send a new BGP open request without the BGPsec capability (Section 2.2 in the protocol spec document).=20 Please also see my response to Mirja. Thank you. Sriram= From nobody Tue Jan 3 08:12:59 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F50129664 for ; Tue, 3 Jan 2017 08:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, 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 2gLIsTm0a9_1 for ; Tue, 3 Jan 2017 08:12:54 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 88602129665 for ; Tue, 3 Jan 2017 08:12:52 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id d45so244417860qta.1 for ; Tue, 03 Jan 2017 08:12:52 -0800 (PST) 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=EVCzkpFkXVxAAqe3J+2UkWE9YYvJcIzgY6rDbUyF8oM=; b=csmw5CWMZvJlzd2V8Zxts+Ee/zymSQAGTvrFHSjrWlaIND2Gj3mR4z3umFSE3kJtZ5 gvhUpKp9hCEJRSiBleB88Otmsbp1sbNS1K+6fUjTqgUu0MuJfF2WCwb6KlVrNXghbl6e xpnYViAOAjwJRq/Y/3evjygZ8+QAxspg+tauA= 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=EVCzkpFkXVxAAqe3J+2UkWE9YYvJcIzgY6rDbUyF8oM=; b=SXDSqHolDxNg1h0Yh2IxukTVENAnQeFWSuSdjNEd1mE4Aj1fVJqZmkgROmF5j8b1sq 4m1pF/jQtrFUPPuAMXYWpsmUS3xlTlhj51u2V5bHDaQYf2nQmCqcVyb2HM6PEe/z0w8v av4VlTSbIoBK+jJQYjQGipcqd7hmI06AUSGxM+I0Gu7Xl5d6wPjqcFcbYeaB2yu2UG+z AFnRNPJyCCG2a6FwBB56ZfNN0R9DlhP1ZRVhfLF4i5FmNbKw4qLZMPOg58nwe0p2tlut K9ao5ab5C5P/Yy+pAsKrokChBbeKTr40pgdf5HoKb2uJelbkWTlrH4hW+MzQzDT8D4lA a4cA== X-Gm-Message-State: AIkVDXJFAgDMLMxSXyD7iiwnrapxW3+g3Pyuo+LuJ8IQFay/SlctSOSl9JZN7gIRqM7fsA== X-Received: by 10.237.62.153 with SMTP id n25mr65305661qtf.50.1483459971490; Tue, 03 Jan 2017 08:12:51 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id i41sm44019203qtc.18.2017.01.03.08.12.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Jan 2017 08:12:50 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <148328799488.25220.17994465220699555250.idtracker@ietfa.amsl.com> Date: Tue, 3 Jan 2017 11:12:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148328799488.25220.17994465220699555250.idtracker@ietfa.amsl.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sidr@ietf.org, draft-ietf-sidr-bgpsec-pki-profiles.all@ietf.org, secdir@ietf.org Subject: Re: [sidr] Review of draft-ietf-sidr-bgpsec-pki-profiles-19 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 16:12:55 -0000 Yaron, Thanks for the review. > On Jan 1, 2017, at 11:26, Yaron Sheffer wrote: >=20 > Reviewer: Yaron Sheffer > Review result: Has Nits >=20 > * 3.1.1: The serial number in RFC 6487 is still a real, unique serial > number that uniquely identifies the certificate. Here it is used as > something other than a serial number, which is explicitly NOT unique, > and the CA is left to decide how to make it unique in the face of > potentially repeating BGP IDs. If this is not a real issue (e.g. > because duplicate IDs are rare and never within a RIR), please say > so. As Rob pointed out this paragraph is talking about the serial number = naming attribute. Maybe something like: r/only two attributes/only two naming attributes and r/common name and serial number/common name (i.e., X520CommonName) and = serial number (i.e., X520SerialNumber)=20 People ought to them be able to track down the definitions. > * 3.2: earlier we said that Basic Constraints must not be included in > the EE cert. Now we are saying that only a particular boolean flag > must not be honored when processing the Cert Request. What happens if > Basic Constraints is included in the Cert Request but with other > flags? The CA is ultimately the one who decides what gets issued. A good CA = would know to only issue properly formatted BGPsec certificates either = by ignoring the improperly requested =E2=80=9Cfeature" or rejecting it = outright. Since these CAs really aren=E2=80=99t open CAs then the CA = ought not get caught off-guard with requests. > * 3.3: ID.sidr-rfc6485bis -> RFC 7935 drat I missed one. > * 6: in the paragraph that discusses hash functions, please spell out > the names of the two key identifiers, because I cannot determine what > they are from the document. Ack they=E2=80=99re the key identifiers in the cert: Subject Key = Identifier and Issuer Key Identifier=20 r/two key identifier extensions./two key identifier extensions (i.e., = Subject Key Identifier and Issuer Key Identifier) spt= From nobody Tue Jan 3 08:15:21 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4595129A65; Tue, 3 Jan 2017 08:15:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dale Worley To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148346011373.28055.14231244831041167421.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2017 08:15:13 -0800 Archived-At: Cc: draft-ietf-sidr-bgpsec-pki-profiles.all@ietf.org, ietf@ietf.org, sidr@ietf.org Subject: [sidr] Review of draft-ietf-sidr-bgpsec-pki-profiles-19 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 16:15:13 -0000 Reviewer: Dale Worley Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-sidr-bgpsec-pki-profiles-19 Reviewer: Dale R. Worley Review Date: 3 Jan 2017 IETF LC End Date: 19 Dec 2016 IESG Telechat date: 5 Jan 2017 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. The draft is much improved relative to the Gen-ART review of -18, but a few items remain. 3.1.1. Subject However, each certificate issued by an individual CA MUST contain a Subject name that is unique to that CA context. E-mail from Sean Turner on 22 Dec 2016 says: I think this is just a case of a missing "CA" in front of the word "context" so tweaking it to: ".... that is unique to that CA context". The certs only need to be unique on a per CA basis the subject name does not need to be unique across the whole of the RPKI. The combination of issuer+subject+serial # plus all the parent certs provides the uniqueness. However, there doesn't seem to be a standard meaning of the phrase "CA context". I can't find any occurrences in any RFC or in any I-D other than draft-ietf-trans-threat-analysis-NN. It seems to me that the best solution is to put a cleaned-up version of Sean's statement "The combination of issuer+subject+serial # plus all parent certs provides the uniqueness." into the draft, as that is admirably clear. (Unless, of course, there is a standard PKI phrase for that requirement, in which case that could be used.) For instance: However, the combination of subject name, serial number, issuer, and certification path must be globally unique. 3.3. BGPsec Router Certificate Validation The validation procedure used for BGPsec Router Certificates is identical to the validation procedure described in Section 7 of [RFC6487] (and any RFC that updates this procedure), as modified below. For example, in step 3: "The certificate contains all field that must be present" - refers to the fields that are required by this specification. This picks up the changes from Sean Turner's e-mail of 22 Dec 2016 except it omits changing "that updates this procedure" to "that updates that procedure", which seems to me to necessary to make the wording correct. step 3: "The certificate contains all field that must be present" This doesn't match the text in RFC 6487, despite claiming to be quoted: s/all field/all fields/ and s/must/MUST/. 7. IANA Considerations No IANA allocations are request of IANA, ... I think this should be "No IANA allocations are requested of IANA", or probably better "No allocations are requested of IANA". E-mail from Sean Turner on 22 Dec 2016 says "Alvaro had a similar comment on the IANA considerations and he suggested the first option.", but no change has been made. Dale From nobody Tue Jan 3 13:47:48 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13371297BC; Tue, 3 Jan 2017 13:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 f9yw6BKFUoCY; Tue, 3 Jan 2017 13:47:41 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909231297A7; Tue, 3 Jan 2017 13:47:06 -0800 (PST) Received: from [10.0.0.13] ([79.177.158.66]) by mail.gmx.com (mrgmx003 [212.227.17.184]) with ESMTPSA (Nemesis) id 0LztHH-1ccm1M35Od-01546h; Tue, 03 Jan 2017 22:47:04 +0100 To: Sean Turner References: <148328799488.25220.17994465220699555250.idtracker@ietfa.amsl.com> From: Yaron Sheffer Message-ID: Date: Tue, 3 Jan 2017 23:47:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------161B0AC6809EC36B16E83D53" X-Provags-ID: V03:K0:4lgKQNzYkldrkBW6qQ+aO304NoHE21lhQpz/bjrQxrPhX7Ny2f8 KiF5svvaAnF9+3v8KClzqUnhdF16fccd2HdXj9pHWmYToBtk19wfI2+sEqVivYK0cxTFVsG XslK9vyTFSsjFegfaz4lk+4O9zDjE3ed7+4pKc/+VYSmUysF3/MLdcM2bEVgk7CZGsjz9ek WAGqPTWztC+B7d/8veWig== X-UI-Out-Filterresults: notjunk:1;V01:K0:AnUGOv4GaKg=:v6oXwLLAH3iVbvwj9BdU+f TANXek75RjrZ8hLxIqV0rjcrNAzTU4wEzTDDGuavjiw78ay3rTMWPYhWb/tZ9Hnt+p0jioAai Mtk8dfBx94OtpJ7bhzyNBqMmin0DmvY/cD7rNoA+WC3flgFxwZo+9EXrTk3jjaHTVK9yQJx6b TcA2+jcogSHLj7Q4UnSGEms0GM7m6rAVOqHCC71A0jUCxaqiPSTLOUc5J/F8C0smKTX0TvXP4 jDfwQeiHLaKuq7ES8hn9EOSmnBPBYcMGY6/P0SwC5VJBHlFruTpU3hUuybmY8lTzykraRWPWe 2jSCyvw71jJYMUIP7fw+YSzcDo7Y/WpIfDTjek0jA43UCEgNFmmOtpY7+EtzdWzLw5tmVbrXE 9lUkZxETbDy0pQ+x1gubZdKhOGOoX69vR5dhClgpDgwArPFLtcTLQRl0APv+URq1WMSYJc2Y1 7+AJQ1HaCoBG7TiNA38IxSO1K+QvsCTO5FYGt/xEWUrLRNxDm9QY9zXh/VCeex7SweAxzUp2q ELo/bYHLdIYtpXk1nsINtuJsbOts5mhQEVC2Zgoll4/RcKcsYR1FbcwB911+nLaxv02yIdMoi TVPkcZtKXyKT7pXI7VjttR43ZyhrxfJ9RV/dtxwzDHovgnovzWEM9hp4M85y5eowbJXukHFc8 djAv8WJ1y6fWj3S6hkjgC/8mGNHk0yd7QHyIGJPSJoGNvV6vNJHqDzzJRRo6THS9Lded0rqjm IwsCsyEnbKd/9Fim8B5EZgkWoTG7IcTOWAXyrn5lYaMdwc1U4uVf/38bM0uEg2z9qWCRggp4H oh63YDa Archived-At: Cc: sidr@ietf.org, draft-ietf-sidr-bgpsec-pki-profiles.all@ietf.org, secdir@ietf.org Subject: Re: [sidr] Review of draft-ietf-sidr-bgpsec-pki-profiles-19 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 21:47:44 -0000 This is a multi-part message in MIME format. --------------161B0AC6809EC36B16E83D53 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Sean, Please see below. On 03/01/17 18:12, Sean Turner wrote: > Yaron, > > Thanks for the review. > >> On Jan 1, 2017, at 11:26, Yaron Sheffer wrote: >> >> Reviewer: Yaron Sheffer >> Review result: Has Nits >> >> * 3.1.1: The serial number in RFC 6487 is still a real, unique serial >> number that uniquely identifies the certificate. Here it is used as >> something other than a serial number, which is explicitly NOT unique, >> and the CA is left to decide how to make it unique in the face of >> potentially repeating BGP IDs. If this is not a real issue (e.g. >> because duplicate IDs are rare and never within a RIR), please say >> so. > As Rob pointed out this paragraph is talking about the serial number naming attribute. Maybe something like: > > r/only two attributes/only two naming attributes > and > r/common name and serial number/common name (i.e., X520CommonName) and serial number (i.e., X520SerialNumber) > > People ought to them be able to track down the definitions. I'm good with these changes. However, according to Randy's response to my review, the text later on is subtly incorrect (or at least misleading). Router IDs are not globally unique, but the combination of AS Number and Router ID is in fact globally unique. > >> * 3.2: earlier we said that Basic Constraints must not be included in >> the EE cert. Now we are saying that only a particular boolean flag >> must not be honored when processing the Cert Request. What happens if >> Basic Constraints is included in the Cert Request but with other >> flags? > The CA is ultimately the one who decides what gets issued. A good CA would know to only issue properly formatted BGPsec certificates either by ignoring the improperly requested feature" or rejecting it outright. Since these CAs really arent open CAs then the CA ought not get caught off-guard with requests. I'm not sure I understand. Why not give a consistent advice to EEs and CAs, e.g., reject any request that includes any Basic Constraints. > >> * 3.3: ID.sidr-rfc6485bis -> RFC 7935 > drat I missed one. > >> * 6: in the paragraph that discusses hash functions, please spell out >> the names of the two key identifiers, because I cannot determine what >> they are from the document. > Ack theyre the key identifiers in the cert: Subject Key Identifier and Issuer Key Identifier > > r/two key identifier extensions./two key identifier extensions (i.e., Subject Key Identifier and Issuer Key Identifier) Yes. > > spt --------------161B0AC6809EC36B16E83D53 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Sean,

Please see below.


On 03/01/17 18:12, Sean Turner wrote:
Yaron,

Thanks for the review.


On Jan 1, 2017, at 11:26, Yaron Sheffer <yaronf@gmx.com> wrote:

Reviewer: Yaron Sheffer
Review result: Has Nits

* 3.1.1: The serial number in RFC 6487 is still a real, unique serial
number that uniquely identifies the certificate. Here it is used as
something other than a serial number, which is explicitly NOT unique,
and the CA is left to decide how to make it unique in the face of
potentially repeating BGP IDs. If this is not a real issue (e.g.
because duplicate IDs are rare and never within a RIR), please say
so.

As Rob pointed out this paragraph is talking about the serial number naming attribute.  Maybe something like:

r/only two attributes/only two naming attributes
and
r/common name and serial number/common name (i.e., X520CommonName) and serial number (i.e., X520SerialNumber) 

People ought to them be able to track down the definitions.
I'm good with these changes. However, according to Randy's response to my review, the text later on is subtly incorrect (or at least misleading). Router IDs are not globally unique, but the combination of AS Number and Router ID is in fact globally unique.



* 3.2: earlier we said that Basic Constraints must not be included in
the EE cert. Now we are saying that only a particular boolean flag
must not be honored when processing the Cert Request. What happens if
Basic Constraints is included in the Cert Request but with other
flags?

The CA is ultimately the one who decides what gets issued.  A good CA would know to only issue properly formatted BGPsec certificates either by ignoring the improperly requested feature" or rejecting it outright.  Since these CAs really arent open CAs then the CA ought not get caught off-guard with requests.
I'm not sure I understand. Why not give a consistent advice to EEs and CAs, e.g., reject any request that includes any Basic Constraints.


* 3.3: ID.sidr-rfc6485bis -> RFC 7935

drat I missed one.


* 6: in the paragraph that discusses hash functions, please spell out
the names of the two key identifiers, because I cannot determine what
they are from the document.

Ack theyre the key identifiers in the cert: Subject Key Identifier and Issuer Key Identifier 

r/two key identifier extensions./two key identifier extensions (i.e., Subject Key Identifier and Issuer Key Identifier)
Yes.

spt

--------------161B0AC6809EC36B16E83D53-- From nobody Tue Jan 3 14:33:59 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC3C129AB6 for ; Tue, 3 Jan 2017 14:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 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_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 XexfAewJiZ9H for ; Tue, 3 Jan 2017 14:33:56 -0800 (PST) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 C1314129A96 for ; Tue, 3 Jan 2017 14:33:56 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 46C14B77 for ; Tue, 3 Jan 2017 22:33:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CywDnc3CtscC for ; Tue, 3 Jan 2017 16:33:56 -0600 (CST) Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 19F3CB92 for ; Tue, 3 Jan 2017 16:33:55 -0600 (CST) Received: by mail-ua0-f200.google.com with SMTP id h30so515117520uaf.1 for ; Tue, 03 Jan 2017 14:33:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nR2crH281N2FliYVWlr2PCUJYHPNXITotthKFzzLkJ8=; b=YkUrb2CZmAxKjDttqfgDWJYgz84oVHUQpWbiRZFC8C2uSruU0+ct/mKBDNGTmmSjV5 8z9qb2DMR6nEb03Shd54BK2qh+E8dycJLXWTIQZps9qY1Htltsv1gbi16+7pr6BB0V+c +uV5XNeM3qODp05/jAezUwj7Svjlj9Ku68o39IChkGkCplaAKW/6lmq4AREZf2ORBOBl LvDYkrGFOxD2gvPxgUFwiZqMrq6f8NqXMg+DGbektslWot3W9rUTHxhjHAluEfJQDAkq iK3MraE239Rzf6dU8rk14QZ5L4SZ79Ir9mmRW7VjxEcZxyKhWmKHYxcAaYFx0KKa/u4p wkuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nR2crH281N2FliYVWlr2PCUJYHPNXITotthKFzzLkJ8=; b=cDeykAYQG39EG/RNqsYcZYykKN1TNDf87KMTNdshcfmFeRhM6XgcwjvThO+QzekZaT FnngGpUc+x2p0EzBNibnbOmFP22WU2lcvty5Y9O2bKu1iQuOhtw+uEcikErit38s22ax jbLKZMagJlqaRl/kcrGXN+gxaplufHKgOtPyDCkTr4pCWduoWA1+9miuWXDgukoOLHF2 Qe8r+wpOGm/lZhZXbaHUP0fWutMRLN1UEqxN1W1H98+eGbDFDc0F1dsODxF47XrY9f3n VD3PDGN9BiOgFZfL3FImhC98jgICcPpBQmMacOvsb+i+sRsFwRPTSxv6wJu4aNF6qy2u TjAw== X-Gm-Message-State: AIkVDXJyynDZNAeZhfAr5DiFpIpoZ2Ij0Cepz6txV++pH3yCL0O3xr0IlwLXHTXBoC90xpKhgaETfVLTqpvDmZxJkpkCGyPa1mKNKspdhwHVLCWy6eDcuhRNFYBASocuhWzTnwxKVBUgIFmoWhg= X-Received: by 10.159.32.133 with SMTP id 5mr47712474uaa.145.1483482835492; Tue, 03 Jan 2017 14:33:55 -0800 (PST) X-Received: by 10.159.32.133 with SMTP id 5mr47712461uaa.145.1483482835311; Tue, 03 Jan 2017 14:33:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.150.19 with HTTP; Tue, 3 Jan 2017 14:33:54 -0800 (PST) In-Reply-To: References: <7055D209-5BF7-4B5D-A675-356CD2CBFF4D@cisco.com> From: David Farmer Date: Tue, 3 Jan 2017 16:33:54 -0600 Message-ID: To: "Borchert, Oliver (Fed)" Content-Type: multipart/alternative; boundary=94eb2c0b62026df52b0545384327 Archived-At: Cc: "Sriram, Kotikalapudi \(Fed\)" , sidr wg list Subject: Re: [sidr] Confederations and Private ASNs (WAS: AD Review of draft-ietf-sidr-bgpsec-protocol-18) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 22:33:58 -0000 --94eb2c0b62026df52b0545384327 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 2, 2017 at 9:32 AM, Borchert, Oliver (Fed) < oliver.borchert@nist.gov> wrote: > > To avoid unnecessary confusion with the ambiguity of the word private, I > would change > the wording of =E2=80=9Cthe (private) Member-AS Number=E2=80=9D to =E2=80= =9Cthe Member-AS Number=E2=80=9D > by > removing the wording of =E2=80=9C(private)=E2=80=9D within parenthesis. > This leaves the usage of private only for the signing parties private key > which I think > is well understood. > > Oliver > I'd suggest the use of "private use" in the parenthesis instead of eliminating the word "private", and maybe add an informational reference to RFC6996 as well. If the intent that a "Member-AS Number" is to be from the private use range as defined in RFC6996, then that should be stated some place. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --94eb2c0b62026df52b0545384327 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 2, 2017 at 9:32 AM, Borchert, Oliver (Fed) <oliver.= borchert@nist.gov> wrote:
To avoid unnecessary confusion with the ambiguity of the word private, I wo= uld change
the wording of =E2=80=9Cthe (private) Member-AS Number=E2=80=9D to =E2=80= =9Cthe Member-AS Number=E2=80=9D by
removing the wording of =E2=80=9C(private)=E2=80=9D within parenthesis.
This leaves the usage of private only for the signing parties private key w= hich I think
is well understood.

Oliver

I'd suggest the use of= "private use" in the parenthesis instead of eliminating the word= "private", and maybe add an informational reference to RFC6996 a= s well.=C2=A0 If the intent that a "Member-AS Number" is to be fr= om the private use range as defined in RFC6996, then that should be stated = some place.

--=C2=A0
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Fa= rmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Net= working & Telecommunication Services
Office of Information Technolog= y
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2= =A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
--94eb2c0b62026df52b0545384327-- From nobody Tue Jan 3 15:28:52 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E501294B4; Tue, 3 Jan 2017 15:28:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148348613046.28010.9982061046362154033.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2017 15:28:50 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-bgpsec-ops@ietf.org, sidr@ietf.org Subject: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 23:28:50 -0000 Ben Campbell has entered the following ballot position for draft-ietf-sidr-bgpsec-ops-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a few minor and editorial comments: -1, first paragraph: "It is thought...": Can you mention "who" thinks it? Otherwise that reads as "weasel words". -1, third paragraph: Please consider writing out "also known as" -4, first paragraph: I found "either" followed by "and/or" a bit confusing. I suggest simply dropping the word "either". -4, 2nd paragraph: The MAY seems like a statement of fact. Is it intended to offer permission, or describe reality? (The latter should not use a 2119 keyword.) -4, last paragraph: "a prudent operator will..." sounds like it might be worthy of a SHOULD. -6, first paragraph: "SHOULD/MUST only" constructions tend to be ambiguous. In this case, are we saying SHOULD only originated signed announcements, as opposed to unsigned announcements? Or as opposed to validating received assignments? If the latter, then the "need not validate" seems to weaken the SHOULD. -6, last paragraph: Can something be cited for the 84% assertion? -7, paragraph 6: This seems to say that signed paths MUST be signed. Does the "MUST be signed if sent to external BGP speakers" mean that the existing signature must not be stripped (as stated more weakly in the previous sentence), or does it mean the sender must re-sign the path? -7, paragraph 7: "a signed path learned via iBGP MAY be Not Valid." seems like a statement of fact. -12.2: [I-D.ietf.sider.bgpsec.overview] is mentioned in section 2 as needed to understand this document. That suggests it should be a normative reference. - From nobody Tue Jan 3 15:32:09 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A27E129479; Tue, 3 Jan 2017 15:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 9_umPQFjWpy8; Tue, 3 Jan 2017 15:32:03 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 48DFA1293D6; Tue, 3 Jan 2017 15:32:03 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cOYYI-0005iD-3O; Tue, 03 Jan 2017 23:31:34 +0000 Date: Wed, 04 Jan 2017 08:31:31 +0900 Message-ID: From: Randy Bush To: Peter Hessler In-Reply-To: <20170103083907.GE5069@gir.theapt.org> References: <148336377615.21819.15119186800162780376.idtracker@ietfa.amsl.com> <563AAA29-82F7-4202-8A54-855CD7702595@kuehlewind.net> <20170103083907.GE5069@gir.theapt.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Chris Morrow , Mirja Kuehlewind , The IESG , sidr wg list Subject: Re: [sidr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-sidr-bgpsec-ops-12=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 23:32:04 -0000 >> ok, i have had coffee. >> >> as a bif gedanken experiment, posit a global registry where r0 can say >> "i can speak bgpsec." i am a distant r1 and receive an unsigned path >> with r0 in it. >> o did someone before r0 on the path not speak bgpsec, so the path was >> never signed? >> o did someone between us not speak bgpsec, so the path was stripped? >> o was there a monkey in the middle? >> >> i think we did discuss this problem space, and decided that, as long as >> we allow islands of partial deployment, and therefore path stripping, >> the monkey is on our back. we might have been wrong in this; but even >> with coffee i do not see a way out. >> >> and i do not think the idea of partial path signing, r0 signing a >> received unsigned path, would have helped a lot. >> >> it is not clear to me that this is a space where the ops doc can help >> much. i am open to ideas. > > I'm currently not using bgpsec (or rpki for that matter). BUT, if there > was no path to go back, I would never ever use it. Destroying my ASN > because I wasn't ready to migrate is a straight-up No Go(tm). > > Mistakes will be made. Rolling back will happen. Preventing rolling > back will kill the baby and will guarentee this will never be rolled > out. what do you mean by "no path to go back" and "rolling back?" where do you see "destroying" your AS? my only guess is that o you have not read the spec or any documentation on it, and o you triggered on the phrase "path stripping" fwiw, path stripping is removing the bgpsec gorp from a bgpsec path and rendering a classic bgp4 path to hand to a bgp listener who does not understand bgpsec. no ASs are harmed in the process. randy From nobody Tue Jan 3 15:59:22 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1478B129453; Tue, 3 Jan 2017 15:59:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148348795694.28027.8646303758093237302.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2017 15:59:16 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-bgpsec-ops@ietf.org, sidr@ietf.org Subject: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 23:59:17 -0000 Ben Campbell has entered the following ballot position for draft-ietf-sidr-bgpsec-ops-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Update: I noted when reviewing other sidr drafts on this telechat agenda that this draft treats 2119 keywords differently than the other drafts. That is, this draft explicitly excludes lower case versions of the 2119 keywords, while the other related drafts do not. Assuming that these drafts have the same target audience, I think that will be confusing to readers. I am okay with either approach; in fact I somewhat prefer excluding lower case versions. But I think consistency among a related group of drafts is more important. Just a few minor and editorial comments: -1, first paragraph: "It is thought...": Can you mention "who" thinks it? Otherwise that reads as "weasel words". -1, third paragraph: Please consider writing out "also known as" -4, first paragraph: I found "either" followed by "and/or" a bit confusing. I suggest simply dropping the word "either". -4, 2nd paragraph: The MAY seems like a statement of fact. Is it intended to offer permission, or describe reality? (The latter should not use a 2119 keyword.) -4, last paragraph: "a prudent operator will..." sounds like it might be worthy of a SHOULD. -6, first paragraph: "SHOULD/MUST only" constructions tend to be ambiguous. In this case, are we saying SHOULD only originated signed announcements, as opposed to unsigned announcements? Or as opposed to validating received assignments? If the latter, then the "need not validate" seems to weaken the SHOULD. -6, last paragraph: Can something be cited for the 84% assertion? -7, paragraph 6: This seems to say that signed paths MUST be signed. Does the "MUST be signed if sent to external BGP speakers" mean that the existing signature must not be stripped (as stated more weakly in the previous sentence), or does it mean the sender must re-sign the path? -7, paragraph 7: "a signed path learned via iBGP MAY be Not Valid." seems like a statement of fact. -12.2: [I-D.ietf.sider.bgpsec.overview] is mentioned in section 2 as needed to understand this document. That suggests it should be a normative reference. - From nobody Tue Jan 3 18:00:26 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EAD129961; Tue, 3 Jan 2017 18:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 C18tSo_n3dLS; Tue, 3 Jan 2017 18:00:20 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 E658B12995A; Tue, 3 Jan 2017 18:00:19 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cOasB-0006KJ-Jl; Wed, 04 Jan 2017 02:00:15 +0000 Date: Wed, 04 Jan 2017 11:00:13 +0900 Message-ID: From: Randy Bush To: "Ben Campbell" In-Reply-To: <148348795694.28027.8646303758093237302.idtracker@ietfa.amsl.com> References: <148348795694.28027.8646303758093237302.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: The IESG , sidr wg list Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 02:00:21 -0000 thanks for the review. > Update: I noted when reviewing other sidr drafts on this telechat > agenda that this draft treats 2119 keywords differently than the other > drafts. That is, this draft explicitly excludes lower case versions > of the 2119 keywords which is, i believe, the current wisdom; see long discussion on ietf list. > while the other related drafts do not. have fun with that. :) > -1, first paragraph: "It is thought...": Can you mention "who" thinks > -it? phrase removed > -1, third paragraph: Please consider writing out "also known as" rich got that > -4, first paragraph: I found "either" followed by "and/or" a bit > confusing. I suggest simply dropping the word "either". As described in [I-D.ietf-sidr-rtr-keying] BGPsec-speaking routers are either capable of generating their own public/private key-pairs and having their certificates signed and published in the RPKI by the RPKI CA system, and/or are given public/private key-pairs by the operator. but the router(s) might not be capable of generating key-pairs. they might, they might not, the op may generate or not, or both. an absurd corner case might be that a router with two ASs has the as0 key stuffed by the as0 noc, and the as1 key is generated on device because that is the as1 policy. > -4, 2nd paragraph: The MAY seems like a statement of fact. Is it intended > to offer permission, or describe reality? (The latter should not use a > 2119 keyword.) sure > -4, last paragraph: "a prudent operator will..." sounds like it might be > worthy of a SHOULD. given the previous, how about lower case should > -6, first paragraph: "SHOULD/MUST only" constructions tend to be > ambiguous. In this case, are we saying SHOULD only originated signed > announcements, as opposed to unsigned announcements? Or as opposed to > validating received assignments? If the latter, then the "need not > validate" seems to weaken the SHOULD. An edge site which does not provide transit and trusts its upstream(s) may only originate a signed prefix announcement and not validate received announcements. > -6, last paragraph: Can something be cited for the 84% assertion? easier to remove it. actually, i thought i had done so already; which causes me to worry if i lost other edits. > -7, paragraph 6: This seems to say that signed paths MUST be signed. Does > the "MUST be signed if sent to external BGP speakers" mean that the > existing signature must not be stripped (as stated more weakly in the > previous sentence), or does it mean the sender must re-sign the path? Because of possible RPKI version skew, an AS Path which does not validate at router R0 might validate at R1. Therefore, signed paths that are Not Valid and yet propagated (because they are chosen as best path) should have their signatures left intact and MUST be signed if sent to external BGPsec speakers. i am not seeing where bgpsec stripping was suggested; in fact, the opposite. if router r0 receives a signed path and intends to pass that signed path to the next listener, r0 must sign the path. i am at a loss to understand your question. clue bat please. > -7, paragraph 7: "a signed path learned via iBGP MAY be Not Valid." > seems like a statement of fact. are you suggesting to downcase it? i will assume so. > -12.2: [I-D.ietf.sider.bgpsec.overview] is mentioned in section 2 as > needed to understand this document. That suggests it should be a > normative reference. ennie meenie. i think some other reviewer had me push refs around. i don't have a dog in this fight. my personal opinion would be that overview is informative and the protocol spec itself is normative. again, thanks. randy From nobody Tue Jan 3 18:02:27 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0304129960; Tue, 3 Jan 2017 18:02:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148349534297.27933.5034191093825118742.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2017 18:02:22 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-13.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 02:02:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : BGPsec Operational Considerations Author : Randy Bush Filename : draft-ietf-sidr-bgpsec-ops-13.txt Pages : 9 Date : 2017-01-03 Abstract: Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. It is expected to evolve as BGPsec is formalized and initially deployed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-ops-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 3 18:03:30 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4FF129965; Tue, 3 Jan 2017 18:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 cMh7Kxzm836p; Tue, 3 Jan 2017 18:03:24 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 AC80C129968; Tue, 3 Jan 2017 18:03:24 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cOavD-0006LB-Ax; Wed, 04 Jan 2017 02:03:23 +0000 Date: Wed, 04 Jan 2017 11:03:21 +0900 Message-ID: From: Randy Bush To: "Ben Campbell" In-Reply-To: References: <148348795694.28027.8646303758093237302.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: The IESG , sidr wg list Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 02:03:25 -0000 i posted -13 so iesg has fresh randy From nobody Tue Jan 3 19:02:06 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3276612952B; Tue, 3 Jan 2017 19:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 DcwEirDcUNq3; Tue, 3 Jan 2017 19:02:01 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 30C51129448; Tue, 3 Jan 2017 19:02:01 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cObpr-0006vK-Mn; Wed, 04 Jan 2017 03:01:56 +0000 Date: Wed, 04 Jan 2017 12:01:53 +0900 Message-ID: From: Randy Bush To: "Mirja Kuehlewind (IETF)" In-Reply-To: <35FB8869-1BCE-4C3B-9546-2581EC79F868@kuehlewind.net> References: <148336377615.21819.15119186800162780376.idtracker@ietfa.amsl.com> <563AAA29-82F7-4202-8A54-855CD7702595@kuehlewind.net> <9A40617C-EB4E-40FD-A8D2-65C292BAC08A@cisco.com> <35FB8869-1BCE-4C3B-9546-2581EC79F868@kuehlewind.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Chris Morrow , The IESG , sidr wg list Subject: Re: [sidr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-sidr-bgpsec-ops-12=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 03:02:02 -0000 > Agreed. I guess you could in addition be very clear that a router that > once negotiated (and/or send) BGPsec (attributes) should not be > expected to always do so. whoops! that'll be in -14. thanks. randy From nobody Tue Jan 3 19:04:56 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEED129B33 for ; Tue, 3 Jan 2017 19:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 nrABVIdNoJZ4 for ; Tue, 3 Jan 2017 19:04:53 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 D05CB12952B for ; Tue, 3 Jan 2017 19:04:53 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cObsh-0006xb-CD; Wed, 04 Jan 2017 03:04:51 +0000 Date: Wed, 04 Jan 2017 12:04:50 +0900 Message-ID: From: Randy Bush To: "Sriram, Kotikalapudi (Fed)" In-Reply-To: References: <7055D209-5BF7-4B5D-A675-356CD2CBFF4D@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] Confederations and Private ASNs (WAS: AD Review of draft-ietf-sidr-bgpsec-protocol-18) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 03:04:55 -0000 >> that is not the core of the problem. the bgpsec protocol doc has to >> specifically say that the public AS upon receiving the update from the >> private AS >> o if the private signed to the public, public should check sig, then >> strip it and then might sign as the originating AS or might not. on >> what criteria does it decide? >> o if the private did not sign, the public might sign or it might not. >> on what criteria does it decide? > >> as i said, once you burn that in, i will hack the ops doc > > Does this change (in Section 7 in the document) work for you? > > [OLD] > > It is possible that a stub customer of an ISP employs a private AS > number. Such a stub customer cannot publish a ROA in the global RPKI > for the private AS number and the prefixes that they use. Also, the > stub customer cannot become a BGPsec speaker. If a BGPsec speaker in > the ISP's AS receives an announcement for a prefix from the stub > customer and chooses to propagate it to BGPsec peers, then it MUST > strip the private AS and re-originate the prefix. In order to do > this, the prefix MUST have a ROA authorizing the ISP's AS to > originate it. > > [NEW] > > It is possible that a stub customer of an ISP employs a private AS > number. Such a stub customer cannot publish a ROA in the global RPKI > for the private AS number and the prefixes that they use. Also, the > global RPKI cannot support private AS numbers for issuing router > certificates for eBGP routers in the private AS. For interactions > between the stub customer and the ISP, the following two scenarios > are possible: > > 1. The stub customer sends an unsigned BGP update for a prefix to > the ISP's AS. An edge BGPsec speaker in the ISP's AS may choose > to propagate the prefix to its non-BGPsec and BGPsec peers. If > so, the ISP's edge BGPsec speaker MUST strip the AS_PATH with the > private AS number, and then (a) re-originate the prefix without > any signatures towards its non-BGPsec peer and (b) re-originate > the prefix including its own signature towards its BGPsec peer. > In both cases (i.e. (a) and (b)), the prefix MUST have a ROA in > the global RPKI authorizing the ISP's AS to originate it. > > 2. The ISP and the stub customer may use a local RPKI repository > (using a mechanism such as described in [I-D.ietf-sidr-slurm]). > Then there can be a ROA for the prefix originated by the sub AS, > and the eBGP speaker in the stub AS can be a BGPsec speaker > having a router certificate, albeit the ROA and router > certificate are valid only locally. With this arrangement, the > stub AS sends a signed update for the prefix to the ISP's AS. An > edge BGPsec speaker in the ISP's AS validates the update using > RPKI data based the local RPKI view. Further, it may choose to > propagate the prefix to its non-BGPsec and BGPsec peers. If so, > the ISP's edge BGPsec speaker MUST strip the Secure_Path and the > Signature Segment received from the stub AS with the private AS > number, and then (a) re-originate the prefix without any > signatures towards its non-BGPsec peer and (b) re-originate the > prefix including its own signature towards its BGPsec peer. In > both cases (i.e. (a) and (b)), the prefix MUST have a ROA in the > global RPKI authorizing the ISP's AS to originate it. i am easily confused. can this be said with significantly less words so i have a chance to actually understand it? randy From nobody Tue Jan 3 20:02:14 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D39127A91; Tue, 3 Jan 2017 20:02:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148350252902.27921.8666847752091341028.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2017 20:02:09 -0800 Archived-At: Cc: draft-ietf-sidr-bgpsec-protocol@ietf.org, sidr-chairs@ietf.org, m.waehlisch@fu-berlin.de, sidr@ietf.org Subject: [sidr] Suresh Krishnan's No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 04:02:09 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 2.1 The IANA registry at http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml may be a better reference for AFIs than RFC4760. * Section 4.2 Is there a specific reason that the signature construction algorithm orders the fields in the way it does? It does look pretty complicated to parse out and arrange the fields this way from the BGPsec packet that was received. Something like the following seems much simpler to calculate +------------------------------------+ | Target AS Number | +------------------------------------+ ---\ | Signature Segment : N-1 | \ +------------------------------------+ \ ... | +------------------------------------+ | | Signature Segment : 2 | | +------------------------------------+ | | Signature Segment : 1 | \ +------------------------------------+ > Data from | Secure_Path Segment : N | / N Segments +------------------------------------+ | ... | +------------------------------------+ | | Secure_Path Segment : 2 | | +------------------------------------+ / | Secure_Path Segment : 1 | / +------------------------------------+---/ | Algorithm Suite Identifier | +------------------------------------+ | AFI | +------------------------------------+ | SAFI | +------------------------------------+ | Prefix | +------------------------------------+ as the segment fields and signature fields are naturally grouped together in the packet. Is there a difference in cryptographic strength between these two constructions? From nobody Tue Jan 3 20:36:51 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F29F129533 for ; Tue, 3 Jan 2017 20:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 Q_B9IaI_Y_yG for ; Tue, 3 Jan 2017 20:36:48 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 AB78B127058 for ; Tue, 3 Jan 2017 20:36:48 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cOdJd-0007Fh-Jf; Wed, 04 Jan 2017 04:36:45 +0000 Date: Wed, 04 Jan 2017 13:36:43 +0900 Message-ID: From: Randy Bush To: joel jaeggli In-Reply-To: <167fc1b5-50b9-a240-afb7-080ab97f1805@bogus.com> References: <1FBAD3F8-5387-47A3-9988-A49A3133490A@cisco.com> <167fc1b5-50b9-a240-afb7-080ab97f1805@bogus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 04:36:49 -0000 [ side comment best ignored ] >> otoh, private AS numbers are used in non-confed topologies, e.g. the bgp >> stub customer who uses a private AS. they should not sign of course. >> but once i receive their announcement and strip the private AS, >> can/should i sign? i just looked at bgpsec-protocol and found no >> guidance. > > from that vantage point you are the origin. it's not clear to me that a > customer relationship is substantively then if you do this internal to ^ different [ i presume ] > your org. operationally the'yre probably also registering route objects, > issuing LOAS and operating on behalf of the private ASN. i buy everything but the LOAs. issues of legal authority to enter into contracts et alia. randy From nobody Wed Jan 4 01:57:37 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A92F127735; Wed, 4 Jan 2017 01:57:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148352385243.12916.15407627777806532255.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 01:57:32 -0800 Archived-At: Cc: draft-ietf-sidr-bgpsec-protocol@ietf.org, sidr-chairs@ietf.org, m.waehlisch@fu-berlin.de, sidr@ietf.org Subject: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 09:57:32 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- +1 to the comment from Suresh about order. I though that something like what he proposed will minimize memcopies and possibly use of memory why hashing. So I am also curious to know answer to his question. Otherwise the document is very well written and it was a pleasure to read! From nobody Wed Jan 4 02:09:45 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAEC128DF6; Wed, 4 Jan 2017 02:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 TMCdkl9iudOd; Wed, 4 Jan 2017 02:09:42 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 3E9CB12711D; Wed, 4 Jan 2017 02:09:42 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cOiVm-0008HN-AN; Wed, 04 Jan 2017 10:09:38 +0000 Date: Wed, 04 Jan 2017 19:09:35 +0900 Message-ID: From: Randy Bush To: "Alexey Melnikov" In-Reply-To: <148352385243.12916.15407627777806532255.idtracker@ietfa.amsl.com> References: <148352385243.12916.15407627777806532255.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr-chairs@ietf.org, draft-ietf-sidr-bgpsec-protocol@ietf.org, The IESG , m.waehlisch@fu-berlin.de, sidr@ietf.org Subject: Re: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 10:09:43 -0000 > +1 to the comment from Suresh about order. I though that something like > what he proposed will minimize memcopies and possibly use of memory why > hashing. So I am also curious to know answer to his question. a vendor engineer actually implementing requested the change to the current syntax for ease of generating/parsing. randy From nobody Wed Jan 4 04:49:48 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2D8129558; Wed, 4 Jan 2017 04:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 kJ5_zWy4ErWJ; Wed, 4 Jan 2017 04:49:45 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D4612954B; Wed, 4 Jan 2017 04:49:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6398; q=dns/txt; s=iport; t=1483534185; x=1484743785; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PU+ExoiGzPezSPvzM3wQ04qUD757um6QzFL90Coo+LQ=; b=EyxH5uXkeGJSupR6aS9PIDGnpes1yxKEf0qnWPBWp2biU4doaBVNXTHI 3WbLCKL+VZgTbi3icKRG/McDdDh2hjuABjpjv3h87Dya9r1yoAElOPj9T Oa1mytQNbVnQIHQ2P0o306crtDfUiKSMVs8TXm+C2glUx0KqPBVVHkGei o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLAQAp7mxY/5NdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnFHAQEBAQEfX4EMB41QpD+DGoIPggiGIgIagTI/FAECAQEBAQE?= =?us-ascii?q?BAWMohGkGI1YQAgEIQgICAjAlAgQBDQWIcK8ZgiUrigoBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdhkWCAgiCV4dLLYIxBZUShXcBkUCQWZI/AR84gSs8AYQOgUZyhyW?= =?us-ascii?q?BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,459,1477958400"; d="scan'208,217";a="193115261" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jan 2017 12:49:44 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v04Cniwm016328 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Jan 2017 12:49:44 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 4 Jan 2017 06:49:43 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Wed, 4 Jan 2017 06:49:43 -0600 From: "Alvaro Retana (aretana)" To: Randy Bush , Ben Campbell Thread-Topic: Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT) Thread-Index: AQHSZh1mV02ZKEidTEacSYlhmNd4h6En9OyAgABhpQA= Date: Wed, 4 Jan 2017 12:49:43 +0000 Message-ID: References: <148348795694.28027.8646303758093237302.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: multipart/alternative; boundary="_000_F170405A79844A15B2E799E2BE0682C4ciscocom_" MIME-Version: 1.0 Archived-At: Cc: The IESG , sidr wg list Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 12:49:47 -0000 --_000_F170405A79844A15B2E799E2BE0682C4ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gMS8zLzE3LCA5OjAwIFBNLCAiUmFuZHkgQnVzaCIgPHJhbmR5QHBzZy5jb20+IHdyb3RlOg0K DQoNCg0KfCB8IC0xMi4yOiBbSS1ELmlldGYuc2lkZXIuYmdwc2VjLm92ZXJ2aWV3XSBpcyBtZW50 aW9uZWQgaW4gc2VjdGlvbiAyIGFzDQoNCnwgfCBuZWVkZWQgdG8gdW5kZXJzdGFuZCB0aGlzIGRv Y3VtZW50LiBUaGF0IHN1Z2dlc3RzIGl0IHNob3VsZCBiZSBhDQoNCnwgfCBub3JtYXRpdmUgcmVm ZXJlbmNlLg0KDQp8DQoNCnwgZW5uaWUgbWVlbmllLiAgaSB0aGluayBzb21lIG90aGVyIHJldmll d2VyIGhhZCBtZSBwdXNoIHJlZnMgYXJvdW5kLiAgaQ0KDQp8IGRvbid0IGhhdmUgYSBkb2cgaW4g dGhpcyBmaWdodC4gIG15IHBlcnNvbmFsIG9waW5pb24gd291bGQgYmUgdGhhdA0KDQp8IG92ZXJ2 aWV3IGlzIGluZm9ybWF0aXZlIGFuZCB0aGUgcHJvdG9jb2wgc3BlYyBpdHNlbGYgaXMgbm9ybWF0 aXZlLg0KDQoNCg0KSSBhZ3JlZS4gIEluIGZhY3QsIGl0IHdhcyBtZSB3aG8gYXNrZWQgdG8gbW92 ZSBJLUQuaWV0Zi1zaWRyLWJncHNlYy1vdmVydmlldyB0byBJbmZvcm1hdGl2ZSBhcyB0aGUgcmVm ZXJlbmNlIHRvIHRoZSBzcGVjIChkcmFmdC1pZXRmLXNpZHItYmdwc2VjLXByb3RvY29sKSBpcyB0 aGUgTm9ybWF0aXZlIG9uZS4NCg0KDQoNCkluIHRoaXMgY2FzZSwgd2UgZG9u4oCZdCB3YW50IHRv IG1ha2UgSS1ELmlldGYtc2lkci1iZ3BzZWMtb3ZlcnZpZXcgYSBOb3JtYXRpdmUgcmVmZXJlbmNl IGJlY2F1c2UgaXQgaXMgYW4gSW5mb3JtYXRpb25hbCBkb2N1bWVudCBhbmQgd291bGQgcmVzdWx0 IGluIGEgZG93bnJlZiAocmVzdWx0aW5nIGluIG1vcmUgcHJvY2VzcywgYW5kIHRoYXQgZG9jdW1l bnQgaXMgbm90IHJlYWR5IHlldCkuDQoNCg0KDQpBbHZhcm8uDQoNCg0K --_000_F170405A79844A15B2E799E2BE0682C4ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <40D2D2F49C25CE43B11408F368CC4643@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7 bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29s b3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7 DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4N Cjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+T24gMS8zLzE3LCA5OjAwIFBNLCAmcXVvdDtSYW5keSBCdXNoJnF1b3Q7ICZsdDtyYW5keUBw c2cuY29tJmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCB8IC0xMi4y OiBbSS1ELmlldGYuc2lkZXIuYmdwc2VjLm92ZXJ2aWV3XSBpcyBtZW50aW9uZWQgaW4gc2VjdGlv biAyIGFzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IHwgbmVlZGVk IHRvIHVuZGVyc3RhbmQgdGhpcyBkb2N1bWVudC4gVGhhdCBzdWdnZXN0cyBpdCBzaG91bGQgYmUg YTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCB8IG5vcm1hdGl2ZSBy ZWZlcmVuY2UuJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IGVubmllIG1lZW5pZS4m bmJzcDsmbmJzcDtpIHRoaW5rIHNvbWUgb3RoZXIgcmV2aWV3ZXIgaGFkIG1lIHB1c2ggcmVmcyBh cm91bmQuJm5ic3A7Jm5ic3A7aTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+fCBkb24ndCBoYXZlIGEgZG9nIGluIHRoaXMgZmlnaHQuJm5ic3A7Jm5ic3A7bXkgcGVyc29u YWwgb3BpbmlvbiB3b3VsZCBiZSB0aGF0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij58IG92ZXJ2aWV3IGlzIGluZm9ybWF0aXZlIGFuZCB0aGUgcHJvdG9jb2wgc3BlYyBp dHNlbGYgaXMgbm9ybWF0aXZlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIGFncmVl LiZuYnNwOyBJbiBmYWN0LCBpdCB3YXMgbWUgd2hvIGFza2VkIHRvIG1vdmUgSS1ELmlldGYtc2lk ci1iZ3BzZWMtb3ZlcnZpZXcgdG8gSW5mb3JtYXRpdmUgYXMgdGhlIHJlZmVyZW5jZSB0byB0aGUg c3BlYyAoZHJhZnQtaWV0Zi1zaWRyLWJncHNlYy1wcm90b2NvbCkgaXMgdGhlIE5vcm1hdGl2ZSBv bmUuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JbiB0aGlzIGNhc2UsIHdlIGRvbuKAmXQgd2FudCB0byBt YWtlIEktRC5pZXRmLXNpZHItYmdwc2VjLW92ZXJ2aWV3IGEgTm9ybWF0aXZlIHJlZmVyZW5jZSBi ZWNhdXNlIGl0IGlzIGFuIEluZm9ybWF0aW9uYWwgZG9jdW1lbnQgYW5kIHdvdWxkIHJlc3VsdCBp biBhIGRvd25yZWYgKHJlc3VsdGluZyBpbiBtb3JlIHByb2Nlc3MsIGFuZCB0aGF0IGRvY3VtZW50 IGlzIG5vdCByZWFkeSB5ZXQpLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QWx2YXJvLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F170405A79844A15B2E799E2BE0682C4ciscocom_-- From nobody Wed Jan 4 05:47:31 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D01CA129590; Wed, 4 Jan 2017 05:47:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148353764984.13034.8506727126675155642.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 05:47:29 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-bgpsec-ops@ietf.org, sidr@ietf.org Subject: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 13:47:30 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-sidr-bgpsec-ops-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I reviewed -12 but I think all these comments are as (ir)relevant as ever;-) - general: given where we are with deployment I wonder would it be a good idea if this document explicitly said sometthing to the effect that "it's early days, this is what we think is the BCP but that may change over time, so while we think doing this is right, be careful to not paint yourself into a corner when doing this." - intro: this seems to say: first do rpki and only when that's finished start on bgpsec - is that really what's meant? The rest of the document makes me doubt that. I think what you maybe meant was "Any specific ASN needs to have setup RPKI for itself before it can speak BGPsec." - intro, 3rd para: where are the "special operational considerations" explained? A reference would be good. If there's no good reference, I'm not clear why saying this is useful. (Actual operators might find this clear of course, in which case, please ignore me.) - section 2: this refers to the BGPsec overview which refers back to this document, but says that this is informational rather than a BCP. Just noting that in case there's confusion and that's not just a typo or a case of the overview not having been updated. I expect the fix is to change the text in the overview. - section 5: What does "fully BGPSEC enabled" mean exactly? That could be referring to signing or to validation of signatures (with or without hard fails) or to never emitting unsigned or accepting unsigned announcements or to some combination of the above. It might be better to avoid use of such a term in order to avoid having to define it for now. (This relates also to the mail subsequent to Mirja's comments.) - section 7: MED could do with expansion and a reference. - section 7: I'm not clear what you mean by "RPKI version skew." You could explain that or maybe use another basis to explain why R0 and R1 might disagree, e.g. revocation status info availability or freshness maybe. - section 8: "forward signed to R" is a bit opaque (for me anyway, before I read the protocol draft). Maybe better to explain this a bit more. - I-D nits complains about some easily fixable things (about which I do not care:-) From nobody Wed Jan 4 05:51:22 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 727901294BC; Wed, 4 Jan 2017 05:51:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148353788046.13042.160471261406266.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 05:51:20 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org Subject: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 13:51:20 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-sidr-bgpsec-pki-profiles-19: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a few probably quick things I'd like to discuss for this one: (1) 3.1.1: Why MUST a CA ensure that the CA name and Subject name combination is unique? I don't see what'd break in BGPsec if that rule is omitted, but maybe I'm missing something. (2) 3.1.1: Similarly, I'm not clear why only common name and serial number are allowed in Subject. Why is that needed for interop? (I can see that you want to say that code MUST support those but not why you want to prevent other things.) (3) Where's certificate status checking covered? What's expected for BGPsec router certs? If BGPsec speakers are intended to inherit the CRL checking from 6487 then being explicit about that would probably be worthwhile. And I'd wonder if router cert revocation will be more common than for other resource certs, in which case an OCSP-like system could be needed - did the WG consider that? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - section 2: I think this is a bit badly written: "The use of BGPsec Router Certificates in no way affects RPKI RPs that process Manifests and ROAs because the public key found in the BGPsec Router Certificate is used only to verify the signature on the BGPsec certificate request (only CAs process these) and the signature on a BGPsec Update Message [ID.sidr-bgpsec-protocol] (only BGPsec routers process these)." Do you mean that there's no way that an entity can confuse a Manifest, ROA, CSR or BGPsec update so there's no issue with which public keys are used to verify the signatures on those data structures? - section 3: As noted in my comments on the BGPsec protocol, it'd be better to call out the SKI here if you don't add the direct ref to 6487 to the BGPsec protocol draft. From nobody Wed Jan 4 05:53:14 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A921294BC; Wed, 4 Jan 2017 05:53:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 05:53:08 -0800 Archived-At: Cc: draft-ietf-sidr-bgpsec-protocol@ietf.org, sidr-chairs@ietf.org, m.waehlisch@fu-berlin.de, sidr@ietf.org Subject: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 13:53:09 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a couple of fairly straightforward things I'd like to briefly discuss... (1) 3.2/Figure 7: A fixed 20 byte SKI being a sha-1 hash of the public key is a bad plan, for all the usual reasons. Why is it ok for that to be hardcoded here when it could change if/when new alg choices are made for the RPKI? If it is not too late then I think you should add a length or alg field to that. If it is too late to do that, then are we really ok that you will need to rev the BGPsec version number in order to get rid of all sha-1 code from your implementation? That seems like a bad plan for a new protocol. (2) Figure 8: It seems to me to be an error to omit the signer's ASN from the signed data and only have that included in the signer's certificate. Why is that intimate level of binding to the RPKI desirable? There may well be reasons but I'm not seeing 'em, and I am recalling that it took a chunk of effort to make CMS less dependent on X.509 for similar reasons (meaning identifying signers exclusively via cert issuer and serial in that case). I would expect that there could be demand to have some level of independence between BGPsec and RPKI for at least internal uses such as those noted in the spec already. (3) section 8: Is there a potential exposure here in that a relying party who emits e.g. certificate status checks or cert retrieval queries for an RPKI cert they've not previously seen is exposing something about the set of paths its traffic is likely to follow. (This is similar to why we have OCSP stapling in the web.) IIRC the RPKI specs may cover this but I suspect it'd be worth noting here as well even if so as this represents exposing something about BGP announcement content to off-path parties which I think is new for BGP. Is that a new thing for BGP? (I think the new aspect to the attack is that a bad actor who has already compromised some AS could more easily spot that traffic from the relying party's AS is likely to transit the compromised AS.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - (Non actionable comment really aimed at the IESG and not the authors/WG...) I'm kinda sad that even today we don't appear to have learned to value deploy-ability more highly. I fear that BGPsec and RPKI will suffer a similar lack of deployment as seen with S/MIME and DNSSEC and for possibly similar reasons (complexity, not starting with modest improvements, requiring a number of parties to change before seeing benefits). I hope I'm wrong about that, but equally, if I'm not and RPKI/BGPsec deployment turns out to be very very slow, (as opposed to the optimistic, "just slow";-) then I also hope the IESG at that time will be willing to consider alternatives - it's too easy for the IETF to just get stuck when a technology like this fails to deploy. But maybe I'm wrong and this'll all be fine and will be widely deployed and used in a few years. - Figures 2 and 5 present the fields in different orders. That seems like a bad idea. - 3.2: The reference to the pki profile doc is not precise enough, the string "key identifier" does not occur in that draft - it's in RFC6487, 4.8.2. - 4.1, last para: is the distinction between an "internal peer" and "iBGP peer" sufficiently clear to routing folk? For me they sound similar but I assume it's ok. - 5.2, I think you need to say something to the effect that every Secure_Path MUST have a signature with an algorithm that is supported. As I read the text, the algorithm as stated here could be read to not require that. E.g. the para before the bullets on p25 could be read to mean "drop all stuff involving unsupported algs and then continue to process the rest of the stuff." - section 7: WRT non-deterministic signature algorithms, I think it'd be useful to note here that all such algorithms require good random number generation on the signer's system and that failing in that respect can expose the signer's private key. IMO deterministic signature schemes are better for this reason but the need for a good RNG is I think a real operational issue worthy of note. From nobody Wed Jan 4 06:38:28 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B580129586 for ; Wed, 4 Jan 2017 06:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, 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 6nnsEW0vHvgi for ; Wed, 4 Jan 2017 06:38:23 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 2557C12958D for ; Wed, 4 Jan 2017 06:38:21 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id c47so492002379qtc.2 for ; Wed, 04 Jan 2017 06:38:21 -0800 (PST) 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=KMq1Ne04bW+Sbcic9ekb6U20ubXHMzzuxYaWkQcGFb0=; b=Ud0oks0CFq04FO/qzKqXOVsuznIWQdgRgL9TpvVbuc9a2s4h3e5aog9fzvwsY6Vt6S Tad91qM8SozsKlxE8QSbXuur2+c+GaC7g4DU9PxvlyA9xE76duwCjJNnuwC0i9Emfht6 aKipPDkFz8/RkLtZs/VTRfomOphWM6LA3Drz4= 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=KMq1Ne04bW+Sbcic9ekb6U20ubXHMzzuxYaWkQcGFb0=; b=kIOBcDtA1O/uSxi8X15/i4ZLQZdZ3siwD3gA8H0TFgcGywXJY2F2khlUYtPlItKzyl bpeyfwijMN6ktmDYqo6l9U6YcwmK7T1ZZZi+6hY1hYlXG0hvcJC6ZLNk1qtQoP+1Y50F bHrjTaoXLAVbCHPVPAaQGATYD3j4fW3HBxlummNxpgbJqkCVtkuGC3yoMvY0PFErzus7 oyXbzNw9WWsziaky0EN0TRoheoUnxb11QM2QZeTbZgMkW7ix916pm+2kfsqcDOn1cNqK hYyUGwDlpDav1aAEdYPDDpli34WcCIB5d8dzHYWAYvcuoDUI6MwOBGuWk+C2FuOHF8cd TMzw== X-Gm-Message-State: AIkVDXIqLXHDXEslouaxjeuNDiDt/HlUE5Z0YuUPmL6cFozx6bQ3gZHMPb1Xvu/xRowKEQ== X-Received: by 10.237.62.107 with SMTP id m40mr481244qtf.196.1483540700212; Wed, 04 Jan 2017 06:38:20 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id 7sm35318327qkx.49.2017.01.04.06.38.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Jan 2017 06:38:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Wed, 4 Jan 2017 09:38:16 -0500 Content-Transfer-Encoding: 7bit Message-Id: <64ABB874-A355-4F91-93D6-6671CB6A354C@sn3rd.com> References: <148352385243.12916.15407627777806532255.idtracker@ietfa.amsl.com> To: Alexey Melnikov , Suresh Krishnan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-sidr-bgpsec-protocol@ietf.org, sidr chairs , The IESG , sidr wg list , m.waehlisch@fu-berlin.de Subject: Re: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 14:38:24 -0000 > On Jan 4, 2017, at 05:09, Randy Bush wrote: > >> +1 to the comment from Suresh about order. I though that something like >> what he proposed will minimize memcopies and possibly use of memory why >> hashing. So I am also curious to know answer to his question. > > a vendor engineer actually implementing requested the change to the > current syntax for ease of generating/parsing. > > randy I believe this is that thread that resulted in the final organization: https://mailarchive.ietf.org/arch/msg/sidr/8B_e4CNxQCUKeZ_AUzsdnn2f5MU spt From nobody Wed Jan 4 07:44:42 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD051295BA; Wed, 4 Jan 2017 07:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 K_B2QLt5IroU; Wed, 4 Jan 2017 07:44:39 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 9FC4B129496; Wed, 4 Jan 2017 07:44:39 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cOnjv-00020W-2X; Wed, 04 Jan 2017 15:44:35 +0000 Date: Thu, 05 Jan 2017 00:44:32 +0900 Message-ID: From: Randy Bush To: Stephen Farrell In-Reply-To: <148353764984.13034.8506727126675155642.idtracker@ietfa.amsl.com> References: <148353764984.13034.8506727126675155642.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: The IESG , sidr wg list Subject: Re: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 15:44:40 -0000 > - general: given where we are with deployment I wonder > would it be a good idea if this document explicitly said > sometthing to the effect that "it's early days, this is > what we think is the BCP but that may change over time, so > while we think doing this is right, be careful to not > paint yourself into a corner when doing this." added As with most operational practices, this document will likely evolve. > - intro: this seems to say: first do rpki and only when > that's finished start on bgpsec - is that really what's > meant? The rest of the document makes me doubt that. I > think what you maybe meant was "Any specific ASN needs to > have setup RPKI for itself before it can speak BGPsec." we are in a twisty maze of nomenclature. to be boringly clear (i suspect you know this stuff, but i believe that you are using the wrong terms). The RPKI is the X.509 based hierarchy [rfc 6481] with is congruent with the internet IP address allocation administration, the IANA, RIRS, ISPs, ... It is the substrate on which the next two are based. It is currently deployed in all five administrative regions. RPKI-based Origin Validation [rfc 6811] uses some of the RPKI data to allow a router to verify that the autonomous system announcing an IP address prefix is in fact authorized to do so. This is not crypto checked so can be violated. But it should prevent the vast majority of accidental 'hijackings' on the internet today, e.g. the famous Pakistani accidental announcement of YouTube's address space. RPKI-based origin validation is in shipping code from Cisco, Juniper, AlcLu, and others. Path validation, AKA BGPsec, is a the next technology step with only proto/test code. It uses the full crypto information of the RPKI to allow a receiver of a BGP announcement to formally cryptographically validate that the originating autonomous system was truly authorized to announce the IP address prefix, and that the systems through which the announcement passed were indeed those which the sender/forwarder at each hop intended. so, i think you are referring to As core BGPsec-capable routers may require large memory and/or modern CPUs, origin validation based on the Resource Public Key Infrastructure (RPKI), [RFC6811], will occur over some years and BGPsec will start to deploy after that. as rpki is deployed to a fair extent, origin validation is baked into current routers, and bgpsec in the core will require bigger hardware, OV before BGPsec would seem to be the sequence. otoh, your last statement is true, an operator will have to set up rpki data before deploying either origin validation or bgpsec. rpki is needed for both. so i am not sure what you are suggesting i do. > - intro, 3rd para: where are the "special operational > considerations" explained? A reference would be good. If > there's no good reference, I'm not clear why saying this > is useful. (Actual operators might find this clear of > course, in which case, please ignore me.) how about This has special operational considerations, see Section 6. > - section 2: this refers to the BGPsec overview which > refers back to this document, but says that this is > informational rather than a BCP. Just noting that in case > there's confusion and that's not just a typo or a case of > the overview not having been updated. I expect the fix is > to change the text in the overview. i can support that :) > - section 5: What does "fully BGPSEC enabled" mean > exactly? That could be referring to signing or to > validation of signatures (with or without hard fails) or > to never emitting unsigned or accepting unsigned > announcements or to some combination of the above. It > might be better to avoid use of such a term in order to > avoid having to define it for now. (This relates also to > the mail subsequent to Mirja's comments.) somehow i do not think that adding more words helps, but In an AS where edge routers speak BGPsec and therefore inject BGPsec paths into the iBGP, Route Reflectors MUST have BGPsec enabled if and only if there are eBGP speakers in their client cone, i.e. an RR client or the transitive closure of a client's customers' customers' customers' etc. > - section 7: MED could do with expansion and a reference. how about ... value such as local-preference or multi-exit discriminator (MED). > - section 7: I'm not clear what you mean by "RPKI version > skew." You could explain that or maybe use another basis > to explain why R0 and R1 might disagree, e.g. revocation > status info availability or freshness maybe. sigh. more words. As the mildly stochastic timing of RPKI propagation may cause version skew across routers, an AS Path which does not validate at router R0 might validate at R1. > - section 8: "forward signed to R" is a bit opaque (for me > anyway, before I read the protocol draft). Maybe better to > explain this a bit more. 2. Suggested Reading It is assumed that the reader understands BGP, see [RFC4271], BGPsec, [I-D.ietf-sidr-bgpsec-overview], the RPKI, see [RFC6480], the RPKI Repository Structure, see [RFC6481], and Route Origin Authorizations (ROAs), see [RFC6482]. should i change that from -overview to -protocol? randy From nobody Wed Jan 4 08:09:58 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318431295F7; Wed, 4 Jan 2017 08:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 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, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham 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 6cMiAoznwYHC; Wed, 4 Jan 2017 08:09:54 -0800 (PST) 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 789CC1295F2; Wed, 4 Jan 2017 08:09:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DE01CBE55; Wed, 4 Jan 2017 16:09:51 +0000 (GMT) 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 FnXLtU3_A5hU; Wed, 4 Jan 2017 16:09:51 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 56034BE39; Wed, 4 Jan 2017 16:09:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483546191; bh=TsuY6f5r7/Wu19KQNTyu+fl0XSZgVUY9S/CY38QpXWU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=VN3a2KqAMI/evkoGeP+VirEB7k0TuQm5l3MeR/cFbVpNgaGmSxTpUDtI0gYvqwaNQ 4p3/JBEy8UgRBpgu9DS+8+jJKNr5M2elcHSBgeUyNwN0ecJAFKJfOW/7Joydr2s2Lb EoGWRowrtSIaX0tNf1uCreb6PV7F7VlQ1qor2joc= To: Randy Bush References: <148353764984.13034.8506727126675155642.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 4 Jan 2017 16:09:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030909020000010905000601" Archived-At: Cc: The IESG , sidr wg list Subject: Re: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 16:09:57 -0000 This is a cryptographically signed message in MIME format. --------------ms030909020000010905000601 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 04/01/17 15:44, Randy Bush wrote: >> - general: given where we are with deployment I wonder >> would it be a good idea if this document explicitly said >> sometthing to the effect that "it's early days, this is >> what we think is the BCP but that may change over time, so >> while we think doing this is right, be careful to not >> paint yourself into a corner when doing this." >=20 > added >=20 > As with most operational practices, this document will likely > evolve. Grand. > =20 >> - intro: this seems to say: first do rpki and only when >> that's finished start on bgpsec - is that really what's >> meant? The rest of the document makes me doubt that. I >> think what you maybe meant was "Any specific ASN needs to >> have setup RPKI for itself before it can speak BGPsec." >=20 > we are in a twisty maze of nomenclature. to be boringly clear (i > suspect you know this stuff, but i believe that you are using the wrong= > terms). >=20 > The RPKI is the X.509 based hierarchy [rfc 6481] with is congruent > with the internet IP address allocation administration, the IANA, > RIRS, ISPs, ... It is the substrate on which the next two are > based. It is currently deployed in all five administrative regions= =2E >=20 > RPKI-based Origin Validation [rfc 6811] uses some of the RPKI data > to allow a router to verify that the autonomous system announcing a= n > IP address prefix is in fact authorized to do so. This is not > crypto checked so can be violated. But it should prevent the vast > majority of accidental 'hijackings' on the internet today, e.g. the= > famous Pakistani accidental announcement of YouTube's address space= =2E > RPKI-based origin validation is in shipping code from Cisco, > Juniper, AlcLu, and others. >=20 > Path validation, AKA BGPsec, is a the next technology step with onl= y > proto/test code. It uses the full crypto information of the RPKI t= o > allow a receiver of a BGP announcement to formally cryptographicall= y > validate that the originating autonomous system was truly authorize= d > to announce the IP address prefix, and that the systems through > which the announcement passed were indeed those which the > sender/forwarder at each hop intended. >=20 > so, i think you are referring to >=20 > As core BGPsec-capable routers may require large memory and/or moder= n > CPUs, origin validation based on the Resource Public Key > Infrastructure (RPKI), [RFC6811], will occur over some years and > BGPsec will start to deploy after that. >=20 > as rpki is deployed to a fair extent, origin validation is baked into > current routers, and bgpsec in the core will require bigger hardware, O= V > before BGPsec would seem to be the sequence. >=20 > otoh, your last statement is true, an operator will have to set up rpki= > data before deploying either origin validation or bgpsec. rpki is > needed for both. >=20 > so i am not sure what you are suggesting i do. I was suggesting re-wording so that the text cannot be read so as to mean "don't bother with BGPsec until the entire world has finished deploying OV." Maybe: As core BGPsec-capable routers may require large memory and/or modern CPUs, origin validation based on the Resource Public Key Infrastructure (RPKI), [RFC6811], will occur over some years and, once origin validation has been deployed at an AS, then BGPsec can start to deploy in that AS. Though I'm not sure that's precisely right either. >=20 >> - intro, 3rd para: where are the "special operational >> considerations" explained? A reference would be good. If >> there's no good reference, I'm not clear why saying this >> is useful. (Actual operators might find this clear of >> course, in which case, please ignore me.) >=20 > how about >=20 > This has special operational considerations, see Section 6. Ack. And the same for all your other suggested changes. And to be sure to be sure, none of the above should be blocking and do feel entirely free to not make any of these changes if you'd rather not. Thanks, S. >=20 >> - section 2: this refers to the BGPsec overview which >> refers back to this document, but says that this is >> informational rather than a BCP. Just noting that in case >> there's confusion and that's not just a typo or a case of >> the overview not having been updated. I expect the fix is >> to change the text in the overview. >=20 > i can support that :) >=20 >> - section 5: What does "fully BGPSEC enabled" mean >> exactly? That could be referring to signing or to >> validation of signatures (with or without hard fails) or >> to never emitting unsigned or accepting unsigned >> announcements or to some combination of the above. It >> might be better to avoid use of such a term in order to >> avoid having to define it for now. (This relates also to >> the mail subsequent to Mirja's comments.) >=20 > somehow i do not think that adding more words helps, but >=20 > In an AS where edge routers speak BGPsec and therefore inject BGPsec= > paths into the iBGP, Route Reflectors MUST have BGPsec enabled if an= d > only if there are eBGP speakers in their client cone, i.e. an RR > client or the transitive closure of a client's customers' customers'= > customers' etc. >=20 >> - section 7: MED could do with expansion and a reference. >=20 > how about >=20 > ... value such as local-preference or multi-exit discriminator > (MED). >=20 >> - section 7: I'm not clear what you mean by "RPKI version >> skew." You could explain that or maybe use another basis >> to explain why R0 and R1 might disagree, e.g. revocation >> status info availability or freshness maybe. >=20 > sigh. more words. >=20 > As the mildly stochastic timing of RPKI propagation may cause versio= n > skew across routers, an AS Path which does not validate at router R0= > might validate at R1. >=20 >> - section 8: "forward signed to R" is a bit opaque (for me >> anyway, before I read the protocol draft). Maybe better to >> explain this a bit more. >=20 > 2. Suggested Reading >=20 > It is assumed that the reader understands BGP, see [RFC4271], BGPsec= , > [I-D.ietf-sidr-bgpsec-overview], the RPKI, see [RFC6480], the RPKI > Repository Structure, see [RFC6481], and Route Origin Authorizations= > (ROAs), see [RFC6482]. >=20 > should i change that from -overview to -protocol? >=20 > randy >=20 --------------ms030909020000010905000601 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDQx NjA5NDZaMC8GCSqGSIb3DQEJBDEiBCDKOd7vRDHxr0E6WUsSuWNuHBNT0fmw1254zh37QwJS iDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCklxXFQTGBaWl7SVjPLVKG1UDrO8x5jkByRpC3+SLlL0XhR4FFGqSW d7qCdRPQmsQVksJ319iINkf5hggy1s1W3V4hCdzU86pb8V6E1huBwsPH53TIOeK+suND1G+j Q+7BP09gfyvvO/imXFsxJJLrg7s5LoWaxMCkXB/Yqm5Pj/zVmIwJsG5aZ7TzCxEySJ6H4Wnj xzu2NqpTtDKFoHlzsB5/kjLnY3Va3VhrnNDM5fWEd73a7J9HiTWtDMfyTUxq29yZyUeUs1wi RKbPpRQdoVn55nx6h4lI/q3XbLluXbgKkzDqKN2cZOYOaQlP7AVG3vO/VpA74bQQyZAd8bAo AAAAAAAA --------------ms030909020000010905000601-- From nobody Wed Jan 4 08:16:24 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D88A91295ED; Wed, 4 Jan 2017 08:16:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148354658288.13030.6680402717954276501.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 08:16:22 -0800 Archived-At: Cc: draft-ietf-sidr-bgpsec-protocol@ietf.org, sidr-chairs@ietf.org, m.waehlisch@fu-berlin.de, sidr@ietf.org Subject: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 16:16:23 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Perhaps I'm just having a good day, but this is one of the clearest BGP-related specifications I can remember reviewing. Thanks for that, and especially for the background on design decisions. I did have questions on two points (which are spread across multiple sections). I started out wondering why Note that BGPsec update messages can be quite large, therefore any BGPsec speaker announcing the capability to receive BGPsec messages SHOULD also announce support for the capability to receive BGP extended messages [I-D.ietf-idr-bgp-extended-messages]. isn't a MUST, but Section 7 explains this In Section 2.2, is was stated that a BGPsec speaker SHOULD announce support for the capability to receive BGP extended messages. Lack of negotiation of this capability is not expected to pose a problem in the early years of BGPsec deployment. However, as BGPsec is deployed more and more, the BGPsec update messages would grow in size and some messages may be dropped due to their size exceeding the current 4K bytes limit. Therefore, it is strongly RECOMMENDED that all BGPsec speakers negotiate the extended message capability within a reasonable period of time after initial deployment of BGPsec. Perhaps that's worth a forward pointer? (or maybe even dragging this paragraph forward from Section 7) I'm looking at BGPsec speakers SHOULD drop incoming update messages with pCount set to zero in cases where the BGPsec speaker does not expect its peer to set pCount to zero. (That is, pCount is only to be set to zero in cases such as route servers or AS Number Migration where the BGPsec speaker's peer expects pCount to be set to zero.) and wondering why that's not a MUST. If I'm understanding this correctly (which is theoretically possible), the BGPsec speaker is telling its peer that it's not participating as a transit AS, but the peer thinks it should be. Is there anything intelligent that the peer can do with the update? Section 7 refers to this SHOULD, while adding a few more SHOULDs. A peer that is an Internet Exchange Point (IXP) (i.e. Route Server) with a transparent AS is expected to set pCount = 0 in its Secure_Path Segment while forwarding an update to a peer (see Section 4.2). Clearly, such an IXP SHOULD configure itself to set its own pCount = 0. As stated in Section 4.2, "BGPsec speakers SHOULD drop incoming update messages with pCount set to zero in cases where the BGPsec speaker does not expect its peer to set pCount to zero." This means that a BGPsec speaker SHOULD be configured so that it permits pCount =0 from an IXP peer and never permits pCount = 0 from a peer that is not an IXP. Again, I'm curious about why a BGPsec speaker wouldn't do this. Is that obvious, to those skilled in the art? I'm looking at Section 8.4, which adds some more background. The mechanism of setting the pCount field to zero is included in this specification to enable route servers in the control path to participate in BGPsec without increasing the length of the AS path. However, entities other than route servers could conceivably use this mechanism (set the pCount to zero) to attract traffic (by reducing the length of the AS path) illegitimately. This risk is largely mitigated if every BGPsec speaker drops incoming update messages that set pCount to zero but come from a peer that is not a route server. However, note that a recipient of a BGPsec update message within which an upstream entity two or more hops away has set pCount to zero is unable to verify for themselves whether pCount was set to zero legitimately. So, the reason this is a SHOULD, and not a MUST, is because a recipient two or more hops away can't be sure pCount was set appropriately? But doesn't the SHOULD increase the chances to propagate an update with an inappropriate pCount? From nobody Wed Jan 4 08:20:58 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A239129658; Wed, 4 Jan 2017 08:20:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148354685349.12965.6263489032913962215.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 08:20:53 -0800 Archived-At: Cc: draft-ietf-sidr-bgpsec-protocol@ietf.org, sidr-chairs@ietf.org, m.waehlisch@fu-berlin.de, sidr@ietf.org Subject: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 16:20:55 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I share various people's concerns about the deployability of this protocol, but I realize this is where the WG ended up after many years of work so fingers crossed, I guess. - Fig 2: Shouldn't the signatures in Sig Block 2 have different identifiers (e.g., X2, Y2) than those in Sig Block 1? - Sec 6.1: "(likely a small number of years)" -- given how hard these things are to predict, is it wise to include this text here? - I was surprised not to see an example message or two in this document. From nobody Wed Jan 4 08:22:30 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB20129640; Wed, 4 Jan 2017 08:22:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148354694377.12928.12337719277813930522.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 08:22:23 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-bgpsec-ops@ietf.org, sidr@ietf.org Subject: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 16:22:24 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sidr-bgpsec-ops-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 5 = "Route Reflectors MUST have BGPsec enabled if and only if there are eBGP speakers in their client cone, i.e. an RR client or the transitive closure of a client's customers' customers' customers' etc." "MUST ... if and only if" is a strange construction. I'm assuming what is meant here is that Route Reflectors MUST NOT enable BGPsec unless there are eBGP speakers in their client cone -- that might be a more sensible way to phrase this since clearly enabling BGPsec isn't required for anyone. Also, for a normative requirement I think it would be better to be specific rather than saying "etc." (e.g., "a client's customers or customers thereof" or something like that). "Additionally, outsourcing verification is not prudent security practice." Isn't that part of the point of draft-ietf-sidr-rpki-rtr-rfc6810-bis though? I know this paragraph is not talking about that but since use of a trusted cache was mentioned in the protocol draft, this struck me as a slight discrepancy. From nobody Wed Jan 4 08:40:40 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD85C1299A8; Wed, 4 Jan 2017 08:40:37 -0800 (PST) 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=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 LyBsG_uGZsrm; Wed, 4 Jan 2017 08:40:36 -0800 (PST) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 E455712999E; Wed, 4 Jan 2017 08:40:35 -0800 (PST) Received: by mail-qk0-x244.google.com with SMTP id u25so54607990qki.2; Wed, 04 Jan 2017 08:40:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=u1Z+PWLVOMcxZf9xKLbmGMeQHjuoNviN+XyUjpmiOGQ=; b=AV5qL92vdSwtd6n59s/r2zvHIB98yEM5BzPMBWV8T+II7tJ2lpzCE2SO7JY+SBBs6h Yvz/B64H/hUixT9RNv6tj10SoaUBsmToMNGTIlg+1bwusz3FpVCfbXfAp5j2zarCdUhv 1P/tG2aCN/7NfKz/Nwzf3Ly35031mnnRmSWYUOj2yqPImWtX7L1wKb0L8VBLtwn8Et8B OGYWGiLGFb7UHxAvLv7bxvCemPGL1/IddSnwLVr8ZelY5uaotVPiwAwfrz6lFTrylYwb 3g/3OR4Lbjr9OPyHwSTneNVRQGcuge7hlLIZNQ+k0JXMcTDwKwv/emyxAUl0HuE7uGdj vl8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=u1Z+PWLVOMcxZf9xKLbmGMeQHjuoNviN+XyUjpmiOGQ=; b=naXYmH2YTk0CJ5WhwGeDN9ShFhCmEMh9nxCDsMYUFqP1l+dSrtVcWHytH9wlm0zsQ/ thAM8iO835Mp2la2lTFIOMcNMQH+6vl7AAEcaVeI7Bqq4JfjkD3oqjyyPARuI2exoUO9 76Ztl95jslulaqCo+js+LhO+xYi9RMldZRqPoqqKAnJIQJmVwU/4dFVOqJHadT1KEvZS 9JJDKHyDd9F0PPVn96hdMMBbdhHfWzWnt/l0gMo8imNwZFw/OZJ2FTh1vMyBK557Zviv jI/2MpBY9GmR2hMPCJv14l6HX3Mx/JgsZy9dJFknmxNYOPeE2qWjJbSkHywCwFhIY3xJ MZcQ== X-Gm-Message-State: AIkVDXLbqeO/VzJXSKUJO7mTCezldG228UYAAwPGNymevjTpFuFadn21dj0zGEf+X0cC+3nzsTdsz70qLSzgDA== X-Received: by 10.55.214.152 with SMTP id p24mr56575298qkl.223.1483548035072; Wed, 04 Jan 2017 08:40:35 -0800 (PST) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.27.179 with HTTP; Wed, 4 Jan 2017 08:40:34 -0800 (PST) In-Reply-To: References: <148336377615.21819.15119186800162780376.idtracker@ietfa.amsl.com> <563AAA29-82F7-4202-8A54-855CD7702595@kuehlewind.net> <20170103083907.GE5069@gir.theapt.org> From: Christopher Morrow Date: Wed, 4 Jan 2017 11:40:34 -0500 X-Google-Sender-Auth: uosXvTDI1wdjsM9RQtQG1MlQEjA Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a1147998aa349b50545477165 Archived-At: Cc: Chris Morrow , sidr wg list , Mirja Kuehlewind , Peter Hessler , The IESG Subject: Re: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-bgpsec-ops-12=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 16:40:37 -0000 --001a1147998aa349b50545477165 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 3, 2017 at 6:31 PM, Randy Bush wrote: > >> ok, i have had coffee. > >> > >> as a bif gedanken experiment, posit a global registry where r0 can say > >> "i can speak bgpsec." i am a distant r1 and receive an unsigned path > >> with r0 in it. > >> o did someone before r0 on the path not speak bgpsec, so the path was > >> never signed? > >> o did someone between us not speak bgpsec, so the path was stripped? > >> o was there a monkey in the middle? > >> > >> i think we did discuss this problem space, and decided that, as long as > >> we allow islands of partial deployment, and therefore path stripping, > >> the monkey is on our back. we might have been wrong in this; but even > >> with coffee i do not see a way out. > >> > >> and i do not think the idea of partial path signing, r0 signing a > >> received unsigned path, would have helped a lot. > >> > >> it is not clear to me that this is a space where the ops doc can help > >> much. i am open to ideas. > > > > I'm currently not using bgpsec (or rpki for that matter). BUT, if there > > was no path to go back, I would never ever use it. Destroying my ASN > > because I wasn't ready to migrate is a straight-up No Go(tm). > > > > Mistakes will be made. Rolling back will happen. Preventing rolling > > back will kill the baby and will guarentee this will never be rolled > > out. > > what do you mean by "no path to go back" and "rolling back?" > > perhaps to paraphrase peter's question/comment: He's worried that the proposed standard may leave a user of the technology in a position where 'old bgp' is not functioning for him. I believe we ran over this horse several times in the WG and other places, basically to provide a path from 'today' to 'tomorrow' the ability to co-exist is required. On day-0 no bgpsec exists, on day-1 you (peter) turn up your first bgpsec peer pop champagne and rejoice... On day-2 you turn up 200 more... then on day-10 you realize things are not working so you disable bgpsec via some knob on your vendors' devices... All along both 'old bgp' and 'new bgpsec bgp' are working alongside each other. Randy's correct that the protocol / etc specs cover this sort of thing... fairly well. Because 'there are no flag days' on the intertubes, we have to plan for co-existence... Just like ipv6 did... wait, I mean dnssec. ;) -chris --001a1147998aa349b50545477165 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 3, 2017 at 6:31 PM, Randy Bush <randy@psg.com> w= rote:
>> ok, i hav= e had coffee.
>>
>> as a bif gedanken experiment, posit a global registry where r0 can= say
>> "i can speak bgpsec."=C2=A0 i am a distant r1 and receiv= e an unsigned path
>> with r0 in it.
>>=C2=A0 =C2=A0o did someone before r0 on the path not speak bgpsec, = so the path was
>>=C2=A0 =C2=A0 =C2=A0never signed?
>>=C2=A0 =C2=A0o did someone between us not speak bgpsec, so the path= was stripped?
>>=C2=A0 =C2=A0o was there a monkey in the middle?
>>
>> i think we did discuss this problem space, and decided that, as lo= ng as
>> we allow islands of partial deployment, and therefore path strippi= ng,
>> the monkey is on our back.=C2=A0 we might have been wrong in this;= but even
>> with coffee i do not see a way out.
>>
>> and i do not think the idea of partial path signing, r0 signing a<= br> >> received unsigned path, would have helped a lot.
>>
>> it is not clear to me that this is a space where the ops doc can h= elp
>> much.=C2=A0 i am open to ideas.
>
> I'm currently not using bgpsec (or rpki fo= r that matter).=C2=A0 BUT, if there
> was no path to go back, I would never ever use it.=C2=A0 Destroying my= ASN
> because I wasn't ready to migrate is a straight-up No Go(tm).
>
> Mistakes will be made.=C2=A0 Rolling back will happen.=C2=A0 Preventin= g rolling
> back will kill the baby and will guarentee this will never be rolled > out.

what do you mean by "no path to go back" and "rolling= back?"


perhaps to paraphrase peter's ques= tion/comment: He's worried that the proposed standard may leave a user = of the technology in a position where 'old bgp' is not functioning = for him.

I believe we ran over this horse several = times in the WG and other places, basically to provide a path from 'tod= ay' to 'tomorrow' the ability to co-exist is required. On day-0= no bgpsec exists, on day-1 you (peter) turn up your first bgpsec peer =C2= =A0pop champagne and rejoice... On day-2 you turn up 200 more... then on da= y-10 you realize things are not working so you disable bgpsec via some knob= on your vendors' devices...=C2=A0

All along both 'ol= d bgp' and 'new bgpsec bgp' are working alongside each other. R= andy's correct that the protocol / etc specs cover this sort of thing..= . fairly well.

Because 'there are no flag days= ' on the intertubes, we have to plan for co-existence... Just like ipv6= did... wait, I mean dnssec. ;)

-chris
=
--001a1147998aa349b50545477165-- From nobody Wed Jan 4 08:42:04 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE6F12966C; Wed, 4 Jan 2017 08:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 IL8fAzxCJFRL; Wed, 4 Jan 2017 08:41:55 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5DD7F129663; Wed, 4 Jan 2017 08:41:55 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v04GfpTi059508 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Jan 2017 10:41:51 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Alvaro Retana" Date: Wed, 04 Jan 2017 10:41:51 -0600 Message-ID: <41B2F724-8213-469E-836D-46650503B403@nostrum.com> In-Reply-To: References: <148348795694.28027.8646303758093237302.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: The IESG , sidr wg list Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 16:42:01 -0000 On 4 Jan 2017, at 6:49, Alvaro Retana (aretana) wrote: > On 1/3/17, 9:00 PM, "Randy Bush" wrote: > > > > | | -12.2: [I-D.ietf.sider.bgpsec.overview] is mentioned in section 2 > as > > | | needed to understand this document. That suggests it should be a > > | | normative reference. > > | > > | ennie meenie. i think some other reviewer had me push refs around. > i > > | don't have a dog in this fight. my personal opinion would be that > > | overview is informative and the protocol spec itself is normative. > > > > I agree. In fact, it was me who asked to move > I-D.ietf-sidr-bgpsec-overview to Informative as the reference to the > spec (draft-ietf-sidr-bgpsec-protocol) is the Normative one. > > > > In this case, we don’t want to make I-D.ietf-sidr-bgpsec-overview a > Normative reference because it is an Informational document and would > result in a downref (resulting in more process, and that document is > not ready yet). > > The issue I saw is that section 2 says readers are expected to understand bgpsec, and cites the overview for that purpose. Perhaps it should cite the protocol doc for the "expected to understand" part, and them mention separately that the overview provides, well, an overview? Ben. From nobody Wed Jan 4 08:46:17 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A618F1299AF; Wed, 4 Jan 2017 08:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 pcEaS7o-aGOV; Wed, 4 Jan 2017 08:46:10 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 7036A12999E; Wed, 4 Jan 2017 08:46:10 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cOohU-0002OW-BQ; Wed, 04 Jan 2017 16:46:08 +0000 Date: Thu, 05 Jan 2017 01:46:05 +0900 Message-ID: From: Randy Bush To: "Alissa Cooper" In-Reply-To: <148354694377.12928.12337719277813930522.idtracker@ietfa.amsl.com> References: <148354694377.12928.12337719277813930522.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: The IESG , sidr@ietf.org Subject: Re: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 16:46:12 -0000 > "Route Reflectors MUST have BGPsec enabled if and only if there are > eBGP speakers in their client cone, i.e. an RR client or the > transitive closure of a client's customers' customers' customers' > etc." > > "MUST ... if and only if" is a strange construction. the syntax may be stressed but the semantics are correct. > I'm assuming what is meant here is that Route Reflectors MUST NOT > enable BGPsec unless there are eBGP speakers in their client cone -- nope. if there are no bgpsec speakers in the client cone, the RRs MAY still choose to validate. the point is that, if there are *any* bgpsec speakers in the client cone, then you'll want them to receive signed paths. hence the RRs would have to enable bgpsec signing. > for a normative requirement I think it would be better to be specific > rather than saying "etc." (e.g., "a client's customers or customers > thereof" or something like that). how about tossing the extra words and going with i.e. an RR client or the transitive closure of a client's customers. > "Additionally, outsourcing verification is not prudent security > practice." > > Isn't that part of the point of draft-ietf-sidr-rpki-rtr-rfc6810-bis > though? I know this paragraph is not talking about that but since use > of a trusted cache was mentioned in the protocol draft, this struck me > as a slight discrepancy. 6810 sec 3 Local Caches: A local set of one or more collected and verified caches. A relying party, e.g., router or other client, MUST have a trust relationship with, and a trusted transport channel to, any authoritative cache(s) it uses. contrast this with this document's BGPsec does not sign over communities, so they are not formally trustable. Additionally, outsourcing verification is not prudent security practice. Therefore an eBGP listener SHOULD NOT strongly trust unsigned security signaling, such as communities, received across a trust boundary. note that this document is advising not crossing a trust boundary carrying data where integrity and authenticity are not protected, while 6810 advises quite the opposite. but if you want to stab me with outsourced security, have a look at draft-ietf-sidr-origin-validation-signaling-10.txt. note that, while i am a co-author, i raised my hum against adopting, progressing, ... it was one of those rock and hard place things. randy From nobody Wed Jan 4 08:48:27 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117C01299C1; Wed, 4 Jan 2017 08:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 AZRFhndIssJL; Wed, 4 Jan 2017 08:48:22 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 3535B1299C0; Wed, 4 Jan 2017 08:48:22 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cOoja-0002PF-Hz; Wed, 04 Jan 2017 16:48:18 +0000 Date: Thu, 05 Jan 2017 01:48:17 +0900 Message-ID: From: Randy Bush To: Stephen Farrell In-Reply-To: References: <148353764984.13034.8506727126675155642.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: The IESG , sidr wg list Subject: Re: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 16:48:23 -0000 > As core BGPsec-capable routers may require large memory and/or modern > CPUs, origin validation based on the Resource Public Key > Infrastructure (RPKI), [RFC6811], will occur over some years and, > once origin validation has been deployed at an AS, then BGPsec > can start to deploy in that AS. > > Though I'm not sure that's precisely right either. let me get back to this tomorrow with coffee. > And to be sure to be sure, none of the above should be blocking > and do feel entirely free to not make any of these changes if > you'd rather not. i made the ones i said i was making, which was most. randy From nobody Wed Jan 4 08:54:10 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB41E1299C8; Wed, 4 Jan 2017 08:54:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148354884869.13006.10827597597769094676.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 08:54:08 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-14.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 16:54:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : BGPsec Operational Considerations Author : Randy Bush Filename : draft-ietf-sidr-bgpsec-ops-14.txt Pages : 9 Date : 2017-01-04 Abstract: Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. It is expected to evolve as BGPsec is formalized and initially deployed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-ops-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 4 08:54:26 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86EDF1299D3; Wed, 4 Jan 2017 08:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 hkPf1l5q4BHt; Wed, 4 Jan 2017 08:54:24 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 AF28A12965F; Wed, 4 Jan 2017 08:54:20 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cOopO-0002RR-8A; Wed, 04 Jan 2017 16:54:18 +0000 Date: Thu, 05 Jan 2017 01:54:15 +0900 Message-ID: From: Randy Bush To: "Ben Campbell" In-Reply-To: <41B2F724-8213-469E-836D-46650503B403@nostrum.com> References: <148348795694.28027.8646303758093237302.idtracker@ietfa.amsl.com> <41B2F724-8213-469E-836D-46650503B403@nostrum.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: The IESG , sidr wg list Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 16:54:25 -0000 > The issue I saw is that section 2 says readers are expected to > understand bgpsec, and cites the overview for that purpose. Perhaps it > should cite the protocol doc for the "expected to understand" part ok. done. i would be happier if that document was easier to read and more concise. i just pushed randy From nobody Wed Jan 4 08:59:00 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458E21299D0; Wed, 4 Jan 2017 08:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 IsJtf1euvUBO; Wed, 4 Jan 2017 08:58:57 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E5D0E1299CE; Wed, 4 Jan 2017 08:58:56 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v04GwrA2061090 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Jan 2017 10:58:54 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Randy Bush" Date: Wed, 04 Jan 2017 10:58:54 -0600 Message-ID: <661F8C18-7B04-4E88-A97A-BBA8314C3FD4@nostrum.com> In-Reply-To: References: <148348795694.28027.8646303758093237302.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: The IESG , sidr wg list Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 16:58:58 -0000 Thanks for the quick response. On 3 Jan 2017, at 20:00, Randy Bush wrote: > thanks for the review. > >> Update: I noted when reviewing other sidr drafts on this telechat >> agenda that this draft treats 2119 keywords differently than the >> other >> drafts. That is, this draft explicitly excludes lower case versions >> of the 2119 keywords > > which is, i believe, the current wisdom; see long discussion on ietf > list. > >> while the other related drafts do not. > > have fun with that. I plan to mention that when I write up my reviews of the other two :-) I agree with the lower case exclusion. I merely thought the working group might want to be consistent on the cluster of drafts. (Assuming they are really a cluster--I could see an argument that the protocol and overview drafts are for a separate audience than the bgp.) [...] > >> -4, first paragraph: I found "either" followed by "and/or" a bit >> confusing. I suggest simply dropping the word "either". > > As described in [I-D.ietf-sidr-rtr-keying] BGPsec-speaking routers > are either capable of generating their own public/private key-pairs > and having their certificates signed and published in the RPKI by > the > RPKI CA system, and/or are given public/private key-pairs by the > operator. > > but the router(s) might not be capable of generating key-pairs. they > might, they might not, the op may generate or not, or both. an absurd > corner case might be that a router with two ASs has the as0 key > stuffed > by the as0 noc, and the as1 key is generated on device because that is > the as1 policy. > I merely meant that "either" seemed odd for non-exclusive options. I take your argument to mean that the options really are non-exclusive. >> -4, last paragraph: "a prudent operator will..." sounds like it might >> be >> worthy of a SHOULD. > > given the previous, how about lower case should That would not seem to change anything :-) My point was that the language seemed stated in a way that _might_ justify a 2119 keyword. If you don't think so, then I'm fine with the current wording. > >> -6, first paragraph: "SHOULD/MUST only" constructions tend to be >> ambiguous. In this case, are we saying SHOULD only originated signed >> announcements, as opposed to unsigned announcements? Or as opposed to >> validating received assignments? If the latter, then the "need not >> validate" seems to weaken the SHOULD. > > An edge site which does not provide transit and trusts its > upstream(s) may only originate a signed prefix announcement and not > validate received announcements. That's much more clear, thanks. [...] > >> -7, paragraph 6: This seems to say that signed paths MUST be signed. >> Does >> the "MUST be signed if sent to external BGP speakers" mean that the >> existing signature must not be stripped (as stated more weakly in the >> previous sentence), or does it mean the sender must re-sign the path? > > Because of possible RPKI version skew, an AS Path which does not > validate at router R0 might validate at R1. Therefore, signed > paths > that are Not Valid and yet propagated (because they are chosen as > best path) should have their signatures left intact and MUST be > signed if sent to external BGPsec speakers. > > i am not seeing where bgpsec stripping was suggested; in fact, the > opposite. if router r0 receives a signed path and intends to pass > that > signed path to the next listener, r0 must sign the path. i am at a > loss > to understand your question. clue bat please. Sorry, I did not mean that stripping was suggested; the previous phrase (non-normatively) recommends against stripping. My question is, since the subject of the sentence is "signed paths" whether the "MUST be signed" language means "MUST NOT strip the signature" (which I suspect to be the case), or something else. > >> -7, paragraph 7: "a signed path learned via iBGP MAY be Not Valid." >> seems like a statement of fact. > > are you suggesting to downcase it? i will assume so. Yes, sorry. > >> -12.2: [I-D.ietf.sider.bgpsec.overview] is mentioned in section 2 as >> needed to understand this document. That suggests it should be a >> normative reference. > > ennie meenie. i think some other reviewer had me push refs around. i > don't have a dog in this fight. my personal opinion would be that > overview is informative and the protocol spec itself is normative. As I mentioned in response to Alvaro's comment: Maybe section 2 should cite the protocol rather than the overview? (Perhaps with a separate mention that the overview is available.) Ben. From nobody Wed Jan 4 10:31:01 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CCF126D74; Wed, 4 Jan 2017 10:30:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148355465867.12949.10785749487953700357.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 10:30:58 -0800 Archived-At: Cc: draft-ietf-sidr-bgpsec-protocol@ietf.org, sidr-chairs@ietf.org, m.waehlisch@fu-berlin.de, sidr@ietf.org Subject: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-bgpsec-protocol-21=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 18:30:59 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- First, thanks for a well written document! A few question on the design; not to propose changes but I would like to learn the reason why the design is as it is: 1) Why do you need to send two different negotiation capabilities for each direction instead of just using two flags in the same capability? And similar why don't you just announce multiple address families in the same capability (using variable length)? 2) Why are the Secure_Path elements and Signature_Block blocks not aligned but in two different lists (given there is and one to one mapping)? Wouldn't it be easier to just update one length field (at a fixed position) and attached the new information at the end? Or to ask the question differently: why is the format as shown in figure 8 not used in the message itself (->this is related to Suresh's question)? Questions on operation: 1) section 5 says "a BGPsec speaker MAY temporarily defer validation of incoming BGPsec update messages". Does this mean it has to remember its state before applying the update message such that is can revert to this state if it later detects that die update message was not valid? Or what action is supposed to happen if the update message is detected as not valid later on 2) sec 4.2 says "Next, the BGPsec speaker generates one or two Signature_Blocks." Are you sure it's at max 2? I guess this depends on the expected update cycles of the algorithm compared to the devices. Given update cycles for devices can be very slow and updates for algorithm can be fast if any security problems are detected, I wouldn't recommend to limit this to two. 3) In relation to the comment above, I'm not a big fan of the algo migration strategy in section 6.1. I understand the problem that all router on the path need to potentially support the algo. However, you do have an negotiation phase. So why don't you the advertise the signing algorithm in the negotiation capabilities? In this case the sender could at least choose to only send the one(s) that is/are also supported by the receiver or not use BGPsec at all if there is no match. However, I also understand that it is probably to late to change anything now and if there is wg consensus, I'm fine with that... 4) section 8.1 says "the recipient of a valid BGPsec update message is assured that the update propagated via the sequence of ASes listed in the Secure_Path portion of the BGPsec_Path attribute." Is that true? It is assured that at least these ASes have been crossed but there might have been others on the path that did not sign the BGPsec_Path attribute, no? 5) Is it really necessary to create registries for "BGPsec Capability" and "BGPsec_Path Flags"? Given this is a really small number of bits/flags, I think new RFCs that update this RFC are enough to define a new use for these so far unused bits. Further, editorial proposals: 1) I would propose to add the Confed_Segment flag in figure 5 (and call the remaining flag field 'reserved') 2) Maybe explain Adj-RIB-In or give a reference to RFCrfc4271 section 1.1 From nobody Wed Jan 4 10:48:14 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC83F129A19 for ; Wed, 4 Jan 2017 10:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 pTQLD6Mx_nxT for ; Wed, 4 Jan 2017 10:48:11 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 615931296C1 for ; Wed, 4 Jan 2017 10:48:11 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id u25so404673843qki.2 for ; Wed, 04 Jan 2017 10:48:11 -0800 (PST) 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=QKXAyqNs2CEC6VdUhWO6eYLlI8Vtp40t3RivjH3BgjI=; b=MHIx9G1D4nF1yvH8OKzuvGsbDFGs7T9JdGfbQvJ+fgWYuOXsRFGgWF35Cr3ZFFFfOq rCLAmxMMDDMaDGtxGHDWjzGJfPIc9D/atGEvRRGUubY6EFguoVlMJU2/ZWdIo+MdRawe XIMVf8Qlrax0Ld6x9J1ayP0qrpsGd41VzleVo= 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=QKXAyqNs2CEC6VdUhWO6eYLlI8Vtp40t3RivjH3BgjI=; b=oqTebN/rXLLc8MLXCKYRE2mQIQr4cbd7IW0jPrJ1wYcixa0IKsHv3Graio8F7oULC4 f+Y/XcNRBCpzzlSWt+ZUBmCwEKtF4F5PVPfxtPPpUSZA8JZUYU4EoF+ZUzvRQgulOSOD ESOIof1i4YbykxPMOmbzbaghrTFPQZBahTK2ARL0i8VtWIZ6PfPT3MYTVdEWUruD6xRs z7old/0vcXOTQIlAu/2mz4J6aVx54rKvKHLyucRWRUej8LDe7thj9menjFot7btFqDc8 JI9XB3ouTw6jElTenznG32gUy0NmjJh4YWNwNPIhkZrGY7KviuLVkuabMiprG8polW8U 4CLg== X-Gm-Message-State: AIkVDXI7YcSf0NwkNNgfd03B8P25JOrjfoi7F3WiIVO5aCxVgZn8nO1+hkZO9+HDrTObZg== X-Received: by 10.55.154.140 with SMTP id c134mr49600416qke.21.1483555690588; Wed, 04 Jan 2017 10:48:10 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id 30sm46317709qth.14.2017.01.04.10.48.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Jan 2017 10:48:09 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> Date: Wed, 4 Jan 2017 13:48:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <58B64FA8-7891-4D84-940B-AB737C3A76D1@sn3rd.com> References: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sidr-chairs@ietf.org, draft-ietf-sidr-bgpsec-protocol@ietf.org, The IESG , m.waehlisch@fu-berlin.de, sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 18:48:13 -0000 > On Jan 4, 2017, at 08:53, Stephen Farrell = wrote: >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-sidr-bgpsec-protocol-21: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 >=20 > I have a couple of fairly straightforward things I'd > like to briefly discuss... >=20 > (1) 3.2/Figure 7: A fixed 20 byte SKI being a sha-1 hash > of the public key is a bad plan, for all the usual > reasons. Why is it ok for that to be hardcoded here when > it could change if/when new alg choices are made for the > RPKI? If it is not too late then I think you should add a > length or alg field to that. If it is too late to do that, > then are we really ok that you will need to rev the BGPsec > version number in order to get rid of all sha-1 code from > your implementation? That seems like a bad plan for a new > protocol. Not sure it absolutely needs a length field; if the RPKI does ever = decide to change to another hash algorithm for SKI, e.g., = SHA-256/384/512, or to change to a hash of the SubjectPublicKeyInfo they = could always the procedures from = https://datatracker.ietf.org/doc/rfc7093/ to generate the values for a = 20-byte value. =20 spt= From nobody Wed Jan 4 11:05:55 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28888129A4D; Wed, 4 Jan 2017 11:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 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, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham 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 DmdSvQhLOA7N; Wed, 4 Jan 2017 11:05:52 -0800 (PST) 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 AB8D1129A41; Wed, 4 Jan 2017 11:05:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0F222BE3E; Wed, 4 Jan 2017 19:05:49 +0000 (GMT) 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 GlFoqfLNbvc1; Wed, 4 Jan 2017 19:05:45 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A433BBE38; Wed, 4 Jan 2017 19:05:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483556745; bh=RX3pTgzIPfTm1hWY+zbrOUSWb7MmGoDg94myr2N30Eo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=x7cAVAR+pR9cHL2nI8SYuwAglJ3opFYXqA6wsSOxlJTTE47Op/kv7uBWIqrb06ajo XD5EgPG4BIfVhdBiSGOwmCBeQDUYEd1RITkOwAXFQFkIKuz9amDZP7wAgvgWUcOcrU q78ZK1P8n3/2qmt6KGAvqbAF47HjVwL4yPz9z6wM= To: Sean Turner References: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> <58B64FA8-7891-4D84-940B-AB737C3A76D1@sn3rd.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 4 Jan 2017 19:05:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <58B64FA8-7891-4D84-940B-AB737C3A76D1@sn3rd.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020107000508000400010605" Archived-At: Cc: sidr-chairs@ietf.org, draft-ietf-sidr-bgpsec-protocol@ietf.org, The IESG , m.waehlisch@fu-berlin.de, sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 19:05:54 -0000 This is a cryptographically signed message in MIME format. --------------ms020107000508000400010605 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 04/01/17 18:48, Sean Turner wrote: >=20 >> On Jan 4, 2017, at 08:53, Stephen Farrell >> wrote: >>=20 >> Stephen Farrell has entered the following ballot position for=20 >> draft-ietf-sidr-bgpsec-protocol-21: Discuss >>=20 >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free to >> cut this introductory paragraph, however.) >>=20 >>=20 >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found >> here:=20 >> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ >>=20 >>=20 >>=20 >> ----------------------------------------------------------------------= >> >>=20 DISCUSS: >> ----------------------------------------------------------------------= >> >> >> >> >>=20 I have a couple of fairly straightforward things I'd >> like to briefly discuss... >>=20 >> (1) 3.2/Figure 7: A fixed 20 byte SKI being a sha-1 hash of the >> public key is a bad plan, for all the usual reasons. Why is it ok >> for that to be hardcoded here when it could change if/when new alg >> choices are made for the RPKI? If it is not too late then I think >> you should add a length or alg field to that. If it is too late to >> do that, then are we really ok that you will need to rev the >> BGPsec version number in order to get rid of all sha-1 code from=20 >> your implementation? That seems like a bad plan for a new=20 >> protocol. >=20 > Not sure it absolutely needs a length field; if the RPKI does ever > decide to change to another hash algorithm for SKI, e.g., > SHA-256/384/512, or to change to a hash of the SubjectPublicKeyInfo > they could always the procedures from > https://datatracker.ietf.org/doc/rfc7093/ to generate the values for > a 20-byte value. Something like that could work I guess e.g. if this draft said "if a router cert contains an SKI that's !=3D 20 bytes long, then here's what you do..." that'd be fine. I'm not sure that's identical to what's in 7093 though but it is close and should be fairly obvious and uncontroversial. I do think it very worthwhile though to not so closely couple the code for generating SKIs with that for BGPsec as they will (I guess) tend to be different codebases not evolving in a tightly coupled manner. Cheers, S. >=20 > spt >=20 --------------ms020107000508000400010605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDQx OTA1NDRaMC8GCSqGSIb3DQEJBDEiBCAnEvcSElyA0eTABqdQsi455aT7LHFh4biWMIaqpIJd tjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBhC9d/0yFDrQjrxfF9WUB7i2B9PKj6oS4TdOsRx0guisndPSgfQDXp OOqt4MGo3/VdSsE5keTkIZXayPGJ4/3hgwdk/5fdZ/Jkz6ihNMPsz7GQBvUxsEMWZHvo8A4a Cr4h0Nihxbgl4frS3hToYbQSWcNLRtD6ZbUgKkl7ULmTVvJjBUdZpEbS/kknzr2NWydNF7i3 oM29OhkLpfkGTlQRXirsyjWpYMbHkc1jpC0sNs08yK+BHKRpwdwxpgqsV/330K7kXiYxWqgF Q3JAAKJwPzrsEjzhbDIicMk+i0NAvbRV13Jg4i39d/5wbW6wJGOZ13if5xH01EFSnAdKpF7e AAAAAAAA --------------ms020107000508000400010605-- From nobody Wed Jan 4 11:10:56 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 028CA12969D; Wed, 4 Jan 2017 11:10:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148355705100.13011.5709768999664450618.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 11:10:51 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-bgpsec-ops@ietf.org, sidr@ietf.org Subject: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 19:10:51 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-sidr-bgpsec-ops-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Again, thanks for a very readable document. I did have one question - I saw that you're chatting about the same paragraph with Alissa, but I'm wondering if "the transitive closure of a client's customers" has a precise meaning. I know what a customer is, at the hand-waving level, but I'm not sure how I would know whether any particular case fit that description, at the corner-case level. Is "customer" being used a shorthand for another term that isn't depending on an economic transaction? (If this was "the transitive closure of a client's clients", for instance, I would know what that meant - and I'm not at all suggesting that's correct, only offering it as an example of the kind of thing I'm asking about) From nobody Wed Jan 4 11:22:52 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E688129A7E for ; Wed, 4 Jan 2017 11:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable 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 SKy_bUsvyUS6 for ; Wed, 4 Jan 2017 11:22:49 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47FF2129A40 for ; Wed, 4 Jan 2017 11:22:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DFBBB30042F for ; Wed, 4 Jan 2017 14:12:32 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LsHZ_rbXF9t4 for ; Wed, 4 Jan 2017 14:12:31 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 59138300278; Wed, 4 Jan 2017 14:12:31 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> Date: Wed, 4 Jan 2017 14:24:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IESG , IETF SIDR Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 19:22:51 -0000 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I have a couple of fairly straightforward things I'd > like to briefly discuss... >=20 > [snip] >=20 > (3) section 8: Is there a potential exposure here in that > a relying party who emits e.g. certificate status checks > or cert retrieval queries for an RPKI cert they've not > previously seen is exposing something about the set of > paths its traffic is likely to follow. (This is similar to > why we have OCSP stapling in the web.) IIRC the RPKI specs > may cover this but I suspect it'd be worth noting here as > well even if so as this represents exposing something > about BGP announcement content to off-path parties which I > think is new for BGP. Is that a new thing for BGP? (I > think the new aspect to the attack is that a bad actor who > has already compromised some AS could more easily spot > that traffic from the relying party's AS is likely to > transit the compromised AS.) I am not sure what you mean by a "compromised AS,=94 but it may not = matters =85 If a link goes down, and that causes an alternative path to be selected, = that forces the validation a new path which might involve a previously = unvalidated AS. If an OCSP responder or repository that provides RPKI = objects is contacted as part of that validation, then some external = entities can detect that something is changing. That is, stuff not = normally validated because it is associated with a unselected path gets = fetched. That said, the NOC could fetch a snapshot of the RPKI, then the exposure = of the switch to a new path can be limited to that AS. This assumes = that the snapshot uses CRLs, which seems like a very reasonable choice = in the RPKI. Russ From nobody Wed Jan 4 11:33:08 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F7D1296AD; Wed, 4 Jan 2017 11:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 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, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham 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 uxkgpm2rc-P6; Wed, 4 Jan 2017 11:33:05 -0800 (PST) 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 216DC1296A6; Wed, 4 Jan 2017 11:33:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 99731BE38; Wed, 4 Jan 2017 19:33:02 +0000 (GMT) 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 ei6B3sEn3KrK; Wed, 4 Jan 2017 19:33:01 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 97810BE2E; Wed, 4 Jan 2017 19:33:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483558381; bh=cUoQWEFyLGMPI/uRSrggVmhbkPUbLiQ4tXyv2Ysgkmg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=EqJM5KqW9G7ZKDy73xW3qUFG5GNN0zaIQ1LKMqEIR+PggqaNILL38sTTlXx+ilhz/ CgRQhEnJwdORUNxftfHAazn7QQ6937hL34a7lAg5D7DQHl9i3iHzUvIbnD8IgMJrq9 F/pQVfir4YaL5vPt33wx2QcVuVO+SIhzWxhQnVs8= To: Russ Housley References: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <3ae7d707-3229-2508-7aeb-2cd617aa97fd@cs.tcd.ie> Date: Wed, 4 Jan 2017 19:33:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030103080806050205040504" Archived-At: Cc: IESG , IETF SIDR Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 19:33:07 -0000 This is a cryptographically signed message in MIME format. --------------ms030103080806050205040504 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/01/17 19:24, Russ Housley wrote: >=20 >> ----------------------------------------------------------------------= >> >>=20 DISCUSS: >> ----------------------------------------------------------------------= >> >> >>=20 I have a couple of fairly straightforward things I'd >> like to briefly discuss... >>=20 >> [snip] >>=20 >> (3) section 8: Is there a potential exposure here in that a relying >> party who emits e.g. certificate status checks or cert retrieval >> queries for an RPKI cert they've not previously seen is exposing >> something about the set of paths its traffic is likely to follow. >> (This is similar to why we have OCSP stapling in the web.) IIRC the >> RPKI specs may cover this but I suspect it'd be worth noting here >> as well even if so as this represents exposing something about BGP >> announcement content to off-path parties which I think is new for >> BGP. Is that a new thing for BGP? (I think the new aspect to the >> attack is that a bad actor who has already compromised some AS >> could more easily spot that traffic from the relying party's AS is >> likely to transit the compromised AS.) >=20 > I am not sure what you mean by a "compromised AS,=E2=80=9D but it may n= ot > matters =E2=80=A6 More or less if traffic to/from ASxxxx is visible to an attacker and/or can be modified by an attacker. That could be due to collusion between the AS and an attacker for example, or because an attacker has compromised some routers within a transit AS. >=20 > If a link goes down,=20 I'm not sure this is only if a link goes down. I'd guess the same risk would exist when any BGPsec path is first seen at a relying party and where that RP doesn't have all the necessary RPKI stuff cached before signature validation. =2E and that causes an alternative path to be > selected, that forces the validation a new path which might involve a > previously unvalidated AS. If an OCSP responder or repository that > provides RPKI objects is contacted as part of that validation, then > some external entities can detect that something is changing. That > is, stuff not normally validated because it is associated with a > unselected path gets fetched. Right. Sorry to not be clearer on what might become visible to the network outside the RP's AS - I'm afraid I just don't have all the RPKI details in my head;-) >=20 > That said, the NOC could fetch a snapshot of the RPKI, then the > exposure of the switch to a new path can be limited to that AS. This > assumes that the snapshot uses CRLs, which seems like a very > reasonable choice in the RPKI. Right, I think all that'd be needed for this would be to ack that there's this (normally fairly minor) new risk and that you can avoid it if you pre-fetch enough stuff. (As a separate question, I wonder if the amount of stuff involved in the RPKI is such that it'd be fairly easy to pre-fetch it all frequently enough to nearly never hit this problem.) Cheers, S. >=20 > Russ >=20 --------------ms030103080806050205040504 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDQx OTMzMDBaMC8GCSqGSIb3DQEJBDEiBCBWl1TjQIiAY6EekfNr3qqiULoh+17d5QcQUpe9DL5Y 2zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAdWy1Mw3anNEIkgCxgt7BZbIYv6btzKzEpEWrMFmyGPxiEqvmlwPUo TSzW204a05dFlFRWXjxioUXKwlSiDpr8r1HSZeY9t+4ZtCsdHVibGeWMB3YUJFpp/tXTZg/L wLbo0dp38axohlWZ65CFBFYEsl4Gh3jRH6GjhAiWbzB1lNaIhOhjTlvdH3zTiVHne5KStW+w aM5+wSpOzWYhahKzg1WitXzB9BvLxlccMqYqd85EZECqH7YTts+5/+faVC5RFr7Za2+eHODG UCqcbZvmpdYEY3sgJZkdCe0VlGdxugPeIlWs52ouLdDMo/J1hEY507AIr/ri4vGr8cNd5MOm AAAAAAAA --------------ms030103080806050205040504-- From nobody Wed Jan 4 11:57:53 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481EF1293FE for ; Wed, 4 Jan 2017 11:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 T_t2iW-sR4Al for ; Wed, 4 Jan 2017 11:57:49 -0800 (PST) Received: from nm42-vm7.bullet.mail.ne1.yahoo.com (nm42-vm7.bullet.mail.ne1.yahoo.com [98.138.121.63]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF75B129446 for ; Wed, 4 Jan 2017 11:57:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1483559866; bh=Dd5ikLnkejtQT3RCLYcFr6FwgTh5as6y5SAuSkrMF14=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=RuuWPbY2SYNnhg1gnJKTPJmx/8p54wCfD7S9Frlj9YeixLyzSWM9j95fpSkHjPhT0NkE4tL/Ohw7PLVOGiBU06dsYo/G7vOlG5pyRoaw9x3t7ri41oNKby7FP7+nOJ2zQuMG/W7yxvPkt4x/q/3MJSdCZpgp5v9IT/0W4R7ZOtbcmC/ixDCh8KFifxZPBLGSCcZCwiYTWkWyUW4BfOH5Vh4LCKGQYv8VZ5rbF9T7mJGCbXCgvK1qUCGDMaP2b7RaHP5h4n7O3Y1KOHfZlxK7hvE++nvGphjGf3vE4uosZb0Sv7MxfELhMdS+lSLUSmBJJZXENGDd+BHK1aAEllKiCg== Received: from [127.0.0.1] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jan 2017 19:57:46 -0000 Received: from [98.138.100.116] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jan 2017 19:55:03 -0000 Received: from [98.138.88.238] by tm107.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jan 2017 19:55:03 -0000 Received: from [127.0.0.1] by omp1038.mail.ne1.yahoo.com with NNFMP; 04 Jan 2017 19:55:03 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 710005.64822.bm@omp1038.mail.ne1.yahoo.com X-YMail-OSG: vAF9iukVM1lt0MrZ6weYLNT_mp2HRYkjXOEeTGz2LysT.6nKfpZoc5VfD4JYEX1 h5QAUi.HvoHg01tr6pEiIx18R53MAadT_l1cFBeChfRuyIFjGsu34O8bIETkKMJ_6YuLadxDQ73s Ic0SwYeJh_VBwnHlc9DDDD_qe_GoYGNvfhEMwJctrUz3ZuVfFuWmY4qZGR0ZSADizPIb2Uc.E5oR 0D.XeYzhUJRanV7lYzs1d9_Uyh6RH2dUhTu34Iu5jeX2yqYyas9QShWY4lso0zd6T.r4QrmWN1uA DiI.EaGJNUuUgBLJxYvl1K3Rdy7.i2p_vBrjhDsGJ.dR9UfPA7LgTNpT89OS8e2oq_2KAearnmJO cdZ8MX8cd82rqXVgQLetVx5aNisZ9PQWO_2SQj55q_XBG5sbnXqhboNlWjKWoJE0oc9B7xHuoOZw Pqkn3i.6DAohaOQGNm76Lu9nVxuQRO2MwzWXHXnOky6sIcDVdKvqio7O.k9toqtv7rIpquUL8jwC Qtlp0Sg5O2qzOJPMrT5cCQZl3gbhpL9UnFUkzqJ3X24GmqfT4WMc63q7huCSx Received: from jws200165.mail.ne1.yahoo.com by sendmailws154.mail.ne1.yahoo.com; Wed, 04 Jan 2017 19:55:03 +0000; 1483559703.317 Date: Wed, 4 Jan 2017 19:54:37 +0000 (UTC) From: "Mehmet Adalier (Antara Teknik)" To: Sean Turner , Stephen Farrell Message-ID: <1671316103.6220736.1483559677229@mail.yahoo.com> In-Reply-To: <58B64FA8-7891-4D84-940B-AB737C3A76D1@sn3rd.com> References: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> <58B64FA8-7891-4D84-940B-AB737C3A76D1@sn3rd.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6220735_1764543738.1483559677222" Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , "sidr-chairs@ietf.org" , The IESG , "m.waehlisch@fu-berlin.de" , "sidr@ietf.org" Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Mehmet Adalier \(Antara Teknik\)" List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 19:57:50 -0000 ------=_Part_6220735_1764543738.1483559677222 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable while i would also like to see less use of=C2=A0sha-1 in new network protoc= ols... limiting the SKI length to a fixed 20 bytes is not really a bad idea for im= plementation efficiency and interoperability. as Sean points out, rfc7093's straight forward (leftmost 160 bits --20bytes= ) of a SHA-2 algorithm digest works well for the use of a hash value in thi= s particular context (generating Key Identifiers).. mA From: Sean Turner To: Stephen Farrell =20 Cc: sidr-chairs@ietf.org; draft-ietf-sidr-bgpsec-protocol@ietf.org; The IES= G ; m.waehlisch@fu-berlin.de; sidr@ietf.org Sent: Wednesday, January 4, 2017 10:48 AM Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pr= otocol-21: (with DISCUSS and COMMENT) =20 > On Jan 4, 2017, at 08:53, Stephen Farrell wro= te: >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-sidr-bgpsec-protocol-21: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 >=20 > I have a couple of fairly straightforward things I'd > like to briefly discuss... >=20 > (1) 3.2/Figure 7: A fixed 20 byte SKI being a sha-1 hash > of the public key is a bad plan, for all the usual > reasons. Why is it ok for that to be hardcoded here when > it could change if/when new alg choices are made for the > RPKI? If it is not too late then I think you should add a > length or alg field to that. If it is too late to do that, > then are we really ok that you will need to rev the BGPsec > version number in order to get rid of all sha-1 code from > your implementation? That seems like a bad plan for a new > protocol. Not sure it absolutely needs a length field; if the RPKI does ever decide t= o change to another hash algorithm for SKI, e.g., SHA-256/384/512, or to ch= ange to a hash of the SubjectPublicKeyInfo they could always the procedures= from https://datatracker.ietf.org/doc/rfc7093/ to generate the values for = a 20-byte value.=C2=A0=20 spt _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr =20 ------=_Part_6220735_1764543738.1483559677222 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
while i would also like to see less use of sha-1 in new network protocols...

limiting the SKI length to a fixed 20 bytes is not = really a bad idea for implementation efficiency and interoperability.
=

as Sean points o= ut, rfc7093's straight forward (leftmost 160 bits --20bytes) of a SHA-2 alg= orithm digest works well for the use of a hash value in this particular con= text (generating Key Identifiers)..

mA
From: Sean Turner <sean@sn3rd.com><= br> To: Stephen Farrell &l= t;stephen.farrell@cs.tcd.ie>
C= c: sidr-chairs@ietf.org; draft-ietf-sidr-bgpsec-protocol@ietf.or= g; The IESG <iesg@ietf.org>; m.waehlisch@fu-berlin.de; sidr@ietf.org<= br> Sent: W= ednesday, January 4, 2017 10:48 AM

<= br clear=3D"none">> On Jan 4, 2017, at 08:53, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>
> Stephen Farrell has entered the foll= owing ballot position for
> draft-ietf-sidr-bgpsec-pro= tocol-21: Discuss
>
> When respo= nding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut = this
> introductory paragraph, however.)
>
>
> Please refer to <= a shape=3D"rect" href=3D"https://www.ietf.org/iesg/statement/discuss-criter= ia.html" target=3D"_blank">https://www.ietf.org/iesg/statement/discuss-crit= eria.html
> for more information about IESG DISCUS= S and COMMENT positions.
>
> > The document, along with other ballot positions, can b= e found here:
> ht= tps://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/
>
>
>
> ------------------------------------------------------------= ----------
> DISCUSS:
> ---------= -------------------------------------------------------------
>
>
>
> I have a couple of fairly straightforward things I'd
> like to briefly discuss...
>
> (1) 3.2/Figure 7: A fixed 20 byte SKI being a sha-1 hash
> of the public key is a bad plan, for all the usual
> reasons. Why is it ok for that to be hardcoded here when
> it could change if/when new alg choices are made for the> RPKI? If it is not too late then I think you should ad= d a
> length or alg field to that. If it is too late t= o do that,
> then are we really ok that you will need = to rev the BGPsec
> version number in order to get rid= of all sha-1 code from
> your implementation? That se= ems like a bad plan for a new
> protocol.

Not sure it absolutely needs a length field; if th= e RPKI does ever decide to change to another hash algorithm for SKI, e.g., = SHA-256/384/512, or to change to a hash of the SubjectPublicKeyInfo they co= uld always the procedures from https://datatracker.ietf.org/doc= /rfc7093/ to generate the values for a 20-byte value. 

spt

_______________________________________________
sidr mailing list
sidr@ietf.orghttps://www.ietf.org/mailman/listinfo/sidr


= ------=_Part_6220735_1764543738.1483559677222-- From nobody Wed Jan 4 12:00:28 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A917129ACD; Wed, 4 Jan 2017 12:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 zx8mfzlD5rNQ; Wed, 4 Jan 2017 12:00:18 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0101.outbound.protection.outlook.com [23.103.200.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABCA2129ADE; Wed, 4 Jan 2017 12:00:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=X/RRNlguF/W1FTuktM+3IS3YyEVVNwU9wCbwy90qKLk=; b=tC2dQ3j/lC1c6BuZq0TIkJgmAkcaYet7BIsr2THeVeDzQMENzbiFeRgCpfI8KFqwZfiMvT19QFNgCamGX9HyFzRTZJ8qXFSja0Ydrd9wf1s0yd+670XWuWxG54aEjUtJri+fGc5qQwNUVZR/HFVPdxwKY/eHIvHORYaKpP2X22I= Received: from BN6PR09MB1426.namprd09.prod.outlook.com (10.173.202.14) by BN6PR09MB1425.namprd09.prod.outlook.com (10.173.202.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Wed, 4 Jan 2017 20:00:14 +0000 Received: from BN6PR09MB1426.namprd09.prod.outlook.com ([10.173.202.14]) by BN6PR09MB1426.namprd09.prod.outlook.com ([10.173.202.14]) with mapi id 15.01.0829.003; Wed, 4 Jan 2017 20:00:13 +0000 From: "Montgomery, Douglas (Fed)" To: Stephen Farrell , Russ Housley Thread-Topic: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) Thread-Index: AQHSZpHm+sFsRlTcAUq59z5oqx6cVKEosxWAgAACfgD//7O6AA== Importance: low X-Priority: 5 Date: Wed, 4 Jan 2017 20:00:13 +0000 Message-ID: References: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> <3ae7d707-3229-2508-7aeb-2cd617aa97fd@cs.tcd.ie> In-Reply-To: <3ae7d707-3229-2508-7aeb-2cd617aa97fd@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: spf=none (sender IP is ) smtp.mailfrom=dougm@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.140.29] x-microsoft-exchange-diagnostics: 1; BN6PR09MB1425; 7:GRC7guWASnerbXE1JbbfImeqxPEfkBIYZPizbC5k3fx0OSHqFLGXlxLJ12e+catPmZMIJgquutpon47ROkoqL41UKrLlzlpqgBnlaAgQwm6FYqiqbSFWZo6LBZ+TkJtE8ZzSxmKn3Kp7aZDlXF9otVOmtrDkhRiVFEUxRrw4Zf64/dy5xH+/0d12U6pD3knjddYfaoaYCxittiKcYdQdN3zl5H2CC9HoXEodd75Jpg2v5/IkBkYso+Ly4nRbi9qqyB8BIFu/TlfRk1Kwa2cLibnVH0joHqzxD5D0Nafurg5Wxq/4dGky5zT5Gn76+MbQoRv3Q/ojEgAAo3yf2G8gIQZXIOwGrVRH4dYPA8x1lA328ALdY2yMaVr39wlexaapwps3jDL2lPmRtw6/HnW58Al1QkWz0jSAzjT4rBDmoVWAMR7Rx1/ZZJN5/bLoenru2bIYGByes7Y0qxBHK6l1hg== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39450400003)(39410400002)(39860400002)(39840400002)(54094003)(377454003)(189002)(24454002)(199003)(2950100002)(6486002)(5660300001)(101416001)(4326007)(2900100001)(2906002)(83506001)(5001770100001)(3280700002)(81156014)(7736002)(81166006)(8676002)(122556002)(229853002)(68736007)(4001350100001)(50986999)(3846002)(102836003)(25786008)(81686999)(92566002)(6436002)(6116002)(54356999)(54906002)(8936002)(66066001)(76176999)(97736004)(36756003)(189998001)(230783001)(106356001)(86362001)(99286003)(105586002)(106116001)(38730400001)(6506006)(305945005)(77096006)(3660700001)(6512006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR09MB1425; H:BN6PR09MB1426.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 0f62757b-a93e-4d04-6c27-08d434dc4bfe x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR09MB1425; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123564025)(20161123558021)(20161123555025)(20161123560025)(6072148); SRVR:BN6PR09MB1425; BCL:0; PCL:0; RULEID:; SRVR:BN6PR09MB1425; x-forefront-prvs: 0177904E6B received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2017 20:00:13.6815 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR09MB1425 Archived-At: Cc: IESG , IETF SIDR Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 20:00:21 -0000 U3RlcGhlbiwNCg0KSWYgSSB1bmRlcnN0YW5kIHlvdXIgcXVlc3Rpb24sIEkgZG9u4oCZdCB0aGlu ayBvbmUgY2FuIGluZmVyIGFueXRoaW5nIGFib3V0DQp0aGUgQkdQIGZlZWRzIG9yIHJvdXRlIHNl bGVjdGlvbiBwcm9jZXNzZXMgb2YgYW4gQVMgYmFzZWQgdXBvbiB0aGUgdHJhZmZpYw0KYSB2YWxp ZGF0aW5nIGNhY2hlIHNlbmRzIHRvIFJQS0kgcmVwb3NpdG9yaWVzLg0KDQpUaGUgZGVzaWduIG9m IFJQS0kgdmFsaWRhdGluZyBjYWNoZXMgKGFuZCBhbGwgaW1wbGVtZW50YXRpb25zIHRoYXQgSSBr bm93DQpvZikgcHJlZmV0Y2ggYW5kIHZhbGlkYXRlIFJQS0kgb2JqZWN0cyBpbmRlcGVuZGVudCBv ZiBCR1AgdHJhZmZpYw0KcHJvY2Vzc2luZy4gICBUaGF0IGlzLCB0aGV5IGFyZSBiYWNrZ3JvdW5k IHByb2Nlc3NpbmcgdGhlIGVudGlyZSBSUEtJLCBhbmQNCmFyZSBub3QgZXZlbnQgZHJpdmVuIGJ5 IEJHUCB0cmFmZmljLiAgQXMgYSBtYXR0ZXIgb2YgZmFjdCwgdGhlIFJQS0kNCnZhbGlkYXRpbmcg Y2FjaGXigJlzIGFyZSB0eXBpY2FsbHkgb24gc3lzdGVtcyB0aGF0IGhhdmUgbm8gcmVhc29uIHRv DQppbXBsZW1lbnQgQkdQIGF0IGFsbC4NCg0KQWxzbyB0aGUgUlBLSS10by1SdHIgcHJvdG9jb2wg YmV0d2VlbiB0aGUgY2FjaGUgYW5kIHJvdXRlciBpcyBiYXRjaCBkcml2ZW4NCihyb3VnaGx5KSBi eSB0aGUgdmFsaWRhdGlvbiBwcm9jZXNzLCBub3QgQkdQIGV2ZW50IGRyaXZlbi4NCg0KSS5lLiwg dGhlIFJQS0kgdHJhZmZpYyB0byBhIHZhbGlkYXRpbmcgY2FjaGUgaW4gYW4gQVMgd2l0aCBubyBC R1AgZmVlZHMNCmFuZCBvbmUgd2l0aCBmdWxsIEJHUCBmZWVkcyBpcyB0aGUgc2FtZSwgYW5kIGJv dGggaW5kZXBlbmRlbnQgb2YgQkdQIGV2ZW50DQpwcm9jZXNzaW5nLg0KDQpJZiB0aGF0IHdhcyBu b3QgdGhlIHN1cHBvc2l0aW9uIG9mIHlvdXIgcXVlc3Rpb24g4oCmIHBsZWFzZSBpZ25vcmUuDQpk b3VnbQ0KDQoNCg0KDQrigJQgDQpEb3VnIE1vbnRnb21lcnksIE1nciBJbnRlcm5ldCAmIFNjYWxh YmxlIFN5c3RlbXMgUmVzZWFyY2ggYXQgIE5JU1QvSVRML0FOVEQNCg0KDQoNCg0KDQpPbiAxLzQv MTcsIDI6MzMgUE0sICJzaWRyIG9uIGJlaGFsZiBvZiBTdGVwaGVuIEZhcnJlbGwiDQo8c2lkci1i b3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPiB3 cm90ZToNCg0KPg0KPg0KPk9uIDA0LzAxLzE3IDE5OjI0LCBSdXNzIEhvdXNsZXkgd3JvdGU6DQo+ PiANCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4NCj4+PiANCj5ESVNDVVNTOg0KPj4+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4+Pg0KPj4+DQo+Pj4gDQo+SSBoYXZlIGEgY291cGxlIG9mIGZhaXJseSBzdHJhaWdo dGZvcndhcmQgdGhpbmdzIEknZA0KPj4+IGxpa2UgdG8gYnJpZWZseSBkaXNjdXNzLi4uDQo+Pj4g DQo+Pj4gW3NuaXBdDQo+Pj4gDQo+Pj4gKDMpIHNlY3Rpb24gODogSXMgdGhlcmUgYSBwb3RlbnRp YWwgZXhwb3N1cmUgaGVyZSBpbiB0aGF0IGEgcmVseWluZw0KPj4+IHBhcnR5IHdobyBlbWl0cyBl LmcuICBjZXJ0aWZpY2F0ZSBzdGF0dXMgY2hlY2tzIG9yIGNlcnQgcmV0cmlldmFsDQo+Pj4gcXVl cmllcyBmb3IgYW4gUlBLSSBjZXJ0IHRoZXkndmUgbm90IHByZXZpb3VzbHkgc2VlbiBpcyBleHBv c2luZw0KPj4+IHNvbWV0aGluZyBhYm91dCB0aGUgc2V0IG9mIHBhdGhzIGl0cyB0cmFmZmljIGlz IGxpa2VseSB0byBmb2xsb3cuDQo+Pj4gKFRoaXMgaXMgc2ltaWxhciB0byB3aHkgd2UgaGF2ZSBP Q1NQIHN0YXBsaW5nIGluIHRoZSB3ZWIuKSBJSVJDIHRoZQ0KPj4+IFJQS0kgc3BlY3MgbWF5IGNv dmVyIHRoaXMgYnV0IEkgc3VzcGVjdCBpdCdkIGJlIHdvcnRoIG5vdGluZyBoZXJlDQo+Pj4gYXMg d2VsbCBldmVuIGlmIHNvIGFzIHRoaXMgcmVwcmVzZW50cyBleHBvc2luZyBzb21ldGhpbmcgYWJv dXQgQkdQDQo+Pj4gYW5ub3VuY2VtZW50IGNvbnRlbnQgdG8gb2ZmLXBhdGggcGFydGllcyB3aGlj aCBJIHRoaW5rIGlzIG5ldyBmb3INCj4+PiBCR1AuIElzIHRoYXQgYSBuZXcgdGhpbmcgZm9yIEJH UD8gKEkgdGhpbmsgdGhlIG5ldyBhc3BlY3QgdG8gdGhlDQo+Pj4gYXR0YWNrIGlzIHRoYXQgYSBi YWQgYWN0b3Igd2hvIGhhcyBhbHJlYWR5IGNvbXByb21pc2VkIHNvbWUgQVMNCj4+PiBjb3VsZCBt b3JlIGVhc2lseSBzcG90IHRoYXQgdHJhZmZpYyBmcm9tIHRoZSByZWx5aW5nIHBhcnR5J3MgQVMg aXMNCj4+PiBsaWtlbHkgdG8gdHJhbnNpdCB0aGUgY29tcHJvbWlzZWQgQVMuKQ0KPj4gDQo+PiBJ IGFtIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgYSAiY29tcHJvbWlzZWQgQVMs4oCdIGJ1dCBp dCBtYXkgbm90DQo+PiBtYXR0ZXJzIOKApg0KPg0KPk1vcmUgb3IgbGVzcyBpZiB0cmFmZmljIHRv L2Zyb20gQVN4eHh4IGlzIHZpc2libGUgdG8gYW4NCj5hdHRhY2tlciBhbmQvb3IgY2FuIGJlIG1v ZGlmaWVkIGJ5IGFuIGF0dGFja2VyLiBUaGF0IGNvdWxkDQo+YmUgZHVlIHRvIGNvbGx1c2lvbiBi ZXR3ZWVuIHRoZSBBUyBhbmQgYW4gYXR0YWNrZXIgZm9yDQo+ZXhhbXBsZSwgb3IgYmVjYXVzZSBh biBhdHRhY2tlciBoYXMgY29tcHJvbWlzZWQgc29tZSByb3V0ZXJzDQo+d2l0aGluIGEgdHJhbnNp dCBBUy4NCj4NCj4+IA0KPj4gSWYgYSBsaW5rIGdvZXMgZG93biwNCj4NCj5JJ20gbm90IHN1cmUg dGhpcyBpcyBvbmx5IGlmIGEgbGluayBnb2VzIGRvd24uIEknZCBndWVzcyB0aGUgc2FtZQ0KPnJp c2sgd291bGQgZXhpc3Qgd2hlbiBhbnkgQkdQc2VjIHBhdGggaXMgZmlyc3Qgc2VlbiBhdCBhIHJl bHlpbmcNCj5wYXJ0eSBhbmQgd2hlcmUgdGhhdCBSUCBkb2Vzbid0IGhhdmUgYWxsIHRoZSBuZWNl c3NhcnkgUlBLSSBzdHVmZg0KPmNhY2hlZCBiZWZvcmUgc2lnbmF0dXJlIHZhbGlkYXRpb24uDQo+ DQo+LiBhbmQgdGhhdCBjYXVzZXMgYW4gYWx0ZXJuYXRpdmUgcGF0aCB0byBiZQ0KPj4gc2VsZWN0 ZWQsIHRoYXQgZm9yY2VzIHRoZSB2YWxpZGF0aW9uIGEgbmV3IHBhdGggd2hpY2ggbWlnaHQgaW52 b2x2ZSBhDQo+PiBwcmV2aW91c2x5IHVudmFsaWRhdGVkIEFTLiAgSWYgYW4gT0NTUCByZXNwb25k ZXIgb3IgcmVwb3NpdG9yeSB0aGF0DQo+PiBwcm92aWRlcyBSUEtJIG9iamVjdHMgaXMgY29udGFj dGVkIGFzIHBhcnQgb2YgdGhhdCB2YWxpZGF0aW9uLCB0aGVuDQo+PiBzb21lIGV4dGVybmFsIGVu dGl0aWVzIGNhbiBkZXRlY3QgdGhhdCBzb21ldGhpbmcgaXMgY2hhbmdpbmcuICBUaGF0DQo+PiBp cywgc3R1ZmYgbm90IG5vcm1hbGx5IHZhbGlkYXRlZCBiZWNhdXNlIGl0IGlzIGFzc29jaWF0ZWQg d2l0aCBhDQo+PiB1bnNlbGVjdGVkIHBhdGggZ2V0cyBmZXRjaGVkLg0KPg0KPlJpZ2h0LiBTb3Jy eSB0byBub3QgYmUgY2xlYXJlciBvbiB3aGF0IG1pZ2h0IGJlY29tZSB2aXNpYmxlIHRvDQo+dGhl IG5ldHdvcmsgb3V0c2lkZSB0aGUgUlAncyBBUyAtIEknbSBhZnJhaWQgSSBqdXN0IGRvbid0IGhh dmUgYWxsDQo+dGhlIFJQS0kgZGV0YWlscyBpbiBteSBoZWFkOy0pDQo+DQo+PiANCj4+IFRoYXQg c2FpZCwgdGhlIE5PQyBjb3VsZCBmZXRjaCBhIHNuYXBzaG90IG9mIHRoZSBSUEtJLCB0aGVuIHRo ZQ0KPj4gZXhwb3N1cmUgb2YgdGhlIHN3aXRjaCB0byBhIG5ldyBwYXRoIGNhbiBiZSBsaW1pdGVk IHRvIHRoYXQgQVMuICBUaGlzDQo+PiBhc3N1bWVzIHRoYXQgdGhlIHNuYXBzaG90IHVzZXMgQ1JM cywgd2hpY2ggc2VlbXMgbGlrZSBhIHZlcnkNCj4+IHJlYXNvbmFibGUgY2hvaWNlIGluIHRoZSBS UEtJLg0KPg0KPlJpZ2h0LCBJIHRoaW5rIGFsbCB0aGF0J2QgYmUgbmVlZGVkIGZvciB0aGlzIHdv dWxkIGJlIHRvIGFjayB0aGF0DQo+dGhlcmUncyB0aGlzIChub3JtYWxseSBmYWlybHkgbWlub3Ip IG5ldyByaXNrIGFuZCB0aGF0IHlvdSBjYW4NCj5hdm9pZCBpdCBpZiB5b3UgcHJlLWZldGNoIGVu b3VnaCBzdHVmZi4gKEFzIGEgc2VwYXJhdGUgcXVlc3Rpb24sDQo+SSB3b25kZXIgaWYgdGhlIGFt b3VudCBvZiBzdHVmZiBpbnZvbHZlZCBpbiB0aGUgUlBLSSBpcyBzdWNoIHRoYXQNCj5pdCdkIGJl IGZhaXJseSBlYXN5IHRvIHByZS1mZXRjaCBpdCBhbGwgZnJlcXVlbnRseSBlbm91Z2ggdG8NCj5u ZWFybHkgbmV2ZXIgaGl0IHRoaXMgcHJvYmxlbS4pDQo+DQo+Q2hlZXJzLA0KPlMuDQo+DQo+PiAN Cj4+IFJ1c3MNCj4+IA0KPg0KDQo= From nobody Wed Jan 4 12:04:16 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA25129458; Wed, 4 Jan 2017 12:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 aXiobIDk_ACJ; Wed, 4 Jan 2017 12:04:13 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A844C12958E; Wed, 4 Jan 2017 12:04:13 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 5F32313998; Wed, 4 Jan 2017 20:04:12 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 1DFD04581178; Wed, 4 Jan 2017 15:04:13 -0500 (EST) Date: Wed, 04 Jan 2017 15:04:13 -0500 From: Rob Austein To: "Stephen Farrell" In-Reply-To: <148353788046.13042.160471261406266.idtracker@ietfa.amsl.com> References: <148353788046.13042.160471261406266.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170104200413.1DFD04581178@minas-ithil.hactrn.net> Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 20:04:15 -0000 [Not the author, but...] At Wed, 04 Jan 2017 05:51:20 -0800, Stephen Farrell wrote: ... > I have a few probably quick things I'd like to discuss for > this one: > > (1) 3.1.1: Why MUST a CA ensure that the CA name and > Subject name combination is unique? I don't see what'd > break in BGPsec if that rule is omitted, but maybe I'm > missing something. > > (2) 3.1.1: Similarly, I'm not clear why only common name > and serial number are allowed in Subject. Why is that > needed for interop? (I can see that you want to say that > code MUST support those but not why you want to prevent > other things.) This draft is a profile of RFC 6487, which is itself a profile of RFC 5280. All of the above is pretty much verbatim from RFC 6487. > (3) Where's certificate status checking covered? What's > expected for BGPsec router certs? If BGPsec speakers are > intended to inherit the CRL checking from 6487 then being > explicit about that would probably be worthwhile. Yes, I think this too is inherited from RFC 6487. > And I'd wonder if router cert revocation will be more common than > for other resource certs, in which case an OCSP-like system could be > needed - did the WG consider that? Not as such. Fair question, but the architecture kind of assumes that the RPKI RP process is separable from the BGPSEC implementation per se, BGPSEC just consumes the output of that process. Most likely implementation technique does all the RPKI stuff per se on a separate box and just stuffs the resulting raw keys into the router using the rpki-rtr protocol, so the router itself probably would not have the information needed to play OCSP even if it wanted to do so, which it probably doesn't. Requiring the routers to speak OCSP seems like a potentially dangerous layering violation. From nobody Wed Jan 4 12:48:09 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F241295DB; Wed, 4 Jan 2017 12:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 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, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham 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 g-ECvodoKFzO; Wed, 4 Jan 2017 12:48:06 -0800 (PST) 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 F08F9129428; Wed, 4 Jan 2017 12:48:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A5A4CBE47; Wed, 4 Jan 2017 20:48:04 +0000 (GMT) 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 0cvses2CebML; Wed, 4 Jan 2017 20:48:03 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7133CBE3E; Wed, 4 Jan 2017 20:48:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483562883; bh=Hnd/a8qUjGTZZ0a/zL7r0+jHs0sJMtYjy+hDPrwQ1jM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=sBa4veHVyLm/B1FWVhQFVJ5dNvdDkKZq6+16Tc9xPB1xZ7cE2bsQmBfwiiZOI/lsj 3cprsrRMF2BCAW7KzEhd3Ak/mhhvkj8PZLsZxv/5SjBfGjYlcaK+7K6g0YNmTKlMku FlKNmPC8zRA0TJrHP9YHUaSRN5c4YIPPtPW7N/I4= To: "Montgomery, Douglas (Fed)" , Russ Housley References: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> <3ae7d707-3229-2508-7aeb-2cd617aa97fd@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 4 Jan 2017 20:48:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090405050702050600080804" Archived-At: Cc: IESG , IETF SIDR Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 20:48:07 -0000 This is a cryptographically signed message in MIME format. --------------ms090405050702050600080804 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 04/01/17 20:00, Montgomery, Douglas (Fed) wrote: > Stephen, >=20 > If I understand your question, I don=E2=80=99t think one can infer anyt= hing about > the BGP feeds or route selection processes of an AS based upon the traf= fic > a validating cache sends to RPKI repositories. Is that the same traffic a BGPsec relying party sends? I can imagine that it might or might not be, but don't recall the BGPsec spec saying. If, in fact, it isn't possible to infer which ASes are likely to be used from the traffic emitted by an RP for PKI purposes, then yes, this discuss point goes away. (I think:-) Cheers, S. >=20 > The design of RPKI validating caches (and all implementations that I kn= ow > of) prefetch and validate RPKI objects independent of BGP traffic > processing. That is, they are background processing the entire RPKI, = and > are not event driven by BGP traffic. As a matter of fact, the RPKI > validating cache=E2=80=99s are typically on systems that have no reason= to > implement BGP at all. >=20 > Also the RPKI-to-Rtr protocol between the cache and router is batch dri= ven > (roughly) by the validation process, not BGP event driven. >=20 > I.e., the RPKI traffic to a validating cache in an AS with no BGP feeds= > and one with full BGP feeds is the same, and both independent of BGP ev= ent > processing. >=20 > If that was not the supposition of your question =E2=80=A6 please ignor= e. > dougm >=20 >=20 >=20 >=20 > =E2=80=94=20 > Doug Montgomery, Mgr Internet & Scalable Systems Research at NIST/ITL/= ANTD >=20 >=20 >=20 >=20 >=20 > On 1/4/17, 2:33 PM, "sidr on behalf of Stephen Farrell" > wrote: >=20 >> >> >> On 04/01/17 19:24, Russ Housley wrote: >>> >>>> --------------------------------------------------------------------= -- >>>> >>>> >> DISCUSS: >>>> --------------------------------------------------------------------= -- >>>> >>>> >>>> >> I have a couple of fairly straightforward things I'd >>>> like to briefly discuss... >>>> >>>> [snip] >>>> >>>> (3) section 8: Is there a potential exposure here in that a relying >>>> party who emits e.g. certificate status checks or cert retrieval >>>> queries for an RPKI cert they've not previously seen is exposing >>>> something about the set of paths its traffic is likely to follow. >>>> (This is similar to why we have OCSP stapling in the web.) IIRC the >>>> RPKI specs may cover this but I suspect it'd be worth noting here >>>> as well even if so as this represents exposing something about BGP >>>> announcement content to off-path parties which I think is new for >>>> BGP. Is that a new thing for BGP? (I think the new aspect to the >>>> attack is that a bad actor who has already compromised some AS >>>> could more easily spot that traffic from the relying party's AS is >>>> likely to transit the compromised AS.) >>> >>> I am not sure what you mean by a "compromised AS,=E2=80=9D but it may= not >>> matters =E2=80=A6 >> >> More or less if traffic to/from ASxxxx is visible to an >> attacker and/or can be modified by an attacker. That could >> be due to collusion between the AS and an attacker for >> example, or because an attacker has compromised some routers >> within a transit AS. >> >>> >>> If a link goes down, >> >> I'm not sure this is only if a link goes down. I'd guess the same >> risk would exist when any BGPsec path is first seen at a relying >> party and where that RP doesn't have all the necessary RPKI stuff >> cached before signature validation. >> >> . and that causes an alternative path to be >>> selected, that forces the validation a new path which might involve a= >>> previously unvalidated AS. If an OCSP responder or repository that >>> provides RPKI objects is contacted as part of that validation, then >>> some external entities can detect that something is changing. That >>> is, stuff not normally validated because it is associated with a >>> unselected path gets fetched. >> >> Right. Sorry to not be clearer on what might become visible to >> the network outside the RP's AS - I'm afraid I just don't have all >> the RPKI details in my head;-) >> >>> >>> That said, the NOC could fetch a snapshot of the RPKI, then the >>> exposure of the switch to a new path can be limited to that AS. This= >>> assumes that the snapshot uses CRLs, which seems like a very >>> reasonable choice in the RPKI. >> >> Right, I think all that'd be needed for this would be to ack that >> there's this (normally fairly minor) new risk and that you can >> avoid it if you pre-fetch enough stuff. (As a separate question, >> I wonder if the amount of stuff involved in the RPKI is such that >> it'd be fairly easy to pre-fetch it all frequently enough to >> nearly never hit this problem.) >> >> Cheers, >> S. >> >>> >>> Russ >>> >> >=20 --------------ms090405050702050600080804 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDQy MDQ4MDJaMC8GCSqGSIb3DQEJBDEiBCDql2WFHGxc7jtCcxZrNDtcOrfbpLpkRIxnFudOJVHI VTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBG2D2LkJTYQEaaGMgbnzW8taiY/GdeL4DRzOvxGAxRUx5QII0yL0zh b80zk2iX8k/WwFaAq+hjDiOmfSmyximPu39AXZU2u2s5miJez0j+PACkMumAykca5g07R9RD kjSQTCWmVZaJoJcgrHmxMwPZmP4djSe8Q4MaMUe8WyChq6TV4+ueKjanplGXJpe85iX+FM4e FOpMl5KS75Fqv56Buyo11o/pNjD3tvEF/rC6RtnluO1AT51xVfuU49nSZlmtG1UwbsppnUJq GZOYpAH07tms2ad7inoQ7aAR3/qEIW7kTk23haMwUZSQibCJCpv+8568BexVt6KNOBkvKdt7 AAAAAAAA --------------ms090405050702050600080804-- From nobody Wed Jan 4 12:57:37 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275DB129454; Wed, 4 Jan 2017 12:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 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, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham 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 lHxXu2DP04rJ; Wed, 4 Jan 2017 12:57:29 -0800 (PST) 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 AB86612945B; Wed, 4 Jan 2017 12:57:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 18236BE47; Wed, 4 Jan 2017 20:57:27 +0000 (GMT) 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 c_UTrskrQ7Qw; Wed, 4 Jan 2017 20:57:25 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 05FE4BE3E; Wed, 4 Jan 2017 20:57:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483563445; bh=7KZ/LWxLZkTElM3NB4g22LT7nm7r3sIIBDeldAwxIQ4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=bpWApdRdgL5I1JnUvScDfNUCOHL9jxb8afowSz7a95r8uqSNdK+42QbtMY6EaDA/T ze30rIlMd6hcyJFCdz/GnZUWBqjm+bnT7VQk2t3Ji6gM3NpXfYU2gplY9k1YLrDdlU KODB7a25R4vzENmo1GwzaIOuEwHKtCjsVihj2/go= To: Rob Austein References: <148353788046.13042.160471261406266.idtracker@ietfa.amsl.com> <20170104200413.1DFD04581178@minas-ithil.hactrn.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <99955d9c-4771-dd45-f019-313661631e87@cs.tcd.ie> Date: Wed, 4 Jan 2017 20:57:24 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170104200413.1DFD04581178@minas-ithil.hactrn.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030101000108020102090809" Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 20:57:32 -0000 This is a cryptographically signed message in MIME format. --------------ms030101000108020102090809 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Rob, On 04/01/17 20:04, Rob Austein wrote: > [Not the author, but...] >=20 No matter - a good answer is a good answer:-) > At Wed, 04 Jan 2017 05:51:20 -0800, Stephen Farrell wrote: > ... >> I have a few probably quick things I'd like to discuss for >> this one: >> >> (1) 3.1.1: Why MUST a CA ensure that the CA name and >> Subject name combination is unique? I don't see what'd >> break in BGPsec if that rule is omitted, but maybe I'm >> missing something.=20 >> >> (2) 3.1.1: Similarly, I'm not clear why only common name >> and serial number are allowed in Subject. Why is that >> needed for interop? (I can see that you want to say that >> code MUST support those but not why you want to prevent >> other things.) >=20 > This draft is a profile of RFC 6487, which is itself a profile of RFC > 5280. All of the above is pretty much verbatim from RFC 6487. Hmm. I wonder if that's the best plan, especially if there's no interop justification for some of it. I note that 6487 says "In the RPKI, the subject name is determined by the issuer, not proposed by the subject" but that seems a bit weird for routers, where I would guess there'll be more diversity in terms of key/CSR generation code. (Correct me if I'm wrong but I'm not sure if it's possible to conform to these requirements with e.g. openssl, or is it?) >=20 >> (3) Where's certificate status checking covered? What's >> expected for BGPsec router certs? If BGPsec speakers are >> intended to inherit the CRL checking from 6487 then being >> explicit about that would probably be worthwhile. >=20 > Yes, I think this too is inherited from RFC 6487. >=20 >> And I'd wonder if router cert revocation will be more common than >> for other resource certs, in which case an OCSP-like system could be >> needed - did the WG consider that? >=20 > Not as such. Fair question, but the architecture kind of assumes that > the RPKI RP process is separable from the BGPSEC implementation per > se, BGPSEC just consumes the output of that process. I'd wonder if that means some revocation request protocol will be needed later. But it's fine to not try define that now. More to the point is whether or not the WG have thought about the revocation support in the RPKI and whether or not that seems also ok for BGPsec. (I'm unsure myself, but mostly due to the number of moving parts in the RPKI.) > Most likely implementation technique does all the RPKI stuff per se on > a separate box and just stuffs the resulting raw keys into the router > using the rpki-rtr protocol, so the router itself probably would not > have the information needed to play OCSP even if it wanted to do so, > which it probably doesn't. =20 So if that's a widely shared view of WG participants then it'd be good to see it described somewhere to help implementers. (It may be in the -overview document which I've yet to read.) > Requiring the routers to speak OCSP seems > like a potentially dangerous layering violation. Not sure about a layering violation but I can see it'd likely be problematic;-) Cheers, S. --------------ms030101000108020102090809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDQy MDU3MjRaMC8GCSqGSIb3DQEJBDEiBCC1oOuQ0ARsykrUQZ/Cu0RhVHObim4wTwQS4n0MAuBG UDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBGzG1oAfYmR2at7FwLxDhneZmWo1Z9tx0vDIZxoWUJQyAAzBdHdSWo lo3CIFYntLuHWdWLYMJdr7NMLnLw9ZV0SMxe56Kxm9LQ7Iy5n7Br8PP6a4AxjcFF3jQaKd1w wFBihWlFs0g/o7AOfXVtf2ClCoXKq5u4ATs0AJNEHOSXXIJmZVeDBH74FerFlczPgRI6zsYS 8rHfcBFkzfIhg+WlDMndU9fTw54nAqgWjLYaI+H/sBkk3N2TdLy5ILwiGrxIkLn1Qhw0WlU0 16FgiEcfBjr4wK7W0Ra3wg2s1bA4Kdz+rDcBg1Q5O+OlinEilINeayrhTUiZ7FdDhj84YBxp AAAAAAAA --------------ms030101000108020102090809-- From nobody Wed Jan 4 13:07:09 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5EAF1295BD; Wed, 4 Jan 2017 13:07:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148356402580.12969.9796089522192063819.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 13:07:05 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org Subject: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-pki-profiles-19: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 21:07:06 -0000 Ben Campbell has entered the following ballot position for draft-ietf-sidr-bgpsec-pki-profiles-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few strictly editorial comments: - IDNits complains about some undefined references. - Abstract: Why is the phrase "(to routers within an Autonomous System)" in parentheses? -2: draft-ietf-sidr-bgpsec-protocol explicitly excludes non-capitalized versions of 2119 words. This draft does not. It seems different 2119 approaches among the various bgpsec draft could be confusing to the reader. From nobody Wed Jan 4 13:39:10 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4872D1296B4; Wed, 4 Jan 2017 13:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 SuizhbHq0JF4; Wed, 4 Jan 2017 13:39:07 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0110.outbound.protection.outlook.com [23.103.200.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891D91296DD; Wed, 4 Jan 2017 13:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fc1Mg2WHnS+pOKq9aI+Tm7U8CE/MfewNfe0fuwjiknA=; b=LmVyzKxl8ui0wOCBiHOx/Q8BCTyt35rx46CmZ0wFEsNWHL2+4VcjnqupcxWkwsrT+a3yjAm8XkpGmKPBK+4etucNuYZC453fF43nVUmp+16UO7Lq5l/cEhyF72RmJpQolc7I2qW/eyYYsHjqno32QeZ3bWDI6K23pAsf4EmC3xs= Received: from BN6PR09MB1426.namprd09.prod.outlook.com (10.173.202.14) by BN6PR09MB1428.namprd09.prod.outlook.com (10.173.202.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Wed, 4 Jan 2017 21:39:05 +0000 Received: from BN6PR09MB1426.namprd09.prod.outlook.com ([10.173.202.14]) by BN6PR09MB1426.namprd09.prod.outlook.com ([10.173.202.14]) with mapi id 15.01.0829.003; Wed, 4 Jan 2017 21:39:04 +0000 From: "Montgomery, Douglas (Fed)" To: Stephen Farrell , Russ Housley Thread-Topic: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) Thread-Index: AQHSZpHm+sFsRlTcAUq59z5oqx6cVKEosxWAgAACfgD//7O6AIAAYT0A//+6YAA= Importance: low X-Priority: 5 Date: Wed, 4 Jan 2017 21:39:04 +0000 Message-ID: References: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> <3ae7d707-3229-2508-7aeb-2cd617aa97fd@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: spf=none (sender IP is ) smtp.mailfrom=dougm@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.140.29] x-microsoft-exchange-diagnostics: 1; BN6PR09MB1428; 7:jvs5tpYAmJ9g34gV2Aa8JPCLnq0kvbdngsChqxXELsTve+BqVvPNHSdpv8XLg1MKBjHxmen2VHZacp2mDBbVR2ExpOlO8/z4XCvPzaHnUqZfVAvOov+2TGslKstJ1c8j0OVh09IpfdVvrxSvaSbhdSRPNwt9RLW011Oe89P4ZnJE7emqEKpnA9ViH77xtMybhSZ2h+oe/wt/dSOMwvlyEQ9mhWOWgdfTv1gNjO9DtYKHktYBiUqr2KXrGo1Oo0jEDuT98296qyvIVac2Hbh/VX2de4GVO1jo02xKy4RQPy0crPnSvrKx0Zw3tXF+9Jz+hJ3PXU4CNka6oDWJGZXGPYFOFSeqGoWxpE2lZDfzpwKrruKkTJ4fSVQipBL+my+oTNx3c6n9a3WIGDHmkGh7t4A7LIefDHkJ/x0zwKDn2+h8n9QfaXNQDNiUZKWORf+KP0l507yJVegXCJRf/3h7Ag== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39860400002)(39850400002)(39410400002)(39450400003)(189002)(54094003)(377454003)(199003)(24454002)(102836003)(4001350100001)(99286003)(93886004)(106116001)(68736007)(6116002)(38730400001)(2906002)(3846002)(97736004)(229853002)(5001770100001)(105586002)(36756003)(66066001)(8676002)(106356001)(81166006)(8936002)(83506001)(305945005)(101416001)(189998001)(2900100001)(6512006)(2950100002)(54906002)(6436002)(230783001)(25786008)(6506006)(77096006)(92566002)(7736002)(6486002)(81156014)(3660700001)(54356999)(122556002)(81686999)(76176999)(5660300001)(86362001)(50986999)(4326007)(3280700002)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR09MB1428; H:BN6PR09MB1426.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: f0ef876d-fbe7-4713-e21c-08d434ea1b17 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR09MB1428; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:BN6PR09MB1428; BCL:0; PCL:0; RULEID:; SRVR:BN6PR09MB1428; x-forefront-prvs: 0177904E6B received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2017 21:39:04.5492 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR09MB1428 Archived-At: Cc: IESG , IETF SIDR Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 21:39:10 -0000 VGhlIFJQS0kgdmFsaWRhdGluZyBjYWNoZXMgKmFyZSogdGhlIHJlbGF5aW5nIHBhcnRpZXMgZm9y IEJHUHNlYywgdGhleSBhcmUNCihhKSBkZXNpZ25lZCB0byBiZSBydW4gb24gYSBzZXBhcmF0ZSBi b3ggdGhhbiB0aGUgcm91dGVyIGl0c2VsZiBhbmQgKGIpDQp0aGVpciBiZWhhdmlvciBXUlQgZXhj aGFuZ2VzIHdpdGggUlBLSSByZXBvc2l0b3JpZXMgaXMgaW5kZXBlbmRlbnQgb2YgQkdQDQptZXNz YWdlIHByb2Nlc3NpbmcgYnkgYW55IG9mIHRoZSByb3V0ZXJzIHRoYXQgdGhleSBzZXJ2ZS4NCg0K TWF5YmUgdGhlIGZpcnN0IGZldyBzZWN0aW9ucyBvZiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNjgxMCB3b3VsZA0KbWFrZSB0aGF0IHBvaW50IGJldHRlciB0aGFuIG15IG11bWJsaW5n cy4NCg0KZS5nLiwgRm9yIHZhcmlvdXMgcmVzZWFyY2ggLyBtZWFzdXJlbWVudCByZWFzb25zIHdl IHJ1biAzIGRpZmZlcmVudA0KdmFsaWRhdGluZyBjYWNoZXMgdGhhdCBkb27igJl0IHNlcnZlIGEg c2luZ2xlIEJHUCByb3V0ZXIuICAgVGhlaXIgZXhjaGFuZ2VzDQp3aXRoIHRoZSByZXBvc2l0b3Jp ZXMgYXJlIG5vIGRpZmZlcmVudCB0aGFuIGlmIHRoZXkgc2VydmVkIGEgREZaIEJHUA0Kcm91dGVy Lg0KDQpEb3VnbQ0KDQoNCg0K4oCUIA0KRG91ZyBNb250Z29tZXJ5LCBNZ3IgSW50ZXJuZXQgJiBT Y2FsYWJsZSBTeXN0ZW1zIFJlc2VhcmNoIGF0ICBOSVNUL0lUTC9BTlREDQoNCg0KDQoNCg0KT24g MS80LzE3LCAzOjQ4IFBNLCAiU3RlcGhlbiBGYXJyZWxsIiA8c3RlcGhlbi5mYXJyZWxsQGNzLnRj ZC5pZT4gd3JvdGU6DQoNCj4NCj5IaXlhLA0KPg0KPk9uIDA0LzAxLzE3IDIwOjAwLCBNb250Z29t ZXJ5LCBEb3VnbGFzIChGZWQpIHdyb3RlOg0KPj4gU3RlcGhlbiwNCj4+IA0KPj4gSWYgSSB1bmRl cnN0YW5kIHlvdXIgcXVlc3Rpb24sIEkgZG9u4oCZdCB0aGluayBvbmUgY2FuIGluZmVyIGFueXRo aW5nDQo+PmFib3V0DQo+PiB0aGUgQkdQIGZlZWRzIG9yIHJvdXRlIHNlbGVjdGlvbiBwcm9jZXNz ZXMgb2YgYW4gQVMgYmFzZWQgdXBvbiB0aGUNCj4+dHJhZmZpYw0KPj4gYSB2YWxpZGF0aW5nIGNh Y2hlIHNlbmRzIHRvIFJQS0kgcmVwb3NpdG9yaWVzLg0KPg0KPklzIHRoYXQgdGhlIHNhbWUgdHJh ZmZpYyBhIEJHUHNlYyByZWx5aW5nIHBhcnR5IHNlbmRzPw0KPg0KPkkgY2FuIGltYWdpbmUgdGhh dCBpdCBtaWdodCBvciBtaWdodCBub3QgYmUsIGJ1dCBkb24ndA0KPnJlY2FsbCB0aGUgQkdQc2Vj IHNwZWMgc2F5aW5nLg0KPg0KPklmLCBpbiBmYWN0LCBpdCBpc24ndCBwb3NzaWJsZSB0byBpbmZl ciB3aGljaCBBU2VzIGFyZQ0KPmxpa2VseSB0byBiZSB1c2VkIGZyb20gdGhlIHRyYWZmaWMgZW1p dHRlZCBieSBhbiBSUA0KPmZvciBQS0kgcHVycG9zZXMsIHRoZW4geWVzLCB0aGlzIGRpc2N1c3Mg cG9pbnQgZ29lcw0KPmF3YXkuIChJIHRoaW5rOi0pDQo+DQo+Q2hlZXJzLA0KPlMuDQo+DQo+PiAN Cj4+IFRoZSBkZXNpZ24gb2YgUlBLSSB2YWxpZGF0aW5nIGNhY2hlcyAoYW5kIGFsbCBpbXBsZW1l bnRhdGlvbnMgdGhhdCBJDQo+Pmtub3cNCj4+IG9mKSBwcmVmZXRjaCBhbmQgdmFsaWRhdGUgUlBL SSBvYmplY3RzIGluZGVwZW5kZW50IG9mIEJHUCB0cmFmZmljDQo+PiBwcm9jZXNzaW5nLiAgIFRo YXQgaXMsIHRoZXkgYXJlIGJhY2tncm91bmQgcHJvY2Vzc2luZyB0aGUgZW50aXJlIFJQS0ksDQo+ PmFuZA0KPj4gYXJlIG5vdCBldmVudCBkcml2ZW4gYnkgQkdQIHRyYWZmaWMuICBBcyBhIG1hdHRl ciBvZiBmYWN0LCB0aGUgUlBLSQ0KPj4gdmFsaWRhdGluZyBjYWNoZeKAmXMgYXJlIHR5cGljYWxs eSBvbiBzeXN0ZW1zIHRoYXQgaGF2ZSBubyByZWFzb24gdG8NCj4+IGltcGxlbWVudCBCR1AgYXQg YWxsLg0KPj4gDQo+PiBBbHNvIHRoZSBSUEtJLXRvLVJ0ciBwcm90b2NvbCBiZXR3ZWVuIHRoZSBj YWNoZSBhbmQgcm91dGVyIGlzIGJhdGNoDQo+PmRyaXZlbg0KPj4gKHJvdWdobHkpIGJ5IHRoZSB2 YWxpZGF0aW9uIHByb2Nlc3MsIG5vdCBCR1AgZXZlbnQgZHJpdmVuLg0KPj4gDQo+PiBJLmUuLCB0 aGUgUlBLSSB0cmFmZmljIHRvIGEgdmFsaWRhdGluZyBjYWNoZSBpbiBhbiBBUyB3aXRoIG5vIEJH UCBmZWVkcw0KPj4gYW5kIG9uZSB3aXRoIGZ1bGwgQkdQIGZlZWRzIGlzIHRoZSBzYW1lLCBhbmQg Ym90aCBpbmRlcGVuZGVudCBvZiBCR1ANCj4+ZXZlbnQNCj4+IHByb2Nlc3NpbmcuDQo+PiANCj4+ IElmIHRoYXQgd2FzIG5vdCB0aGUgc3VwcG9zaXRpb24gb2YgeW91ciBxdWVzdGlvbiDigKYgcGxl YXNlIGlnbm9yZS4NCj4+IGRvdWdtDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IOKAlCANCj4+IERv dWcgTW9udGdvbWVyeSwgTWdyIEludGVybmV0ICYgU2NhbGFibGUgU3lzdGVtcyBSZXNlYXJjaCBh dA0KPj5OSVNUL0lUTC9BTlREDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gT24gMS80LzE3 LCAyOjMzIFBNLCAic2lkciBvbiBiZWhhbGYgb2YgU3RlcGhlbiBGYXJyZWxsIg0KPj4gPHNpZHIt Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygc3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4g d3JvdGU6DQo+PiANCj4+Pg0KPj4+DQo+Pj4gT24gMDQvMDEvMTcgMTk6MjQsIFJ1c3MgSG91c2xl eSB3cm90ZToNCj4+Pj4NCj4+Pj4+IA0KPj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pg0KPj4+Pj4N Cj4+PiBESVNDVVNTOg0KPj4+Pj4gDQo+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+DQo+Pj4+Pg0K Pj4+Pj4NCj4+PiBJIGhhdmUgYSBjb3VwbGUgb2YgZmFpcmx5IHN0cmFpZ2h0Zm9yd2FyZCB0aGlu Z3MgSSdkDQo+Pj4+PiBsaWtlIHRvIGJyaWVmbHkgZGlzY3Vzcy4uLg0KPj4+Pj4NCj4+Pj4+IFtz bmlwXQ0KPj4+Pj4NCj4+Pj4+ICgzKSBzZWN0aW9uIDg6IElzIHRoZXJlIGEgcG90ZW50aWFsIGV4 cG9zdXJlIGhlcmUgaW4gdGhhdCBhIHJlbHlpbmcNCj4+Pj4+IHBhcnR5IHdobyBlbWl0cyBlLmcu ICBjZXJ0aWZpY2F0ZSBzdGF0dXMgY2hlY2tzIG9yIGNlcnQgcmV0cmlldmFsDQo+Pj4+PiBxdWVy aWVzIGZvciBhbiBSUEtJIGNlcnQgdGhleSd2ZSBub3QgcHJldmlvdXNseSBzZWVuIGlzIGV4cG9z aW5nDQo+Pj4+PiBzb21ldGhpbmcgYWJvdXQgdGhlIHNldCBvZiBwYXRocyBpdHMgdHJhZmZpYyBp cyBsaWtlbHkgdG8gZm9sbG93Lg0KPj4+Pj4gKFRoaXMgaXMgc2ltaWxhciB0byB3aHkgd2UgaGF2 ZSBPQ1NQIHN0YXBsaW5nIGluIHRoZSB3ZWIuKSBJSVJDIHRoZQ0KPj4+Pj4gUlBLSSBzcGVjcyBt YXkgY292ZXIgdGhpcyBidXQgSSBzdXNwZWN0IGl0J2QgYmUgd29ydGggbm90aW5nIGhlcmUNCj4+ Pj4+IGFzIHdlbGwgZXZlbiBpZiBzbyBhcyB0aGlzIHJlcHJlc2VudHMgZXhwb3Npbmcgc29tZXRo aW5nIGFib3V0IEJHUA0KPj4+Pj4gYW5ub3VuY2VtZW50IGNvbnRlbnQgdG8gb2ZmLXBhdGggcGFy dGllcyB3aGljaCBJIHRoaW5rIGlzIG5ldyBmb3INCj4+Pj4+IEJHUC4gSXMgdGhhdCBhIG5ldyB0 aGluZyBmb3IgQkdQPyAoSSB0aGluayB0aGUgbmV3IGFzcGVjdCB0byB0aGUNCj4+Pj4+IGF0dGFj ayBpcyB0aGF0IGEgYmFkIGFjdG9yIHdobyBoYXMgYWxyZWFkeSBjb21wcm9taXNlZCBzb21lIEFT DQo+Pj4+PiBjb3VsZCBtb3JlIGVhc2lseSBzcG90IHRoYXQgdHJhZmZpYyBmcm9tIHRoZSByZWx5 aW5nIHBhcnR5J3MgQVMgaXMNCj4+Pj4+IGxpa2VseSB0byB0cmFuc2l0IHRoZSBjb21wcm9taXNl ZCBBUy4pDQo+Pj4+DQo+Pj4+IEkgYW0gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSBhICJjb21w cm9taXNlZCBBUyzigJ0gYnV0IGl0IG1heSBub3QNCj4+Pj4gbWF0dGVycyDigKYNCj4+Pg0KPj4+ IE1vcmUgb3IgbGVzcyBpZiB0cmFmZmljIHRvL2Zyb20gQVN4eHh4IGlzIHZpc2libGUgdG8gYW4N Cj4+PiBhdHRhY2tlciBhbmQvb3IgY2FuIGJlIG1vZGlmaWVkIGJ5IGFuIGF0dGFja2VyLiBUaGF0 IGNvdWxkDQo+Pj4gYmUgZHVlIHRvIGNvbGx1c2lvbiBiZXR3ZWVuIHRoZSBBUyBhbmQgYW4gYXR0 YWNrZXIgZm9yDQo+Pj4gZXhhbXBsZSwgb3IgYmVjYXVzZSBhbiBhdHRhY2tlciBoYXMgY29tcHJv bWlzZWQgc29tZSByb3V0ZXJzDQo+Pj4gd2l0aGluIGEgdHJhbnNpdCBBUy4NCj4+Pg0KPj4+Pg0K Pj4+PiBJZiBhIGxpbmsgZ29lcyBkb3duLA0KPj4+DQo+Pj4gSSdtIG5vdCBzdXJlIHRoaXMgaXMg b25seSBpZiBhIGxpbmsgZ29lcyBkb3duLiBJJ2QgZ3Vlc3MgdGhlIHNhbWUNCj4+PiByaXNrIHdv dWxkIGV4aXN0IHdoZW4gYW55IEJHUHNlYyBwYXRoIGlzIGZpcnN0IHNlZW4gYXQgYSByZWx5aW5n DQo+Pj4gcGFydHkgYW5kIHdoZXJlIHRoYXQgUlAgZG9lc24ndCBoYXZlIGFsbCB0aGUgbmVjZXNz YXJ5IFJQS0kgc3R1ZmYNCj4+PiBjYWNoZWQgYmVmb3JlIHNpZ25hdHVyZSB2YWxpZGF0aW9uLg0K Pj4+DQo+Pj4gLiBhbmQgdGhhdCBjYXVzZXMgYW4gYWx0ZXJuYXRpdmUgcGF0aCB0byBiZQ0KPj4+ PiBzZWxlY3RlZCwgdGhhdCBmb3JjZXMgdGhlIHZhbGlkYXRpb24gYSBuZXcgcGF0aCB3aGljaCBt aWdodCBpbnZvbHZlIGENCj4+Pj4gcHJldmlvdXNseSB1bnZhbGlkYXRlZCBBUy4gIElmIGFuIE9D U1AgcmVzcG9uZGVyIG9yIHJlcG9zaXRvcnkgdGhhdA0KPj4+PiBwcm92aWRlcyBSUEtJIG9iamVj dHMgaXMgY29udGFjdGVkIGFzIHBhcnQgb2YgdGhhdCB2YWxpZGF0aW9uLCB0aGVuDQo+Pj4+IHNv bWUgZXh0ZXJuYWwgZW50aXRpZXMgY2FuIGRldGVjdCB0aGF0IHNvbWV0aGluZyBpcyBjaGFuZ2lu Zy4gIFRoYXQNCj4+Pj4gaXMsIHN0dWZmIG5vdCBub3JtYWxseSB2YWxpZGF0ZWQgYmVjYXVzZSBp dCBpcyBhc3NvY2lhdGVkIHdpdGggYQ0KPj4+PiB1bnNlbGVjdGVkIHBhdGggZ2V0cyBmZXRjaGVk Lg0KPj4+DQo+Pj4gUmlnaHQuIFNvcnJ5IHRvIG5vdCBiZSBjbGVhcmVyIG9uIHdoYXQgbWlnaHQg YmVjb21lIHZpc2libGUgdG8NCj4+PiB0aGUgbmV0d29yayBvdXRzaWRlIHRoZSBSUCdzIEFTIC0g SSdtIGFmcmFpZCBJIGp1c3QgZG9uJ3QgaGF2ZSBhbGwNCj4+PiB0aGUgUlBLSSBkZXRhaWxzIGlu IG15IGhlYWQ7LSkNCj4+Pg0KPj4+Pg0KPj4+PiBUaGF0IHNhaWQsIHRoZSBOT0MgY291bGQgZmV0 Y2ggYSBzbmFwc2hvdCBvZiB0aGUgUlBLSSwgdGhlbiB0aGUNCj4+Pj4gZXhwb3N1cmUgb2YgdGhl IHN3aXRjaCB0byBhIG5ldyBwYXRoIGNhbiBiZSBsaW1pdGVkIHRvIHRoYXQgQVMuICBUaGlzDQo+ Pj4+IGFzc3VtZXMgdGhhdCB0aGUgc25hcHNob3QgdXNlcyBDUkxzLCB3aGljaCBzZWVtcyBsaWtl IGEgdmVyeQ0KPj4+PiByZWFzb25hYmxlIGNob2ljZSBpbiB0aGUgUlBLSS4NCj4+Pg0KPj4+IFJp Z2h0LCBJIHRoaW5rIGFsbCB0aGF0J2QgYmUgbmVlZGVkIGZvciB0aGlzIHdvdWxkIGJlIHRvIGFj ayB0aGF0DQo+Pj4gdGhlcmUncyB0aGlzIChub3JtYWxseSBmYWlybHkgbWlub3IpIG5ldyByaXNr IGFuZCB0aGF0IHlvdSBjYW4NCj4+PiBhdm9pZCBpdCBpZiB5b3UgcHJlLWZldGNoIGVub3VnaCBz dHVmZi4gKEFzIGEgc2VwYXJhdGUgcXVlc3Rpb24sDQo+Pj4gSSB3b25kZXIgaWYgdGhlIGFtb3Vu dCBvZiBzdHVmZiBpbnZvbHZlZCBpbiB0aGUgUlBLSSBpcyBzdWNoIHRoYXQNCj4+PiBpdCdkIGJl IGZhaXJseSBlYXN5IHRvIHByZS1mZXRjaCBpdCBhbGwgZnJlcXVlbnRseSBlbm91Z2ggdG8NCj4+ PiBuZWFybHkgbmV2ZXIgaGl0IHRoaXMgcHJvYmxlbS4pDQo+Pj4NCj4+PiBDaGVlcnMsDQo+Pj4g Uy4NCj4+Pg0KPj4+Pg0KPj4+PiBSdXNzDQo+Pj4+DQo+Pj4NCj4+IA0KPg0KDQo= From nobody Wed Jan 4 13:43:49 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4021C12941E; Wed, 4 Jan 2017 13:43:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148356622825.12945.17416255063037873581.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 13:43:48 -0800 Archived-At: Cc: draft-ietf-sidr-bgpsec-protocol@ietf.org, sidr-chairs@ietf.org, m.waehlisch@fu-berlin.de, sidr@ietf.org Subject: [sidr] Ben Campbell's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 21:43:48 -0000 Ben Campbell has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share some of the concerns about deployability, but have nothing new to add to that conversation. Otherwise I just have a few minor comments: -2: draft-ietf-sidr-bgpsec-protocol explicitly excludes non-capitalized versions of 2119 words. This draft does not. It seems different 2119 approaches among the various bgpsec draft could be confusing to the reader. - 5.2, step 2: I'm almost sure I've missed something here, but if I understand correctly, previous sections talked about how a peer can propagate a BGPsec_Path attribute without modification. Will that cause a problem in this step if the immediate peer propagated an unmodified BGPsec_Path that came from a different AS? - 8.4, last paragraph: The text describes a replay attack, and delegates the mitigation solution to draft-ietf-sidr-bgpsec-rollover. This is an informational reference; it seems like it should be normative. From nobody Wed Jan 4 13:45:28 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEA31296F7; Wed, 4 Jan 2017 13:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 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, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham 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 Qs8mbNz-nsml; Wed, 4 Jan 2017 13:45:24 -0800 (PST) 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 A29BF12941E; Wed, 4 Jan 2017 13:45:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 39C9CBE39; Wed, 4 Jan 2017 21:45:21 +0000 (GMT) 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 otHnNzDmSizR; Wed, 4 Jan 2017 21:45:19 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9B597BE38; Wed, 4 Jan 2017 21:45:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483566319; bh=XbQ4IQ/DDwq4xIA9i+B87NvqgLR7vHnhZ+Hdey0N+BM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=kvYb6FtLgohMhqKO63t+l3GdHldnNUcK7OVY6b2IQW9N/qbjwQ61lpZB61mwe6yTu vgOAAjQAGqK5qhFX2RIar7JD2I6H+b9i9J5wS1dt/10hkefi1civ0BU0QlJw06odAB eiorzY5uezrCC4klJACuJKoTL7RzEy95LL3Zo8+Q= To: "Montgomery, Douglas (Fed)" , Russ Housley References: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> <3ae7d707-3229-2508-7aeb-2cd617aa97fd@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 4 Jan 2017 21:45:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080702040900010903040100" Archived-At: Cc: IESG , IETF SIDR Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 21:45:27 -0000 This is a cryptographically signed message in MIME format. --------------ms080702040900010903040100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 04/01/17 21:39, Montgomery, Douglas (Fed) wrote: > The RPKI validating caches *are* the relaying parties for BGPsec, they = are > (a) designed to be run on a separate box than the router itself and (b)= > their behavior WRT exchanges with RPKI repositories is independent of B= GP > message processing by any of the routers that they serve. Sure. That makes sense. But where's it stated for BGPsec that the RP ought act that way? Cheers, S. >=20 > Maybe the first few sections of https://tools.ietf.org/html/rfc6810 wou= ld > make that point better than my mumblings. >=20 > e.g., For various research / measurement reasons we run 3 different > validating caches that don=E2=80=99t serve a single BGP router. Their= exchanges > with the repositories are no different than if they served a DFZ BGP > router. >=20 > Dougm >=20 >=20 >=20 > =E2=80=94=20 > Doug Montgomery, Mgr Internet & Scalable Systems Research at NIST/ITL/= ANTD >=20 >=20 >=20 >=20 >=20 > On 1/4/17, 3:48 PM, "Stephen Farrell" wrote= : >=20 >> >> Hiya, >> >> On 04/01/17 20:00, Montgomery, Douglas (Fed) wrote: >>> Stephen, >>> >>> If I understand your question, I don=E2=80=99t think one can infer an= ything >>> about >>> the BGP feeds or route selection processes of an AS based upon the >>> traffic >>> a validating cache sends to RPKI repositories. >> >> Is that the same traffic a BGPsec relying party sends? >> >> I can imagine that it might or might not be, but don't >> recall the BGPsec spec saying. >> >> If, in fact, it isn't possible to infer which ASes are >> likely to be used from the traffic emitted by an RP >> for PKI purposes, then yes, this discuss point goes >> away. (I think:-) >> >> Cheers, >> S. >> >>> >>> The design of RPKI validating caches (and all implementations that I >>> know >>> of) prefetch and validate RPKI objects independent of BGP traffic >>> processing. That is, they are background processing the entire RPKI= , >>> and >>> are not event driven by BGP traffic. As a matter of fact, the RPKI >>> validating cache=E2=80=99s are typically on systems that have no reas= on to >>> implement BGP at all. >>> >>> Also the RPKI-to-Rtr protocol between the cache and router is batch >>> driven >>> (roughly) by the validation process, not BGP event driven. >>> >>> I.e., the RPKI traffic to a validating cache in an AS with no BGP fee= ds >>> and one with full BGP feeds is the same, and both independent of BGP >>> event >>> processing. >>> >>> If that was not the supposition of your question =E2=80=A6 please ign= ore. >>> dougm >>> >>> >>> >>> >>> =E2=80=94=20 >>> Doug Montgomery, Mgr Internet & Scalable Systems Research at >>> NIST/ITL/ANTD >>> >>> >>> >>> >>> >>> On 1/4/17, 2:33 PM, "sidr on behalf of Stephen Farrell" >>> wrote:= >>> >>>> >>>> >>>> On 04/01/17 19:24, Russ Housley wrote: >>>>> >>>>>> >>>>>> ------------------------------------------------------------------= ---- >>>>>> >>>>>> >>>> DISCUSS: >>>>>> >>>>>> ------------------------------------------------------------------= ---- >>>>>> >>>>>> >>>>>> >>>> I have a couple of fairly straightforward things I'd >>>>>> like to briefly discuss... >>>>>> >>>>>> [snip] >>>>>> >>>>>> (3) section 8: Is there a potential exposure here in that a relyin= g >>>>>> party who emits e.g. certificate status checks or cert retrieval >>>>>> queries for an RPKI cert they've not previously seen is exposing >>>>>> something about the set of paths its traffic is likely to follow. >>>>>> (This is similar to why we have OCSP stapling in the web.) IIRC th= e >>>>>> RPKI specs may cover this but I suspect it'd be worth noting here >>>>>> as well even if so as this represents exposing something about BGP= >>>>>> announcement content to off-path parties which I think is new for >>>>>> BGP. Is that a new thing for BGP? (I think the new aspect to the >>>>>> attack is that a bad actor who has already compromised some AS >>>>>> could more easily spot that traffic from the relying party's AS is= >>>>>> likely to transit the compromised AS.) >>>>> >>>>> I am not sure what you mean by a "compromised AS,=E2=80=9D but it m= ay not >>>>> matters =E2=80=A6 >>>> >>>> More or less if traffic to/from ASxxxx is visible to an >>>> attacker and/or can be modified by an attacker. That could >>>> be due to collusion between the AS and an attacker for >>>> example, or because an attacker has compromised some routers >>>> within a transit AS. >>>> >>>>> >>>>> If a link goes down, >>>> >>>> I'm not sure this is only if a link goes down. I'd guess the same >>>> risk would exist when any BGPsec path is first seen at a relying >>>> party and where that RP doesn't have all the necessary RPKI stuff >>>> cached before signature validation. >>>> >>>> . and that causes an alternative path to be >>>>> selected, that forces the validation a new path which might involve= a >>>>> previously unvalidated AS. If an OCSP responder or repository that= >>>>> provides RPKI objects is contacted as part of that validation, then= >>>>> some external entities can detect that something is changing. That= >>>>> is, stuff not normally validated because it is associated with a >>>>> unselected path gets fetched. >>>> >>>> Right. Sorry to not be clearer on what might become visible to >>>> the network outside the RP's AS - I'm afraid I just don't have all >>>> the RPKI details in my head;-) >>>> >>>>> >>>>> That said, the NOC could fetch a snapshot of the RPKI, then the >>>>> exposure of the switch to a new path can be limited to that AS. Th= is >>>>> assumes that the snapshot uses CRLs, which seems like a very >>>>> reasonable choice in the RPKI. >>>> >>>> Right, I think all that'd be needed for this would be to ack that >>>> there's this (normally fairly minor) new risk and that you can >>>> avoid it if you pre-fetch enough stuff. (As a separate question, >>>> I wonder if the amount of stuff involved in the RPKI is such that >>>> it'd be fairly easy to pre-fetch it all frequently enough to >>>> nearly never hit this problem.) >>>> >>>> Cheers, >>>> S. >>>> >>>>> >>>>> Russ >>>>> >>>> >>> >> >=20 --------------ms080702040900010903040100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDQy MTQ1MThaMC8GCSqGSIb3DQEJBDEiBCCjkBpYPpOcwXIRt44Fq9bgXXjOzHu9zAO5Q1Ej6nPF UTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAWqHkqTQ+4mg5AkzMnw7ZntGW08Xqo3mUhXzr4gRUU4vv4gVaBpVzS abc+EAurMeRCNes5cYicTQecEw63E9Cgjcukof2k5ZGiRbeR3O3z4UO0aiwUNRU9p5ZK6N4z 3ud6MH+JVDhLYQPINOrHx++f7259B6MZ8kjVnbDoNeNP61frOdyimy60Xp5GuNyLqUSqOVKs hYDLVoAJGPeoOAdB0wTq7+QMRGJBXSoZntcPMcrijEcLC+gWBX8reJUp+T4sdvb2SOTa6u6k p9LjhWQqOFfHOskTO4RnQB2qFXgHsGZbm2B00vM5S1VwlsSBgriZcLga+lSpimgMKcCwEktH AAAAAAAA --------------ms080702040900010903040100-- From nobody Wed Jan 4 13:51:31 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D207129AC1; Wed, 4 Jan 2017 13:51:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148356668724.12930.15362273504294003018.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 13:51:27 -0800 Archived-At: Cc: morrowc@ops-netman.net, draft-ietf-sidr-as-migration@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: [sidr] Kathleen Moriarty's No Objection on draft-ietf-sidr-as-migration-06: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 21:51:27 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-sidr-as-migration-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think the Abstract & introduction are too brief. A lot of concerns might have been avoided with a little more explanation up front. I removed my discuss points as expanding the abstract to include more details in the introduction that appear in the security consideration section isn't really discussable, but would help the draft IMO. Comments are left, I didn't comb through them, so take or leave the ones that have not been addressed. Thank you. --- Standards Track *is* right for this document, but it takes a little to understand that while the document doesn't make any changes to the protocol, it does describe how implementations use the protocol to deliver a specific function. --- Some rewording of the introduction could go a long way in helping with document clarity: Possibly: "This document describes how ASN migration may be performed securely using the RPKI and BGPSec mechanisms. It defines the implementation behavior during ASN migration, but does not define any changes to the BGPSec protocol." *Note - if the last part remains true --- 1.2 refers to "private ASNs" and this term is well understood. But the referenced RFC 1930 doesn't use that term. It uses the term "Reserved AS Numbers" and describes them as "reserved for private use". --- Section 2 has "...merging two or more ASNs..." I think it is ASes that are being merged. Ditto "...is not enabled between the ASNs..." --- Section 3 has Since they are using methods to migrate that do not require coordination with customers, they do not have a great deal of control over the length of the transition period as they might with something completely under their administrative control I can't parse this. If the methods do NOT require coordination with customers, surely the methods are wholly under the control of the operator. Is there a typo: s/do not require/require/ ? Or is there some other message? --- Section 3 As solutions were being proposed for RPKI implementations to solve this transition case, operational complexity and hardware scaling considerations associated with maintaining multiple legacy ASN keys on routers throughout the combined network have been carefully considered. As worded (passive voice) it demands a citation. Possibly it is meant to say that operators have carefully considered this. Maybe that the SIDR WG has done the consideration. --- Section 3 It would be helpful to add a final sentence saying what this section goes on to do. I think it examines the basic functions of RPKI to determine whether they already handle ASN migration and to identify any issues that might arise when an ASN changes. --- 3.1 Route Origin Validation as defined by RFC 6480 [RFC6480] does not need a unique solution to enable AS migration, as the existing protocol and procedure allows for a solution. That doesn't read too well to me at least, do you mean something like: Route Origin Validation as defined by RFC 6480 [RFC6480] does not need modification to enable AS migration, as the existing protocol and procedure allows for a solution as follows. --- 3.1 In the scenario discussed, AS64510 is being replaced by AS64500. s/discussed/discussed in RFC 7705/ --- There are some abbreviations that will need to be expanded (e.g., ROA) --- 3.2.1 has... However, there is currently no guidance in the BGPSec protocol specification [I-D.ietf-sidr-bgpsec-protocol] on whether or not the forward-signed ASN value is required to match the configured remote AS to validate properly "currently" looks unlikely to change at this stage given the status of draft-ietf-sidr-bgpsec-protocol. So, either - make the changes to draft-ietf-sidr-bgpsec-protocol while you can or - change this text to reflect reality as... "However, there is no guidance..." --- 3.2.1 s/remote as 64510/remote AS 64510/ s/local as 64510/local AS 64510/ --- 3.2.1 It took me several attempts to parse... Assuming that this mismatch will be allowed by vendor implementations and using it as a means to solve this migration case is likely to be problematic. Did you mean: If we assume that this mismatch will be allowed by vendor implementations and that using it as a means to solve this migration case, then we are likely to see problems when implementations disallow the mismatch. --- 3.2.2 However, if the updates are left intact, this will cause the AS Path length to be increased, which is undesirable as discussed in RFC7705 [RFC7705]. On reading this I thought: "Undesirable is OK for a short transition period," but I went and read 7705. There, in the introduction, it says "it is critical that the ISP does not increase AS_PATH length during or after ASN migration". So I would s/is undesirable/must be avoided/ (Note: Section 4 has this as MUST NOT.) --- The text before the bullets in section 4 should... s/listed in no particular order:/listed in no particular order. BGPSec:/ Then "BGPSec" can be deleted from the first bullet. --- In section 5... Since that PE has been moved to AS64500, it is not possible for it to forward-sign AS64510 with pCount=0 without some minor changes to the BGPSec implementation to address this use case. I know what this is saying, but it is a bit skewed since implementations are not normally in scope for our specs. Perhaps... Since that PE has been moved to AS64500, this described a new behavior for implementations to forward-sign AS64510 with pCount=0. --- Section 5 This document proposes applying a similar technique Too late! If this is to be an RFC on the Standards Track then This document describes how to apply a similar technique --- Section 5 has (see section 4.4 of the above-referenced draft) Really? Too tired to actually include the reference? But by the time this document is published the reference will be an RFC and this text will be left dangling. ---- 5.2 The requirement to sign updates in iBGP represents a change to the normal behavior for this specific AS-migration implementation only. s/implementation/scenario/ --- I always love it when the Acknowledgements section thanks one of the authors :-) --- Section 8 This has happened before, but it usually leads the IESG to say "Hang on, why don't you just fix the protocol spec?" At the least, the Abstract and Introduction need to include the right text that would be present for an "Update". That is: what document is updated and what change is made. --- Section 9 Is "reasonably secure" should be replaced with something more accurate. Maybe this will come with the new text Sandy is working on. this is not fundamentally altering the existing security risks for BGPSec. That seems to say "...is somewhat (or marginally) altering..." which doesn't sound good. --- I hope the more detailed review is helpful. I still need to look at BGPsec to feel more comfortable with this one. From nobody Wed Jan 4 14:16:06 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53E6129495; Wed, 4 Jan 2017 14:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 H_10azYbtas5; Wed, 4 Jan 2017 14:16:00 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [IPv6:2001:418:8006::30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB3AF129AD2; Wed, 4 Jan 2017 14:15:58 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 194951399E; Wed, 4 Jan 2017 22:15:57 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 73CF84581C4F; Wed, 4 Jan 2017 17:15:57 -0500 (EST) Date: Wed, 04 Jan 2017 17:15:57 -0500 From: Rob Austein To: Stephen Farrell In-Reply-To: <99955d9c-4771-dd45-f019-313661631e87@cs.tcd.ie> References: <148353788046.13042.160471261406266.idtracker@ietfa.amsl.com> <20170104200413.1DFD04581178@minas-ithil.hactrn.net> <99955d9c-4771-dd45-f019-313661631e87@cs.tcd.ie> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170104221557.73CF84581C4F@minas-ithil.hactrn.net> Archived-At: Cc: Rob Austein , morrowc@ops-netman.net, sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 22:16:04 -0000 At Wed, 4 Jan 2017 20:57:24 +0000, Stephen Farrell wrote: > On 04/01/17 20:04, Rob Austein wrote: ... > > This draft is a profile of RFC 6487, which is itself a profile of RFC > > 5280. All of the above is pretty much verbatim from RFC 6487. > > Hmm. I wonder if that's the best plan, especially if there's > no interop justification for some of it. The theory, such as it is, goes: * RPKI is a tightly constrained profile of X.509v3, with almost everything either required or forbidden, to reduce the number of grey areas. * The BGPSEC profile is a minimal set of changes and extensions to the RPKI profile: same overall goal, slightly different constraints. > I note that 6487 says "In the RPKI, the subject name is determined > by the issuer, not proposed by the subject" but that seems a bit > weird for routers, where I would guess there'll be more diversity in > terms of key/CSR generation code. Well, strictly speaking the subject name is always selected by the issuer in X.509, but I know what you mean. RFC 6487 is weird about this because various parties were extremely concerned to avoid anything that could be construed as certification of real-world identity, ie, they did not want to find themselves in the mainstream PKI business. So RPKI uses meaningless names and has the ability to enforce that, hence the text you note in RFC 6487. RFC 6487 6.1.1 does in fact allow the subject to include a subject name in the PKCS #10 request, but the text is loaded with weasel words. Speaking as someone who has implemented all of this, I find the RFC 6487 constraints on subject name in PKCS #10 requests a bit excessive, but that's not the document currently under discussion. > (Correct me if I'm wrong but I'm not sure if it's possible to > conform to these requirements with e.g. openssl, or is it?) The OpenSSL command line tool would probably fight hard against either omitting the subject field from the PKCS #10 request or allowing it to be NULL. The former (field absent) is not even syntactically legal X.509. The latter (present but NULL) is legal but kind of unusual: RFC 5280 4.1.2.6 allows it in certificates if a critical, non-empty subjectAltName extension is present, RFC 2986 is silent on the subject and is only informational in any case. I'm pretty sure that the OpenSSL library would allow the present-but-NULL form, but haven't tested it (recently? ever? don't recall...). In practice, I don't think any of the RKI CA implementations reject PKCS #10 requests for having a non-NULL subject, they just ignore it. All of this is still a problem with RFC 6487, which we should have caught five years ago. Oops. Not sure what the best approach is when trying to sub-profile a profile with a known wart like this. > >> And I'd wonder if router cert revocation will be more common than > >> for other resource certs, in which case an OCSP-like system could be > >> needed - did the WG consider that? > > > > Not as such. Fair question, but the architecture kind of assumes that > > the RPKI RP process is separable from the BGPSEC implementation per > > se, BGPSEC just consumes the output of that process. > > I'd wonder if that means some revocation request protocol will be > needed later. But it's fine to not try define that now. Fair point. > More to the point is whether or not the WG have thought about the > revocation support in the RPKI and whether or not that seems also > ok for BGPsec. (I'm unsure myself, but mostly due to the number of > moving parts in the RPKI.) Has been discussed, somewhat noisily. Ask a SIDR WG chair if you want an opinion on WG consensus. My own take is that router keys probably get whacked on roughly the same kind of timescale as other RPKI keys, so if the revocation mechanism is good enough for everything else, it's probably good enough for router keys. YMMV. > > Most likely implementation technique does all the RPKI stuff per se on > > a separate box and just stuffs the resulting raw keys into the router > > using the rpki-rtr protocol, so the router itself probably would not > > have the information needed to play OCSP even if it wanted to do so, > > which it probably doesn't. > > So if that's a widely shared view of WG participants then it'd be > good to see it described somewhere to help implementers. (It may > be in the -overview document which I've yet to read.) It's sort of in RFC 6810 (rpki-rtr). The update to RFC 6810 is stalled because I dropped the ball last year. > > Requiring the routers to speak OCSP seems > > like a potentially dangerous layering violation. > > Not sure about a layering violation but I can see it'd likely be > problematic;-) I had front-row tickets to the "let's stuff routing policy data into the DNS!" show back in the '90s. My main take-away from that mess was a fear of real-time circular dependencies. From nobody Wed Jan 4 14:37:19 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAADA1295C7 for ; Wed, 4 Jan 2017 14:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, 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 7UPiPIdtsRXZ for ; Wed, 4 Jan 2017 14:37:16 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 D65E312973A for ; Wed, 4 Jan 2017 14:37:14 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id d45so282085361qta.1 for ; Wed, 04 Jan 2017 14:37:14 -0800 (PST) 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=8oUQjFYTwPJABsYU2sdnItspDnRPTiQ6dK2MxZ6SfgI=; b=Z8EK1y3f1p4QTUYQ18Z3t4JaQYfxperNRe0hwF8Zq9DX6p6dUiVUYXLBcYgsfKDsLv 2eS1u+JrGwsDi/A3xWFDq2omx173KYnTEdMD189N9PRsEiiDfjTAiu4e1PVxRC5IDVMk e/tq+58FKMq8C201rQl1ktCtPdAA3yXvfIUDY= 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=8oUQjFYTwPJABsYU2sdnItspDnRPTiQ6dK2MxZ6SfgI=; b=iEFIvqHiJ8bNV2e/+qdB90YEce7tViqUNArsUEweysxp2bRhVobA9WI3+e1hafZD97 kkleJEGwNlzjR40+hDnK7DkwQMBhKouwdgIvfWwlJPN818BeKUyb6oprXFVlrk1fMF5t mfhoNv9R6nmPbFSmD+m+CBOGKjjyeECjeiocIzPNoedooPxIX1Kjol5guvY10jk0vtga dWzHEm+l9bJqxyyTfVEGTEwh9VG9/HZjutATX3ENSEvOvBcQ58N4qMz9A5QPOzo7jey/ cp17+SFBXr4pTpZ10SZbBzlG0tAHB8WOUtkP3KVG4Uss1m0Fa5301eRIav2bAT+HQzy+ wvVg== X-Gm-Message-State: AIkVDXKh0VpJR8Y26npMfzDg9dNSb4OEG/8BdsdDMX1C0SA4172Q8BfV6v/aBpxRHeWWOA== X-Received: by 10.200.42.106 with SMTP id l39mr63123882qtl.280.1483569434001; Wed, 04 Jan 2017 14:37:14 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id 30sm46719094qth.14.2017.01.04.14.37.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Jan 2017 14:37:12 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <148356402580.12969.9796089522192063819.idtracker@ietfa.amsl.com> Date: Wed, 4 Jan 2017 17:37:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148356402580.12969.9796089522192063819.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-pki-profiles-19: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 22:37:18 -0000 > On Jan 4, 2017, at 16:07, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-sidr-bgpsec-pki-profiles-19: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > A few strictly editorial comments: >=20 > - IDNits complains about some undefined references. =3D=3D Missing Reference: 'ID.sidr-rfc6485bis' is mentioned on line 334, = but not defined Yep that gets fixed when I change it to: RFC 7935 ** Obsolete undefined reference: RFC 6485 (Obsoleted by RFC 7935) I haven=E2=80=99t a clue where this reference is and why this warning is = there. =3D=3D Missing Reference: 'RFC6818' is mentioned on line 416, but not = defined And this also seems to be a fail on nroffedit. It=E2=80=99s in the list = but not populated in the informative references. 6818 is in the = rfc-ref.txt from which the references are pulled. grrr I=E2=80=99m going to claim I failed here, beg forgiveness, and hope that = we=E2=80=99ll let the RFC editor help us out later in the process. > - Abstract: Why is the phrase "(to routers within an Autonomous = System)" > in parentheses? sigh - no idea - parentheses removed > -2: draft-ietf-sidr-bgpsec-protocol explicitly excludes = non-capitalized > versions of 2119 words. This draft does not. It seems different 2119 > approaches among the various bgpsec draft could be confusing to the > reader. Where=E2=80=99s that in draft-ietf-sidr-bgpsec-protocol? Regardless, I=E2=80=99m not sure that restoration will work in this = draft because there are repeated MUST requirements from other RFC and my = AD told me to not capitalize them :) spt= From nobody Wed Jan 4 14:45:39 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAE312973E; Wed, 4 Jan 2017 14:45:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148356993344.13025.6002959289961148717.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 14:45:33 -0800 Archived-At: Cc: morrowc@ops-netman.net, draft-ietf-sidr-as-migration@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-as-migration-06: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 22:45:33 -0000 Ben Campbell has entered the following ballot position for draft-ietf-sidr-as-migration-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (The deferral of this draft until the bgpsec protocol draft is on the agenda resolves my comment about timing.) >From a strictly style perspective (that is, you can take this or leave it), I find the heavy use of present continuous tense confusing to read. From nobody Wed Jan 4 14:53:27 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E896A1296AC; Wed, 4 Jan 2017 14:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 K5r1Or2Nz0cr; Wed, 4 Jan 2017 14:53:20 -0800 (PST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (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 D7103129497; Wed, 4 Jan 2017 14:53:19 -0800 (PST) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 468318007D; Wed, 4 Jan 2017 22:53:14 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx2-us1.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id D4CB980054; Wed, 4 Jan 2017 22:53:13 +0000 (UTC) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03lp0052.outbound.protection.outlook.com [216.32.180.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx2-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 3982D80087; Wed, 4 Jan 2017 22:53:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FutD/SRAammxGAacq9BKZnwAhJJZ+4g7MDhU2KI2y4k=; b=LIYtB5CoZFJNZzyg4kryFbl8XG+/027xOA6eoBn8WC+49kdzPrtY0GxN7l3CxAd6r5xzEuyc6zMkjW6Qw0pjKTWRxvrzOvB5GBw9bE/7qcqHItuIVDL0YqQcqUec/eW/0KR8LNW8NKIaZ/t9VGjVS5QZiqjVw9FdGEgcdQyCKcY= Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0261.namprd18.prod.outlook.com (10.163.72.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Wed, 4 Jan 2017 22:53:01 +0000 Received: from BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) by BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) with mapi id 15.01.0817.009; Wed, 4 Jan 2017 22:53:01 +0000 From: Keyur Patel To: Jonathan Hardwick , "Alvaro Retana (aretana)" , Zhangxian Xian , "Jon Hudson" Thread-Topic: draft-ietf-sidr-bgpsec-protocol Thread-Index: AQHSZthkNfH8MXPYLkOmxwl9coeqv6EoZskA Date: Wed, 4 Jan 2017 22:53:01 +0000 Message-ID: References: In-Reply-To: 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=keyur@arrcus.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2602:306:c446:9490:c160:7303:35b8:9b52] x-ms-office365-filtering-correlation-id: d30f5182-0dc2-471f-e733-08d434f46fb3 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR18MB0261; x-microsoft-exchange-diagnostics: 1; BY2PR18MB0261; 7:joWYA82vzxYcLH/3gCooZZ8qo1OTWOpulyl8x1XhYwAw3hHDdd+ideqrpCQpyStqh2sVHFxROB8ij0bfWK0lzzcS+/Drs43/NcGgr1u4LFGqzWfzamg44UZKIWG3p+AgdUAJrQyj4hB78tzlOBGWvOrt3eWBgIVOVUOO/rm1EpO9Qbu3ptO1rjhAWE6CrBhyoecm3ZyycVWrMZ17pExRooF+ftPeCmq1LVPhzKhysc0DELi7u4vVpThO5tN2WdNMmO4w+f9kPznKoXhYdR5wavnQ7bWn1NfIUlgEJeq67MXco4ssCxfAkHtyrHq3TcB6LX4cftjGxgw1UG3wEJV8qT+q5CSYcUuQMf6Snbbjd8DYmdtceL6JsYUUeF3depJY/qXMuDoWlOMEbwSxGi96biS+hLlMF0tzzGX4ZR8ZLEerETre0Rw0hTHEnLxTxhgjguGGXt3ZGeMho8XRwi+68g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(50582790962513)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(2016111802025)(20161123564025)(20161123562025)(6072148)(6043046); SRVR:BY2PR18MB0261; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0261; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(7916002)(39410400002)(39450400003)(39830400002)(199003)(377454003)(189002)(54896002)(81166006)(122556002)(5660300001)(230783001)(8656002)(189998001)(101416001)(2906002)(54906002)(50986999)(54356999)(2900100001)(102836003)(106356001)(68736007)(92566002)(6306002)(106116001)(105586002)(76176999)(38730400001)(6116002)(3660700001)(229853002)(6506006)(6486002)(6512006)(97736004)(6436002)(36756003)(83716003)(82746002)(25786008)(33656002)(7736002)(99286003)(8936002)(5001770100001)(2950100002)(7416002)(39060400001)(4326007)(81156014)(8676002)(3280700002)(77096006)(86362001)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0261; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_C3B0482B10074B29B178DE98C062E197arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2017 22:53:01.4636 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0261 X-MDID: 1483570394-1hvfSYrvpfm2 Archived-At: Cc: Routing Directorate , sidr , "Sriram, Kotikalapudi \(Fed\)" , "mlepinski@ncf.edu" , "sidr-chairs@ietf.org" , Routing ADs Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 22:53:22 -0000 --_000_C3B0482B10074B29B178DE98C062E197arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W2FkZGluZyByb3V0aW5nLWFkc10NCg0KRnJvbTogS2V5dXIgUGF0ZWwgPGtleXVyQGFycmN1cy5j b20+DQpEYXRlOiBXZWRuZXNkYXksIEphbnVhcnkgNCwgMjAxNyBhdCAyOjE3IFBNDQpUbzogSm9u YXRoYW4gSGFyZHdpY2sgPGpvbmF0aGFuLmhhcmR3aWNrQG1ldGFzd2l0Y2guY29tPiwgIkFsdmFy byBSZXRhbmEgKGFyZXRhbmEpIiA8YXJldGFuYUBjaXNjby5jb20+LCBaaGFuZ3hpYW4gWGlhbiA8 emhhbmcueGlhbkBodWF3ZWkuY29tPiwgSm9uIEh1ZHNvbiA8am9uLmh1ZHNvbkBnbWFpbC5jb20+ DQpDYzogcnRnLWRpciA8cnRnLWRpci1ib3VuY2VzQGlldGYub3JnPiwgInNpZHItY2hhaXJzQGll dGYub3JnIiA8c2lkci1jaGFpcnNAaWV0Zi5vcmc+LCBzaWRyIDxzaWRyLWJvdW5jZXNAaWV0Zi5v cmc+LCAiU3JpcmFtLCBLb3Rpa2FsYXB1ZGkgKEZlZCkiIDxrb3Rpa2FsYXB1ZGkuc3JpcmFtQG5p c3QuZ292PiwgIm1sZXBpbnNraUBuY2YuZWR1IiA8bWxlcGluc2tpQG5jZi5lZHU+DQpTdWJqZWN0 OiBkcmFmdC1pZXRmLXNpZHItYmdwc2VjLXByb3RvY29sDQoNCkhlbGxvLA0KDQpBcG9sb2dpZXMg Zm9yIHRoZSBkZWxheWVkIHJlc3BvbnNlLg0KDQpJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUg Um91dGluZyBEaXJlY3RvcmF0ZSBRQSByZXZpZXdlciBmb3IgZHJhZnQtaWV0Zi1zaWRyLWJncHNl Yy1wcm90b2NvbC4NCg0KVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgUUEgcmV2aWV3cyBhcmUgaW50 ZW5kZWQgdG8gYmUgYSBzdXBwb3J0IHRvIGltcHJvdmUgdGhlIHF1YWxpdHkgb2YgUlRHIEFyZWEg ZG9jdW1lbnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIHRoZSBJRVRGIHByb2Nlc3MuIFRoaXMgaXMg dGhlIFFBIHJldmlldyBhdCB0aGUgdGltZSBvZiB0aGUgV0cgZG9jdW1lbnQgYWRvcHRpb24gcG9s bC4NCg0KU3VtbWFyeToNCg0KVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgQkdQc2VjLCBhbiBleHRl bnNpb24gdG8gdGhlIEJvcmRlciBHYXRld2F5ICBQcm90b2NvbCAoQkdQKSB0aGF0IHByb3ZpZGVz IHNlY3VyaXR5IGZvciB0aGUgcGF0aCBvZiBhdXRvbm9tb3VzIHN5c3RlbXMgKEFTZXMpIHRocm91 Z2ggd2hpY2ggYSBCR1AgdXBkYXRlIG1lc3NhZ2UgcGFzc2VzLg0KVGhlIGRvY3VtZW50IGlzIHdl bGwgd3JpdHRlbiwgZWFzeSB0byByZWFkIGFuZCBmb2xsb3cuIFNvbWUgbWlub3IgY29tbWVudHMg YXJlIGxpc3RlZCBiZWxvdzoNCg0KQ29tbWVudHMgZm9yIHRoZSBhdXRob3JzOg0KDQoNCjEpICAg ICAgU2VjdGlvbiA0LjEg4oCcVGhlIEJHUHNlYyBQYXRoIGF0dHJpYnV0ZSBhbmQgdGhlIEFTX1BB VEggYXR0cmlidXRlIGFyZSBtdXR1YWxseSBleGNsdXNpdmUuIFRoYXQgaXMsIGFueSB1cGRhdGUg bWVzc2FnZSBjb250YWluaW5nIHRoZSBCR1BzZWMgUGF0aCBhdHRyaWJ1dGUgTVVTVCBOT1QgY29u dGFpbiB0aGUgQVNfUEFUSCBhdHRyaWJ1dGXigJ0uICBGb3IgYW55IHJlc3RhcnRpbmcgc3BlYWtl cnMgaW4gYSBHUiBtb2RlLCB3aGVyZSB0aGUgYmdwIGNhcGFiaWxpdHkgaXMgbm90IGV4Y2hhbmdl ZCwgdGhlIGV4aXN0aW5nIHN0YWxlIHJvdXRlcyB3b27igJl0IGhhdmUgYW4gQVNfUEFUSCBhdHRy aWJ1dGUuIFdlIGNvdWxkIGFkZCBzb21lIGNsYXJpZnlpbmcgdGhhdCBoZWxwcyB0byBpbmRpY2F0 ZSB0aGF0IHN1Y2ggcm91dGVzIHNob3VsZCBiZSBjb25zaWRlcmVkIHZhbGlkIGluIHN0YWxlIG1v ZGUgKHRpbGwgdGhleSBnZXQgcmVmcmVzaGVkKT8NCg0KDQoNCjIpICAgICAgIDQuMSA0dGggcGFy YWdyYXBoOiDigJxOb3RlIGFsc28gdGhhdCBuZXcgc2lnbmF0dXJlcyBhcmUgb25seSBhZGRlZCB0 byBhIEJHUHNlYyB1cGRhdGUgbWVzc2FnZSB3aGVuIGEgQkdQc2VjIHNwZWFrZXIgaXMgZ2VuZXJh dGluZyBhbiB1cGRhdGUgbWVzc2FnZSB0byBzZW5kIHRvIGFuIGV4dGVybmFsIHBlZXIgKGkuZS4s IHdoZW4gdGhlIEFTIG51bWJlciBvZiB0aGUgcGVlciBpcyBub3QgZXF1YWwgdG8gdGhlIEJHUHNl YyBzcGVha2VyJ3Mgb3duIEFTIG51bWJlcikuICBUaGVyZWZvcmUsIGEgQkdQc2VjIHNwZWFrZXIg d2hvIG9ubHkgc2VuZHMgQkdQc2VjIHVwZGF0ZSBtZXNzYWdlcyB0byBwZWVycyB3aXRoaW4gaXRz IG93biBBUyBkb2VzIG5vdCBuZWVkIHRvIHBvc3Nlc3MgYW55IHByaXZhdGUgc2lnbmF0dXJlIGtl eXMu4oCdIFRoaXMgdGV4dCBkb2VzbuKAmXQgc2VlbSB0byBhcHBseSB0byBjb25mZWQgcGVlcnM/ IElmIHNvLCBpdCB3b3VsZCBiZSBuaWNlIHRvIGNsYXJpZnkgdGhhdCB0aGlzIHRleHQgZG9lc27i gJl0IGFwcGx5IHRvIGFueSBjb25mZWQgcGVlcnMuDQoNCg0KDQoNCjMpICAgICAgU2VjdGlvbiA1 IGFuZCBTZWN0aW9uIDUuMiwgMXN0IHBhcmFncmFwaDogUkZDNDI3MSBjb25zaWRlcnMgdXBkYXRl IG1lc3NhZ2UgcmVjZWl2ZWQgd2l0aG91dCBhIHdlbGxrbm93biBBU19QQVRIIGF0dHJpYnV0ZSBh cyBhbiBlcnJvci4gIFdlIG5lZWQgc29tZSB0ZXh0IHRvIGNsYXJpZnkgdGhlIChlcnJvciBoYW5k bGluZyBpZiBhbnkpIGJlaGF2aW9yIHdoZW4gYW4gdXBkYXRlIG1lc3NhZ2UgaXMgcmVjZWl2ZWQg d2l0aG91dCBhIGJncHNlYyBhbmQgYW4gYXNwYXRoIGF0dHJpYnV0ZS4gVGhlIGN1cnJlbnQgZHJh ZnQgdGV4dCBzZWVtcyB1bmNsZWFyIGFib3V0IGdlbmVyYXRpb24gb2YgYmdwc2VjIGF0dHJpYnV0 ZSBhcyB3ZWxsIChpbiBhIGliZ3Agc2NlbmFyaW8pLiBJcyBpdCBhIHJlcXVpcmVtZW50IHRvIGdl bmVyYXRlIGFuIGVtcHR5IGJncHNlYyBhdHRyaWJ1dGU/DQoNCg0KNCkgICAgICBXaXRoIGFuIEFT X1BBVEggYXR0cmlidXRlIGluIDQyNzEgdGhlcmUgd2FzIGxvb3AgZGV0ZWN0aW9uIGluIHBsYWNl LiAgV2l0aCBCR1BTZWMgSSBkb27igJl0IHNlZSB0aGF0IGJlaW5nIGNhbGxlZCBleHBsaWNpdGx5 IG90aGVyIHRoYW4gYSBwYXNzaW5nIHJlbWFyayBpbiBzZWN0aW9uIDUuIFNlY3Rpb24gNS4yIHNo b3VsZCBoYXZlIGEgY2hlY2sgdGhhdCBhbGxvd3MgYSBCR1BzZWMgc3BlYWtlciB0byBiYWlsIG91 dCBvZiBhIHZhbGlkYXRpb24gcHJvY2VkdXJlIHdoZW4gYSBhc3BhdGggbG9vcCBpcyBkZXRlY3Rl ZC4NCg0KDQpCZXN0IFJlZ2FyZHMsDQpLZXl1cg0K --_000_C3B0482B10074B29B178DE98C062E197arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <77F47326F320BB4A929B94A8196923FA@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJy aTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNDM1NDQwNzExOw0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTY3MjU1MzU4NCA2NzY5ODcwNSA2NzY5ODcxMyA2 NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4 dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBw dDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjND MSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlthZGRpbmcgcm91dGluZy1hZHNdPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+S2V5dXIgUGF0ZWwgJmx0O2tleXVyQGFycmN1cy5jb20m Z3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgSmFudWFyeSA0LCAyMDE3IGF0IDI6MTcg UE08YnI+DQo8Yj5UbzogPC9iPkpvbmF0aGFuIEhhcmR3aWNrICZsdDtqb25hdGhhbi5oYXJkd2lj a0BtZXRhc3dpdGNoLmNvbSZndDssICZxdW90O0FsdmFybyBSZXRhbmEgKGFyZXRhbmEpJnF1b3Q7 ICZsdDthcmV0YW5hQGNpc2NvLmNvbSZndDssIFpoYW5neGlhbiBYaWFuICZsdDt6aGFuZy54aWFu QGh1YXdlaS5jb20mZ3Q7LCBKb24gSHVkc29uICZsdDtqb24uaHVkc29uQGdtYWlsLmNvbSZndDs8 YnI+DQo8Yj5DYzogPC9iPnJ0Zy1kaXIgJmx0O3J0Zy1kaXItYm91bmNlc0BpZXRmLm9yZyZndDss ICZxdW90O3NpZHItY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtzaWRyLWNoYWlyc0BpZXRmLm9y ZyZndDssIHNpZHIgJmx0O3NpZHItYm91bmNlc0BpZXRmLm9yZyZndDssICZxdW90O1NyaXJhbSwg S290aWthbGFwdWRpIChGZWQpJnF1b3Q7ICZsdDtrb3Rpa2FsYXB1ZGkuc3JpcmFtQG5pc3QuZ292 Jmd0OywgJnF1b3Q7bWxlcGluc2tpQG5jZi5lZHUmcXVvdDsgJmx0O21sZXBpbnNraUBuY2YuZWR1 Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5kcmFmdC1pZXRmLXNpZHItYmdwc2VjLXByb3RvY29s PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IZWxsbyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXBvbG9naWVzIGZvciB0aGUgZGVsYXll ZCByZXNwb25zZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIGJlZW4gc2VsZWN0ZWQg YXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgUUEgcmV2aWV3ZXIgZm9yDQo8Yj5kcmFmdC1pZXRm LXNpZHItYmdwc2VjLXByb3RvY29sLiA8L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBS b3V0aW5nIERpcmVjdG9yYXRlIFFBIHJldmlld3MgYXJlIGludGVuZGVkIHRvIGJlIGEgc3VwcG9y dCB0byBpbXByb3ZlIHRoZSBxdWFsaXR5IG9mIFJURyBBcmVhIGRvY3VtZW50cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCB0aGUgSUVURiBwcm9jZXNzLiBUaGlzIGlzIHRoZSBRQSByZXZpZXcgYXQgdGhl IHRpbWUgb2YgdGhlIFdHIGRvY3VtZW50IGFkb3B0aW9uIHBvbGwuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlN1bW1hcnk6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZG9jdW1lbnQgZGVz Y3JpYmVzIEJHUHNlYywgYW4gZXh0ZW5zaW9uIHRvIHRoZSBCb3JkZXIgR2F0ZXdheSAmbmJzcDtQ cm90b2NvbCAoQkdQKSB0aGF0IHByb3ZpZGVzIHNlY3VyaXR5IGZvciB0aGUgcGF0aCBvZiBhdXRv bm9tb3VzIHN5c3RlbXMgKEFTZXMpIHRocm91Z2ggd2hpY2ggYSBCR1AgdXBkYXRlIG1lc3NhZ2Ug cGFzc2VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGRvY3VtZW50 IGlzIHdlbGwgd3JpdHRlbiwgZWFzeSB0byByZWFkIGFuZCBmb2xsb3cuIFNvbWUgbWlub3IgY29t bWVudHMgYXJlIGxpc3RlZCBiZWxvdzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29tbWVudHMg Zm9yIHRoZSBhdXRob3JzOiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEpPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlNlY3Rpb24gNC4xIOKAnFRoZSBCR1Bz ZWMgUGF0aCBhdHRyaWJ1dGUgYW5kIHRoZSBBU19QQVRIIGF0dHJpYnV0ZSBhcmUgbXV0dWFsbHkg ZXhjbHVzaXZlLiBUaGF0IGlzLCBhbnkgdXBkYXRlIG1lc3NhZ2UgY29udGFpbmluZyB0aGUgQkdQ c2VjIFBhdGggYXR0cmlidXRlIE1VU1QgTk9UIGNvbnRhaW4gdGhlIEFTX1BBVEggYXR0cmlidXRl 4oCdLiZuYnNwOyBGb3IgYW55IHJlc3RhcnRpbmcgc3BlYWtlcnMgaW4gYSBHUiBtb2RlLA0KIHdo ZXJlIHRoZSBiZ3AgY2FwYWJpbGl0eSBpcyBub3QgZXhjaGFuZ2VkLCB0aGUgZXhpc3Rpbmcgc3Rh bGUgcm91dGVzIHdvbuKAmXQgaGF2ZSBhbiBBU19QQVRIIGF0dHJpYnV0ZS4gV2UgY291bGQgYWRk IHNvbWUgY2xhcmlmeWluZyB0aGF0IGhlbHBzIHRvIGluZGljYXRlIHRoYXQgc3VjaCByb3V0ZXMg c2hvdWxkIGJlIGNvbnNpZGVyZWQgdmFsaWQgaW4gc3RhbGUgbW9kZSAodGlsbCB0aGV5IGdldCBy ZWZyZXNoZWQpPw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mik8c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+Jm5ic3A7NC4xIDR0aCBwYXJhZ3Jh cGg6Jm5ic3A74oCcTm90ZSBhbHNvIHRoYXQgbmV3IHNpZ25hdHVyZXMmbmJzcDthcmUgb25seSBh ZGRlZCB0byBhIEJHUHNlYyB1cGRhdGUgbWVzc2FnZSB3aGVuIGEgQkdQc2VjIHNwZWFrZXIgaXMg Z2VuZXJhdGluZyBhbiB1cGRhdGUgbWVzc2FnZSB0byBzZW5kIHRvIGFuIGV4dGVybmFsIHBlZXIg KGkuZS4sIHdoZW4gdGhlIEFTIG51bWJlciBvZiB0aGUgcGVlciBpcyBub3QgZXF1YWwgdG8gdGhl DQogQkdQc2VjIHNwZWFrZXIncyBvd24gQVMgbnVtYmVyKS4mbmJzcDsmbmJzcDtUaGVyZWZvcmUs IGEgQkdQc2VjIHNwZWFrZXIgd2hvIG9ubHkgc2VuZHMgQkdQc2VjIHVwZGF0ZSBtZXNzYWdlcyB0 byBwZWVycyB3aXRoaW4gaXRzIG93biBBUyBkb2VzIG5vdCBuZWVkIHRvIHBvc3Nlc3MgYW55IHBy aXZhdGUgc2lnbmF0dXJlIGtleXMu4oCdIFRoaXMgdGV4dCBkb2VzbuKAmXQgc2VlbSB0byBhcHBs eSB0byBjb25mZWQgcGVlcnM/IElmIHNvLCBpdCB3b3VsZCBiZSBuaWNlIHRvDQogY2xhcmlmeSB0 aGF0IHRoaXMgdGV4dCBkb2VzbuKAmXQgYXBwbHkgdG8gYW55IGNvbmZlZCBwZWVycy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPjMpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPlNlY3Rpb24gNSBhbmQgU2VjdGlvbiA1LjIsIDFzdCBwYXJhZ3JhcGg6IFJGQzQyNzEgY29u c2lkZXJzIHVwZGF0ZSBtZXNzYWdlIHJlY2VpdmVkIHdpdGhvdXQgYSB3ZWxsa25vd24gQVNfUEFU SCBhdHRyaWJ1dGUgYXMgYW4gZXJyb3IuJm5ic3A7Jm5ic3A7V2UgbmVlZCBzb21lIHRleHQgdG8g Y2xhcmlmeSB0aGUgKGVycm9yIGhhbmRsaW5nIGlmIGFueSkgYmVoYXZpb3Igd2hlbiBhbiB1cGRh dGUgbWVzc2FnZSBpcyByZWNlaXZlZA0KIHdpdGhvdXQgYSBiZ3BzZWMgYW5kIGFuIGFzcGF0aCBh dHRyaWJ1dGUuIFRoZSBjdXJyZW50IGRyYWZ0IHRleHQgc2VlbXMgdW5jbGVhciBhYm91dCBnZW5l cmF0aW9uIG9mIGJncHNlYyBhdHRyaWJ1dGUgYXMgd2VsbCAoaW4gYSBpYmdwIHNjZW5hcmlvKS4g SXMgaXQgYSByZXF1aXJlbWVudCB0byBnZW5lcmF0ZSBhbiBlbXB0eSBiZ3BzZWMgYXR0cmlidXRl PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi4yNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj40KTxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5XaXRoIGFuIEFTX1BB VEggYXR0cmlidXRlIGluIDQyNzEgdGhlcmUgd2FzIGxvb3AgZGV0ZWN0aW9uIGluIHBsYWNlLiZu YnNwOyZuYnNwO1dpdGggQkdQU2VjIEkgZG9u4oCZdCBzZWUgdGhhdCBiZWluZyBjYWxsZWQgZXhw bGljaXRseSBvdGhlciB0aGFuIGEgcGFzc2luZyByZW1hcmsgaW4gc2VjdGlvbiA1LiBTZWN0aW9u IDUuMiBzaG91bGQgaGF2ZSBhIGNoZWNrIHRoYXQgYWxsb3dzIGEgQkdQc2VjIHNwZWFrZXIgdG8g YmFpbA0KIG91dCBvZiBhIHZhbGlkYXRpb24gcHJvY2VkdXJlIHdoZW4gYSBhc3BhdGggbG9vcCBp cyBkZXRlY3RlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5LZXl1cjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_C3B0482B10074B29B178DE98C062E197arrcuscom_-- From nobody Wed Jan 4 15:11:59 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7F9129426; Wed, 4 Jan 2017 15:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 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, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham 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 WVEDQK6CBdc1; Wed, 4 Jan 2017 15:11:54 -0800 (PST) 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 9981F127076; Wed, 4 Jan 2017 15:11:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 798B8BE32; Wed, 4 Jan 2017 23:11:51 +0000 (GMT) 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 Zf1ch_EMTiqV; Wed, 4 Jan 2017 23:11:49 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2B89EBE2F; Wed, 4 Jan 2017 23:11:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483571509; bh=Nvb5ToAvbIUbhAAaX8OX4pc5xNScbKjjoOx4R1q+oPM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=V6ZCvMiHMOWbFoE/goavIZ8B7TYEBubN4THKCUCxbBVp9ld55Hkn/PJTHm1ITBxit FlDa/EhcabC0Hn1aCvpxOeji5MpubbbgkpTerdlOqKd337LD6/qdePHJlKVgYfnfM4 gafrZl/xuUe98yd7a9h9GWjP+P+vQhhrEvpAb9Qc= To: Rob Austein References: <148353788046.13042.160471261406266.idtracker@ietfa.amsl.com> <20170104200413.1DFD04581178@minas-ithil.hactrn.net> <99955d9c-4771-dd45-f019-313661631e87@cs.tcd.ie> <20170104221557.73CF84581C4F@minas-ithil.hactrn.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <0811b400-fc2a-8675-7b74-4b549940de65@cs.tcd.ie> Date: Wed, 4 Jan 2017 23:11:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170104221557.73CF84581C4F@minas-ithil.hactrn.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070408020000060603050304" Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 23:11:57 -0000 This is a cryptographically signed message in MIME format. --------------ms070408020000060603050304 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 04/01/17 22:15, Rob Austein wrote: > At Wed, 4 Jan 2017 20:57:24 +0000, Stephen Farrell wrote: >> On 04/01/17 20:04, Rob Austein wrote: > ... >>> This draft is a profile of RFC 6487, which is itself a profile of RFC= >>> 5280. All of the above is pretty much verbatim from RFC 6487. >> >> Hmm. I wonder if that's the best plan, especially if there's >> no interop justification for some of it. >=20 > The theory, such as it is, goes: >=20 > * RPKI is a tightly constrained profile of X.509v3, with almost > everything either required or forbidden, to reduce the number of > grey areas. >=20 > * The BGPSEC profile is a minimal set of changes and extensions to the > RPKI profile: same overall goal, slightly different constraints. >=20 >> I note that 6487 says "In the RPKI, the subject name is determined >> by the issuer, not proposed by the subject" but that seems a bit >> weird for routers, where I would guess there'll be more diversity in >> terms of key/CSR generation code. >=20 > Well, strictly speaking the subject name is always selected by the > issuer in X.509, but I know what you mean. >=20 > RFC 6487 is weird about this because various parties were extremely > concerned to avoid anything that could be construed as certification > of real-world identity, ie, they did not want to find themselves in > the mainstream PKI business. So RPKI uses meaningless names and has > the ability to enforce that, hence the text you note in RFC 6487. I'd say any concerns that the web PKI CAs might have had ought now be ameliorated (or OBE, give letsencrypt), so not trodding on mainstream CA business is probably not as much as concern as was the case at the start of the RPKI work. >=20 > RFC 6487 6.1.1 does in fact allow the subject to include a subject > name in the PKCS #10 request, but the text is loaded with weasel > words. Speaking as someone who has implemented all of this, I find > the RFC 6487 constraints on subject name in PKCS #10 requests a bit > excessive, but that's not the document currently under discussion. Well, except that this draft does re-iterate some of those now clearly weird MUSTs. >=20 >> (Correct me if I'm wrong but I'm not sure if it's possible to >> conform to these requirements with e.g. openssl, or is it?) >=20 > The OpenSSL command line tool would probably fight hard against either > omitting the subject field from the PKCS #10 request or allowing it to > be NULL. The former (field absent) is not even syntactically legal > X.509. The latter (present but NULL) is legal but kind of unusual: > RFC 5280 4.1.2.6 allows it in certificates if a critical, non-empty > subjectAltName extension is present, RFC 2986 is silent on the subject > and is only informational in any case. >=20 > I'm pretty sure that the OpenSSL library would allow the > present-but-NULL form, but haven't tested it (recently? ever? don't > recall...). >=20 > In practice, I don't think any of the RKI CA implementations reject > PKCS #10 requests for having a non-NULL subject, they just ignore it. >=20 > All of this is still a problem with RFC 6487, which we should have > caught five years ago. Oops. Not sure what the best approach is when > trying to sub-profile a profile with a known wart like this. Fair point. So assuming there isn't a chorus of WG participants asking to remove the weird constraints then I'd say the right thing must be to not re-iterate any weirdness from 6487 but to only inherit that by reference. That way, if/when we modify 6487, we won't have to do the same with this, and maybe also hit problems with these constraints being enforced by code in two places. I think the only such text I saw (that re-iterates 6487) was in 3.1.1 but there might I guess be more. >=20 >>>> And I'd wonder if router cert revocation will be more common than >>>> for other resource certs, in which case an OCSP-like system could be= >>>> needed - did the WG consider that? >>> >>> Not as such. Fair question, but the architecture kind of assumes tha= t >>> the RPKI RP process is separable from the BGPSEC implementation per >>> se, BGPSEC just consumes the output of that process. >> >> I'd wonder if that means some revocation request protocol will be >> needed later. But it's fine to not try define that now. >=20 > Fair point. >=20 >> More to the point is whether or not the WG have thought about the >> revocation support in the RPKI and whether or not that seems also >> ok for BGPsec. (I'm unsure myself, but mostly due to the number of >> moving parts in the RPKI.) >=20 > Has been discussed, somewhat noisily. Ask a SIDR WG chair if you want > an opinion on WG consensus. My own take is that router keys probably > get whacked on roughly the same kind of timescale as other RPKI keys, > so if the revocation mechanism is good enough for everything else, > it's probably good enough for router keys. YMMV. Fair enough. Again, assuming that there's no chorus wanting change, I'll clear this point as well. Cheers, S. >=20 >>> Most likely implementation technique does all the RPKI stuff per se o= n >>> a separate box and just stuffs the resulting raw keys into the router= >>> using the rpki-rtr protocol, so the router itself probably would not >>> have the information needed to play OCSP even if it wanted to do so, >>> which it probably doesn't. =20 >> >> So if that's a widely shared view of WG participants then it'd be >> good to see it described somewhere to help implementers. (It may >> be in the -overview document which I've yet to read.) >=20 > It's sort of in RFC 6810 (rpki-rtr). The update to RFC 6810 is > stalled because I dropped the ball last year. >=20 >>> Requiring the routers to speak OCSP seems >>> like a potentially dangerous layering violation. >> >> Not sure about a layering violation but I can see it'd likely be >> problematic;-) >=20 > I had front-row tickets to the "let's stuff routing policy data into > the DNS!" show back in the '90s. My main take-away from that mess was > a fear of real-time circular dependencies. >=20 --------------ms070408020000060603050304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDQy MzExNDhaMC8GCSqGSIb3DQEJBDEiBCDW8AYcAtqkd6VVyxWAEP9OioVxhCUkJfnOptyGmvgb AzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCqgRkhwuv8KWvX+weS88l0Py3rOOInzAZr/9oclVcScPSIC/q6GCjC XWQuaRczskpG78L9Q/kMRfXVvnke6UjZXI9J3ocn3x2/wm3op8+EzCXg9S4XUIHoVmeG/4Y1 isKZ1fwDtkGpQvu8qgagLWv9NrpkXb1IS6e10S/KryTA+0sE5CMyy4WRF1rJUbuJMAFRnmwI /DKZ1XnnhIyUwxlRvVegOj8P5qG9igDWYqHo6uEQFy43DwL678q8uyByFaUXnm9X+iX8fDJT cpwQgkmY8IeBjdMOnPP2P4iSIaVNy9+Y3bYvgAXTjai+vkZIpHgpPA2qCfrYqaYIjNOCNesA AAAAAAAA --------------ms070408020000060603050304-- From nobody Wed Jan 4 15:20:06 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFAA129422; Wed, 4 Jan 2017 15:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 RrUQ32nG2CgR; Wed, 4 Jan 2017 15:20:01 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 AB6441297B8; Wed, 4 Jan 2017 15:19:56 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v04NJtRO099106 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Jan 2017 17:19:56 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Sean Turner" Date: Wed, 04 Jan 2017 17:19:55 -0600 Message-ID: In-Reply-To: References: <148356402580.12969.9796089522192063819.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-pki-profiles-19: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 23:20:03 -0000 On 4 Jan 2017, at 16:37, Sean Turner wrote: > -2: draft-ietf-sidr-bgpsec-protocol explicitly excludes > non-capitalized >> versions of 2119 words. This draft does not. It seems different 2119 >> approaches among the various bgpsec draft could be confusing to the >> reader. > > > Where’s that in draft-ietf-sidr-bgpsec-protocol? > > Regardless, I’m not sure that restoration will work in this draft > because there are repeated MUST requirements from other RFC and my AD > told me to not capitalize them :) Oops, sorry, I meant to say draft-ietf-sidr-bgpsec-ops. Maybe I misunderstand what you mean; are the non-capitalized requirements from other drafts intended as normative for _this_ draft? If not, then the treatment of non-capitalized 2119 words as normal English seems to help. Thanks! Ben. From nobody Wed Jan 4 15:21:34 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B4312984F for ; Wed, 4 Jan 2017 15:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, 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 vLW4MbWkPVXZ for ; Wed, 4 Jan 2017 15:21:31 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 5E67F12984A for ; Wed, 4 Jan 2017 15:21:29 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id a20so27470617qkc.1 for ; Wed, 04 Jan 2017 15:21:29 -0800 (PST) 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=kfF2Lhv+YAQT5zCJeAZd+E8RIO/LxOhPzdo6xM/2XnI=; b=lsMLY9O1/Dzby/djh1tU7Sze6WBNwbDm5fh92Xry1bT0ObqgkTboTvAkisFBiwpcjf SDBy0XH4be4gnHXpyUNNmKNlJzhd4oI5uAun05N5mJr40444d1cJucbHTz5YkJvBmZKC 3W2k39rj/6kwZn+BUHNx6nwk/nC6qn1wBXIoM= 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=kfF2Lhv+YAQT5zCJeAZd+E8RIO/LxOhPzdo6xM/2XnI=; b=fn5hyvK/I/2JVFqCZp+GBPIjzGz2dF7k0yjtfTY2dlCJ/ow/F/1VFVDqyuny7WE6I/ Cv1HJdWdMw2lKwjX2QPPn75X2FQJjotzqChazxD9t7wZOG1ctkBOaDo85p5fbKRg0+W8 trCuQmOOq1q+VBd0nDJu3J7ry94C5ilniZ1rweS2bP1wJvLfwjhg4pySTorYOp4tYv0m cDQvDAntjDN7vyXa1666bJ1I4xLuszvrho5S9HLHJGHY3EwSJE8ar7DPIxHRKofRCnZM qEc89aSoQDDRYoqSaYTGqtODCSOCqcCcKc3poIcnCSBfMKefDJWX0MQ/hhr8V3GdJQHj /OgA== X-Gm-Message-State: AIkVDXJUoVzJjdytD/XwHdqcSMqS2YysZoLuUkPugfyGKuHB1zj2s07WtA8zK2aAGYOeQw== X-Received: by 10.233.223.196 with SMTP id t187mr74099006qkf.135.1483572088553; Wed, 04 Jan 2017 15:21:28 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id k26sm31703939qtc.36.2017.01.04.15.21.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Jan 2017 15:21:27 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Wed, 4 Jan 2017 18:21:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148356402580.12969.9796089522192063819.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-pki-profiles-19: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 23:21:32 -0000 > On Jan 4, 2017, at 18:19, Ben Campbell wrote: >=20 > On 4 Jan 2017, at 16:37, Sean Turner wrote: >=20 >> -2: draft-ietf-sidr-bgpsec-protocol explicitly excludes = non-capitalized >>> versions of 2119 words. This draft does not. It seems different 2119 >>> approaches among the various bgpsec draft could be confusing to the >>> reader. >>=20 >>=20 >> Where=E2=80=99s that in draft-ietf-sidr-bgpsec-protocol? >>=20 >> Regardless, I=E2=80=99m not sure that restoration will work in this = draft because there are repeated MUST requirements from other RFC and my = AD told me to not capitalize them :) >=20 > Oops, sorry, I meant to say draft-ietf-sidr-bgpsec-ops. >=20 > Maybe I misunderstand what you mean; are the non-capitalized = requirements from other drafts intended as normative for _this_ draft? = If not, then the treatment of non-capitalized 2119 words as normal = English seems to help. >=20 It=E2=80=99s more like: "As defined in RFC mubleqsuat, client must do = this.=E2=80=9D The thinking goes (and I agree) that we should repeat = requirements if we=E2=80=99re just quoting them. spt From nobody Wed Jan 4 15:23:17 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A9B1297E8; Wed, 4 Jan 2017 15:23:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148357219612.13068.224046269873957367.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 15:23:16 -0800 Archived-At: Cc: draft-ietf-sidr-bgpsec-protocol@ietf.org, sidr-chairs@ietf.org, m.waehlisch@fu-berlin.de, sidr@ietf.org Subject: [sidr] Ben Campbell's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 23:23:16 -0000 Ben Campbell has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share some of the concerns about deployability, but have nothing new to add to that conversation. Otherwise I just have a few minor comments: -2: draft-ietf-sidr-bgpsec-protocol explicitly excludes non-capitalized versions of 2119 words. This draft does not. It seems different 2119 approaches among the various bgpsec draft could be confusing to the reader. [Update: Oops, sorry, I meant to say draft-ietf-sidr-bgpsec-ops excludes non-capitalized versions of 2119 words. (That is to say, it treats them as their normal English equivalents.)] - 5.2, step 2: I'm almost sure I've missed something here, but if I understand correctly, previous sections talked about how a peer can propagate a BGPsec_Path attribute without modification. Will that cause a problem in this step if the immediate peer propagated an unmodified BGPsec_Path that came from a different AS? - 8.4, last paragraph: The text describes a replay attack, and delegates the mitigation solution to draft-ietf-sidr-bgpsec-rollover. This is an informational reference; it seems like it should be normative. From nobody Wed Jan 4 15:26:52 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6AB12945B; Wed, 4 Jan 2017 15:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 Y7kfNdZfJuIh; Wed, 4 Jan 2017 15:26:49 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B4871129422; Wed, 4 Jan 2017 15:26:49 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v04NQmGU099776 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Jan 2017 17:26:48 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Sean Turner" Date: Wed, 04 Jan 2017 17:26:48 -0600 Message-ID: In-Reply-To: References: <148356402580.12969.9796089522192063819.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-pki-profiles-19: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 23:26:51 -0000 On 4 Jan 2017, at 17:21, Sean Turner wrote: >> On Jan 4, 2017, at 18:19, Ben Campbell wrote: >> >> On 4 Jan 2017, at 16:37, Sean Turner wrote: >> >>> -2: draft-ietf-sidr-bgpsec-protocol explicitly excludes >>> non-capitalized >>>> versions of 2119 words. This draft does not. It seems different >>>> 2119 >>>> approaches among the various bgpsec draft could be confusing to the >>>> reader. >>> >>> >>> Where’s that in draft-ietf-sidr-bgpsec-protocol? >>> >>> Regardless, I’m not sure that restoration will work in this draft >>> because there are repeated MUST requirements from other RFC and my >>> AD told me to not capitalize them :) >> >> Oops, sorry, I meant to say draft-ietf-sidr-bgpsec-ops. >> >> Maybe I misunderstand what you mean; are the non-capitalized >> requirements from other drafts intended as normative for _this_ >> draft? If not, then the treatment of non-capitalized 2119 words as >> normal English seems to help. >> > > It’s more like: "As defined in RFC mubleqsuat, client must do > this.” The thinking goes (and I agree) that we should repeat > requirements if we’re just quoting them. Without getting into specific reasoning either way: My comment was not meant to be binding, just something to consider. Ben. t From nobody Wed Jan 4 15:57:08 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3801294BE for ; Wed, 4 Jan 2017 15:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, 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 XS9pmxCn435K for ; Wed, 4 Jan 2017 15:56:59 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 18BCB129440 for ; Wed, 4 Jan 2017 15:56:59 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id n21so417484679qka.3 for ; Wed, 04 Jan 2017 15:56:59 -0800 (PST) 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=ISJfG8uwjRXmGTuFfInsxWKCRHstlQmbC3dHUOFSOXA=; b=jZncyFyFpVD67RT5J9N+yrBKhJXUSFbg6i79EnbkLtL/RdLoYBNJw+MQNYdvjHDUfM figoG+YGYhCFlhbCQym6VjhOGCS9VRLYzAL/1MmgtJduPbRBVDUv8dR1PH9Q9oC1X88d KDNe020NvnopdeMM8sWOo6JbiEZrOx3iQXcbg= 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=ISJfG8uwjRXmGTuFfInsxWKCRHstlQmbC3dHUOFSOXA=; b=C8/xhY1SJ9WgjSIGOVSDX5ZaSrise4zhEeqJj6UyrDrs1n6cYGoQGOB5kopiuZ54Au ds18XC/d40+3OT2cMImCL3q5m3DEiSTfxN+gpU4N3h0hTljF2ZW/mSai8MnNsqyLCpSV pDqu+2m8rxJuuCC+5Oa499SLq1Rs5viUZXXuhsxQD6a6yXfHmbgxuFkRCswn923uMYDI DwUygjAzThJyAYr5EixpsYGgZjnh5AMU8K+169J2yYa0ljZvmdT0DXMXEFRE0e4328KQ QNnhrhaLsG9Czt6t1Amzd44uwexqS1DynqCYgUkcsGZNmDdwJczvy5tINrCzn2ErC9rN 0MJQ== X-Gm-Message-State: AIkVDXKUXaTTSzrj9MMyiVoxPVCB5S9gl2ZLL2mBwzIjEAlxA7AQ4w9eMC5FvnLMEP0qPw== X-Received: by 10.55.200.195 with SMTP id t64mr64931658qkl.294.1483574218048; Wed, 04 Jan 2017 15:56:58 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id 5sm47053274qts.47.2017.01.04.15.56.56 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Jan 2017 15:56:56 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <0811b400-fc2a-8675-7b74-4b549940de65@cs.tcd.ie> Date: Wed, 4 Jan 2017 18:56:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148353788046.13042.160471261406266.idtracker@ietfa.amsl.com> <20170104200413.1DFD04581178@minas-ithil.hactrn.net> <99955d9c-4771-dd45-f019-313661631e87@cs.tcd.ie> <20170104221557.73CF84581C4F@minas-ithil.hactrn.net> <0811b400-fc2a-8675-7b74-4b549940de65@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Rob Austein , Chris Morrow , sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 23:57:06 -0000 Jumping here > On Jan 4, 2017, at 18:11, Stephen Farrell = wrote: >=20 > Hiya, >=20 > On 04/01/17 22:15, Rob Austein wrote: >> At Wed, 4 Jan 2017 20:57:24 +0000, Stephen Farrell wrote: > (1) 3.1.1: Why MUST a CA ensure that the CA name and > Subject name combination is unique? I don't see what'd > break in BGPsec if that rule is omitted, but maybe I'm > missing something.=20 This might OBE based on the hack/burn of this section, but are you = talking about the last sentence? >>> On 04/01/17 20:04, Rob Austein wrote: >> ... >>>> This draft is a profile of RFC 6487, which is itself a profile of = RFC >>>> 5280. All of the above is pretty much verbatim from RFC 6487. >>>=20 >>> Hmm. I wonder if that's the best plan, especially if there's >>> no interop justification for some of it. >>=20 >> The theory, such as it is, goes: >>=20 >> * RPKI is a tightly constrained profile of X.509v3, with almost >> everything either required or forbidden, to reduce the number of >> grey areas. >>=20 >> * The BGPSEC profile is a minimal set of changes and extensions to = the >> RPKI profile: same overall goal, slightly different constraints. Yep that=E2=80=99s it: constraining the constrained. >>> I note that 6487 says "In the RPKI, the subject name is determined >>> by the issuer, not proposed by the subject" but that seems a bit >>> weird for routers, where I would guess there'll be more diversity in >>> terms of key/CSR generation code. >>=20 >> Well, strictly speaking the subject name is always selected by the >> issuer in X.509, but I know what you mean. >>=20 >> RFC 6487 is weird about this because various parties were extremely >> concerned to avoid anything that could be construed as certification >> of real-world identity, ie, they did not want to find themselves in >> the mainstream PKI business. So RPKI uses meaningless names and has >> the ability to enforce that, hence the text you note in RFC 6487. >=20 > I'd say any concerns that the web PKI CAs might have had ought > now be ameliorated (or OBE, give letsencrypt), so not trodding > on mainstream CA business is probably not as much as concern > as was the case at the start of the RPKI work. >=20 >>=20 >> RFC 6487 6.1.1 does in fact allow the subject to include a subject >> name in the PKCS #10 request, but the text is loaded with weasel >> words. Speaking as someone who has implemented all of this, I find >> the RFC 6487 constraints on subject name in PKCS #10 requests a bit >> excessive, but that's not the document currently under discussion. >=20 > Well, except that this draft does re-iterate some of those now > clearly weird MUSTs. >=20 >>=20 >>> (Correct me if I'm wrong but I'm not sure if it's possible to >>> conform to these requirements with e.g. openssl, or is it?) >>=20 >> The OpenSSL command line tool would probably fight hard against = either >> omitting the subject field from the PKCS #10 request or allowing it = to >> be NULL. The former (field absent) is not even syntactically legal >> X.509. The latter (present but NULL) is legal but kind of unusual: >> RFC 5280 4.1.2.6 allows it in certificates if a critical, non-empty >> subjectAltName extension is present, RFC 2986 is silent on the = subject >> and is only informational in any case. >>=20 >> I'm pretty sure that the OpenSSL library would allow the >> present-but-NULL form, but haven't tested it (recently? ever? don't >> recall...). >>=20 >> In practice, I don't think any of the RKI CA implementations reject >> PKCS #10 requests for having a non-NULL subject, they just ignore it. >>=20 >> All of this is still a problem with RFC 6487, which we should have >> caught five years ago. Oops. Not sure what the best approach is = when >> trying to sub-profile a profile with a known wart like this. The only thing I want to what Rob has mentioned is that this constraint = to use common name and serial number has been around since mid-2011. In = contrast to many other groups I=E2=80=99ve worked with there was no = desire to support everything and the kitchen sink only to find out later = that there were a whole lot of implementation pitfalls to be had with = T61String, BMPString, or how IDNA2008 vs IDNA2003 might affect = comparisons. I remember trying to get people to provide input to tell = me that more was needed, I gave up at some point because all I got in = response was crickets. Now that might have been for a lot of reasons, = but I/we certainly asked. > Fair point. >=20 > So assuming there isn't a chorus of WG participants asking to > remove the weird constraints then I'd say the right thing must > be to not re-iterate any weirdness from 6487 but to only inherit > that by reference. That way, if/when we modify 6487, we won't > have to do the same with this, and maybe also hit problems > with these constraints being enforced by code in two places. >=20 > I think the only such text I saw (that re-iterates 6487) was > in 3.1.1 but there might I guess be more. That text has basically been unchanged since the -01 of the individual = draft circa 2011. I can have a look at 3.1.1 and scrub out what=E2=80=99s= repeated from 6487, but then I=E2=80=99ll get a chorus of =E2=80=9Cbut = there=E2=80=99s no context, I can=E2=80=99t understand it.=E2=80=9D But, = to get through this hurdle, what I think we=E2=80=99re talking about is = deleting the first sentence and everything after =E2=80=9Cnote=E2=80=9D, = i.e.,=20 Common name encoding options that are supported are printableString and UTF8String. For BGPsec Router Certificates, it is RECOMMENDED that the common name attribute contain the literal string "ROUTER-" followed by the 32-bit AS Number [RFC3779] encoded as eight hexadecimal digits and that the serial number attribute contain the 32-bit BGP Identifier [RFC4271] (i.e., the router ID) encoded as eight hexadecimal digits. If there is more than one AS number, the choice of which to include in the common name is at the discretion of the Issuer. If the same certificate is issued to more than one router (hence the private key is shared among these routers), the choice of the router ID used in this name is at the discretion of the Issuer. >>>>> And I'd wonder if router cert revocation will be more common than >>>>> for other resource certs, in which case an OCSP-like system could = be >>>>> needed - did the WG consider that? >>>>=20 >>>> Not as such. Fair question, but the architecture kind of assumes = that >>>> the RPKI RP process is separable from the BGPSEC implementation per >>>> se, BGPSEC just consumes the output of that process. >>>=20 >>> I'd wonder if that means some revocation request protocol will be >>> needed later. But it's fine to not try define that now. >>=20 >> Fair point. >>=20 >>> More to the point is whether or not the WG have thought about the >>> revocation support in the RPKI and whether or not that seems also >>> ok for BGPsec. (I'm unsure myself, but mostly due to the number of >>> moving parts in the RPKI.) >>=20 >> Has been discussed, somewhat noisily. Ask a SIDR WG chair if you = want >> an opinion on WG consensus. My own take is that router keys probably >> get whacked on roughly the same kind of timescale as other RPKI keys, >> so if the revocation mechanism is good enough for everything else, >> it's probably good enough for router keys. YMMV. >=20 > Fair enough. Again, assuming that there's no chorus wanting > change, I'll clear this point as well. Again, definitely no chorus or even drunk carolers :) spt > Cheers, > S. >=20 >>=20 >>>> Most likely implementation technique does all the RPKI stuff per se = on >>>> a separate box and just stuffs the resulting raw keys into the = router >>>> using the rpki-rtr protocol, so the router itself probably would = not >>>> have the information needed to play OCSP even if it wanted to do = so, >>>> which it probably doesn't. =20 >>>=20 >>> So if that's a widely shared view of WG participants then it'd be >>> good to see it described somewhere to help implementers. (It may >>> be in the -overview document which I've yet to read.) >>=20 >> It's sort of in RFC 6810 (rpki-rtr). The update to RFC 6810 is >> stalled because I dropped the ball last year. >>=20 >>>> Requiring the routers to speak OCSP seems >>>> like a potentially dangerous layering violation. >>>=20 >>> Not sure about a layering violation but I can see it'd likely be >>> problematic;-) >>=20 >> I had front-row tickets to the "let's stuff routing policy data into >> the DNS!" show back in the '90s. My main take-away from that mess = was >> a fear of real-time circular dependencies. From nobody Wed Jan 4 16:19:56 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A331294AB; Wed, 4 Jan 2017 16:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 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, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham 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 dkZ2ArKRt40v; Wed, 4 Jan 2017 16:19:49 -0800 (PST) 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 9B61C129470; Wed, 4 Jan 2017 16:19:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C2E28BE2F; Thu, 5 Jan 2017 00:19:47 +0000 (GMT) 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 tSlwBWJlYhX4; Thu, 5 Jan 2017 00:19:46 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D95DDBE2C; Thu, 5 Jan 2017 00:19:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483575586; bh=jCVIcKLL0o0ezWcsl8Tmc3wTmN3IZPezKfHCWC8iXHc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=HvV52YPl0u/VkOA2Zf0nHno7JVhyfN50DyXQTxuX1tp+rO+FffvqiDUXcKSV4Vu+X edjjOWbN3jcwPxoI7PHsiFH93pdGlmaLroUfCJgi3w1DxdPh8/D+gNRlpYJ2DwMm5D QN9e3DVuhzANP4VG6Otrjrvt7SUPfNmeqDaHFAEE= To: Sean Turner References: <148353788046.13042.160471261406266.idtracker@ietfa.amsl.com> <20170104200413.1DFD04581178@minas-ithil.hactrn.net> <99955d9c-4771-dd45-f019-313661631e87@cs.tcd.ie> <20170104221557.73CF84581C4F@minas-ithil.hactrn.net> <0811b400-fc2a-8675-7b74-4b549940de65@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 5 Jan 2017 00:19:45 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020100070200000202070302" Archived-At: Cc: Rob Austein , Chris Morrow , sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 00:19:52 -0000 This is a cryptographically signed message in MIME format. --------------ms020100070200000202070302 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Yep, I guess the text below is good enough. Thanks, S. On 04/01/17 23:56, Sean Turner wrote: > Common name encoding options that are supported are > printableString and UTF8String. For BGPsec Router Certificates, it > is RECOMMENDED that the common name attribute contain the literal > string "ROUTER-" followed by the 32-bit AS Number [RFC3779] encoded > as eight hexadecimal digits and that the serial number attribute > contain the 32-bit BGP Identifier [RFC4271] (i.e., the router ID) > encoded as eight hexadecimal digits. If there is more than one AS > number, the choice of which to include in the common name is at the > discretion of the Issuer. If the same certificate is issued to more > than one router (hence the private key is shared among these > routers), the choice of the router ID used in this name is at the > discretion of the Issuer. --------------ms020100070200000202070302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDUw MDE5NDVaMC8GCSqGSIb3DQEJBDEiBCAHH4mON93os9u1uz6VzDPLuYqEOLm3pOsrG3J0wBbG NDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQB06G2ItlwJOu53X7hYMgq6TVNVnhzJj5TzfwrMv6Zoe6s7yg7R1tG3 SWmG+yA2RANJmt7sT9vUMQyvZSA3G5GDj8ujC8BGXmitWchTJOe0SElQVUWohRg5SfOzgiHR 2R5gdi1CyansA6uR7Y/BTrdTRfBWnjeI8argEA98xOYijbhLfIlW8Fs9CQfBJ7jCMWhmi7XQ u7UP/dOymFlnJxS3HzLkR7pVnOSPE86+K2M9pM5GXYozRHSiDbqzL+g/VeSm8KTwaq1wBSiZ UKI8Xvg4O3ZHtiHpfV2F7jCYwLapYCfpWYjchgOprhREyRSB46Yu0mB7fMOgWf+JS8MysOkd AAAAAAAA --------------ms020100070200000202070302-- From nobody Wed Jan 4 16:21:26 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E5312947A; Wed, 4 Jan 2017 16:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 ZaYUFb40D0Qa; Wed, 4 Jan 2017 16:21:24 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 27B33129449; Wed, 4 Jan 2017 16:21:24 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cOvo2-0005G9-6w; Thu, 05 Jan 2017 00:21:22 +0000 Date: Thu, 05 Jan 2017 09:21:19 +0900 Message-ID: From: Randy Bush To: Spencer Dawkins In-Reply-To: <148355705100.13011.5709768999664450618.idtracker@ietfa.amsl.com> References: <148355705100.13011.5709768999664450618.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: The IESG , sidr wg list Subject: Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 00:21:25 -0000 you are at the intersection (well actially union) of two twisty sets of passages, bgp routing and internet ops. > I'm wondering if "the transitive closure of a client's customers" has > a precise meaning. I know what a customer is, at the hand-waving > level the academic, overly-idealized, definitions of customer/provider/peer are in https://www.cs.princeton.edu/~jrex/papers/sigmetrics00.long.pdf, aka gao-rexford; though this has been shown to apply to the real internet far less strictly than many researchers have stubbornly assumed; see http://conferences2.sigcomm.org/imc/2015/papers/p71.pdf at the network ops level, a 'customer' is an ebgp-speaking AS to which you give routes learned from o other custimers o your peers o your upstreams/transits o your internals of course, by business arrangement, this might be restricted. this may be contrasted with peers and upstreams/transits, to whom you give only customer and internal routes. > Is "customer" being used a shorthand for another term that isn't > depending on an economic transaction? exactly > (If this was "the transitive closure of a client's clients", for > instance, I would know what that meant a route reflector's "clients" are ibgp speakers (stress is on the 'i') within the RR's AS. a (possibly improper) subset of those clients may be "customer aggregation" routers, i.e. connect via ebgp to ASs of external entities (aka customers). iff one or more of those RR clients (or their clients, cf 'transitive closure') speak bgpsec to a customer is the RR required to do bgpsec. if all the customers (which could be the null set) of of the RR's clients speak only bgp classic, there is no requirement that the RR speak bgpsec. randy From nobody Wed Jan 4 16:34:55 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752E8129477 for ; Wed, 4 Jan 2017 16:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 HykRFuxPeMXT for ; Wed, 4 Jan 2017 16:34:53 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 CF62D12947A for ; Wed, 4 Jan 2017 16:34:52 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id n21so418184563qka.3 for ; Wed, 04 Jan 2017 16:34:52 -0800 (PST) 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=jRR1SPIRzQv5JnwlDQ7Io3PaXOPfcMgEalTl33r9a50=; b=C3jnXsZXGHOf9TTP8nELQq21d7AyBAVTeIbRehDsRkPEtEs0dvT9MO1mYQyyYOJFPs ewdqUIUUrIzdib1d9aBDXGrbxsPl2p8hbfQ57QkIo7PLJgF6la5K2AXDmd+E8u8m4LtR 4cFbDPvdYsGCMogppUrDzs1jOS5alVzWVa6hg= 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=jRR1SPIRzQv5JnwlDQ7Io3PaXOPfcMgEalTl33r9a50=; b=YR4W4fYxhzhoRRR0pP/s0EkBQqP681rSF4HGSeBghm47uA9PXslMqjoRdGJY+el/81 JWeR9e377WQBpMIknh68NT5Dsyhe9SCQM0aovTBfXoOOECVOzf276Fi8rKY2S72du4/c Jm9ZvvYeywG2cY4GK0O1O1tVAgwySzr/IQ0edOMMjSPJdiPfTXnxdEFlzBiS1rLDJJYI eoedhXLLj6TfrdwVAJF4RUeXpLVLf5vFSoLSl80v+u2pegb1rpneqJKu96iiUq5fmYQc L5xbwwQwzmzyBQtHVOHblJFxqJmWg+ihMk6U9WzkWVYh4Q0zv4H4LwfWUobMz32c712h /aSw== X-Gm-Message-State: AIkVDXL0+x7X0ThD8G3xDQrWKCVvHxSUqz1a4KiDLMT642/TfDmCkENnn0ZfnCKrKsABdA== X-Received: by 10.55.92.195 with SMTP id q186mr37524979qkb.83.1483576491912; Wed, 04 Jan 2017 16:34:51 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id i41sm47199030qtc.18.2017.01.04.16.34.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Jan 2017 16:34:50 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <148353788046.13042.160471261406266.idtracker@ietfa.amsl.com> Date: Wed, 4 Jan 2017 19:34:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148353788046.13042.160471261406266.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 00:34:54 -0000 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - section 2: I think this is a bit badly written: "The use > of BGPsec Router Certificates in no way affects RPKI RPs > that process Manifests and ROAs because the public key > found in the BGPsec Router Certificate is used only to > verify the signature on the BGPsec certificate request > (only CAs process these) and the signature on a BGPsec > Update Message [ID.sidr-bgpsec-protocol] (only BGPsec > routers process these)." Do you mean that there's no way > that an entity can confuse a Manifest, ROA, CSR or BGPsec > update so there's no issue with which public keys are used > to verify the signatures on those data structures? Gahhhh =E2=80=A6 so that=E2=80=99s a little tortured; it=E2=80=99s a = continuation of the whole =E2=80=9Cthese certs don=E2=80=99t really = affect the rest of the RPKI". How about: BGPsec Router Certificates are used only to verify the signature on the = BGPsec certificate request (only CAs process these) and the signature on = a BGPsec Update Message [ID.sidr-bgpsec-protocol] (only BGPsec routers = process these); BGPsec Router Certificates are not used to process = Manifests and ROAs or verify signatures on Certificates or CRLs. > - section 3: As noted in my comments on the BGPsec > protocol, it'd be better to call out the SKI here if you > don't add the direct ref to 6487 to the BGPsec protocol > draft. Wait, I thought I wasn=E2=80=99t supposed to duplicate any of the crazy = stuff from 6487 :) spt From nobody Wed Jan 4 16:39:37 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A8B12947A; Wed, 4 Jan 2017 16:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 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, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham 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 nkNUikER0Fcx; Wed, 4 Jan 2017 16:39:30 -0800 (PST) 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 BE35612946D; Wed, 4 Jan 2017 16:39:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 39135BE32; Thu, 5 Jan 2017 00:39:28 +0000 (GMT) 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 kJxRnwEm1y7K; Thu, 5 Jan 2017 00:39:26 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 28C24BE2F; Thu, 5 Jan 2017 00:39:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483576766; bh=RibU54lH/CDLgN+2F5AhsPo/vfXeBFuBxFe+RQDNiak=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=3Mt/f2C/OXNEZ3ldeS593Di+wLYTZMtIU0i3df0u4+nmrTFYFE2GbBjyv6cFOSBno bZ+Himad7BNFjUUMf9BFMs4rhaVab2hE2fGprW48rhlkTbPmZhj4hjQVQ3lGKQOe52 FdMtQbpetAiA064LeGqX2E4e/Js4j9Rm1MMnwrc8= To: Sean Turner References: <148353788046.13042.160471261406266.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 5 Jan 2017 00:39:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010806050602040900090506" Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 00:39:33 -0000 This is a cryptographically signed message in MIME format. --------------ms010806050602040900090506 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 05/01/17 00:34, Sean Turner wrote: >> ----------------------------------------------------------------------= >> >>=20 COMMENT: >> ----------------------------------------------------------------------= >> >> >> >>=20 - section 2: I think this is a bit badly written: "The use >> of BGPsec Router Certificates in no way affects RPKI RPs that >> process Manifests and ROAs because the public key found in the >> BGPsec Router Certificate is used only to verify the signature on >> the BGPsec certificate request (only CAs process these) and the >> signature on a BGPsec Update Message [ID.sidr-bgpsec-protocol] >> (only BGPsec routers process these)." Do you mean that there's no >> way that an entity can confuse a Manifest, ROA, CSR or BGPsec=20 >> update so there's no issue with which public keys are used to >> verify the signatures on those data structures? >=20 > Gahhhh =E2=80=A6 so that=E2=80=99s a little tortured; it=E2=80=99s a co= ntinuation of the > whole =E2=80=9Cthese certs don=E2=80=99t really affect the rest of the = RPKI". How > about: >=20 > BGPsec Router Certificates are used only to verify the signature on > the BGPsec certificate request (only CAs process these) and the > signature on a BGPsec Update Message [ID.sidr-bgpsec-protocol] (only > BGPsec routers process these); BGPsec Router Certificates are not > used to process Manifests and ROAs or verify signatures on > Certificates or CRLs. Yep, better. >=20 >> - section 3: As noted in my comments on the BGPsec protocol, it'd >> be better to call out the SKI here if you don't add the direct ref >> to 6487 to the BGPsec protocol draft. >=20 > Wait, I thought I wasn=E2=80=99t supposed to duplicate any of the crazy= stuff > from 6487 :) Well, this is describing a different PDU though:-) But yeah, better if the protocol spec points direct to 6487 direct. Cheers, S. >=20 > spt >=20 --------------ms010806050602040900090506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDUw MDM5MjVaMC8GCSqGSIb3DQEJBDEiBCB6RGDWzNZCiEfJCGq457D8PWBTTKpchfWNXkWV6W1j tTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCKFxl9+/NOkOS/0KPPZ6WHF/1FRaDsYghE9AxfMS/HC7Am01t17VHb 9c1z/EZnyma+Cy+34FQFx7H6WYr0Tx4L9uBM20BHgRw+ME++mnXmNS3Aw0fq0gm7OgSJR3Uj iSb4MLsgY6K79e6hTWX7LRib3ZUNAzAt+1BHe5kExqs72wmY3ialNFIty+mhz4131GA9V6JG ZdEhOK4JiFHPc6vCb40lNHbPlsXPWwNVn3UT9lQMqUDYrLXNEVlIHgXBR4IxZXWlrEqX3QCq lV2aT1nSo1Wo5Z++FVL+4lyQI09EP+GQLbUlo9rTbRVA/MomIUCjw4YTIKCKj9Vs+QToWk+Y AAAAAAAA --------------ms010806050602040900090506-- From nobody Wed Jan 4 16:40:28 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AB21294AC for ; Wed, 4 Jan 2017 16:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, 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 rHW0sMPTwz6Z for ; Wed, 4 Jan 2017 16:40:21 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 0C2AD1294AB for ; Wed, 4 Jan 2017 16:40:21 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id n21so418280422qka.3 for ; Wed, 04 Jan 2017 16:40:20 -0800 (PST) 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=ugN4C/nBjE+3mk43EXOb363nx/sYjIyhN5kRJDCzTjw=; b=Q/C/h8ZlJoSule9oS5Eb0QoaBGMUL3bRnMcA/ateQ6htIHNUEJBa5qM+rvWaHQDU3M 1H5VFFWohgS1uQVrvb1/8JSde5yW1OeRztKPYR5W+1ClJwfcfVEU1w2UfguB6S8VIcM6 XaN75uCgivIdPvUNkL5gAQnLvPX72ETYjVDzs= 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=ugN4C/nBjE+3mk43EXOb363nx/sYjIyhN5kRJDCzTjw=; b=kbFmAZ5Vk5kRIcUa6HKpV12VBE9VPDSaRnBfgLYuoEpnKfMYeb6NLIJhN6jooFchl3 /caQHfghh8GLl2yc+5sF9lTS39aXGjx7ElV9XAWuOJl/w1UP/NW7YpCesmEpxoLwScwD einDgQbRWzFzVqBSiolQlRBqUxgOVfEgOJtvbP0SHr9o6QpyAgh7Q/GGfNfcRi2DG92f DhnnKMdh6OOphG2l+unKbFNQMlp1qGSrzpOaU5zyP9LCQ9+p2sV6ZhFQr4P9h5AbXask dGLXcck2OSLnrZj0khuVkw4KPgBT4QbHBGQUm36bCXBAD6rupRBACgd+U2brz2RqHbEz j9Qw== X-Gm-Message-State: AIkVDXIfrfhWQQrUo+qBwyjgqI5+9odt9HtD5gevmXlM9xDi3m15Fh3XWnhfPKyAZD3TTA== X-Received: by 10.55.26.159 with SMTP id l31mr68481184qkh.164.1483576820254; Wed, 04 Jan 2017 16:40:20 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id j204sm2313792qke.36.2017.01.04.16.40.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Jan 2017 16:40:19 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Wed, 4 Jan 2017 19:40:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148353788046.13042.160471261406266.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 00:40:23 -0000 > On Jan 4, 2017, at 19:39, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > On 05/01/17 00:34, Sean Turner wrote: >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 > COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 >>>=20 >>>=20 > - section 2: I think this is a bit badly written: "The use >>> of BGPsec Router Certificates in no way affects RPKI RPs that >>> process Manifests and ROAs because the public key found in the >>> BGPsec Router Certificate is used only to verify the signature on >>> the BGPsec certificate request (only CAs process these) and the >>> signature on a BGPsec Update Message [ID.sidr-bgpsec-protocol] >>> (only BGPsec routers process these)." Do you mean that there's no >>> way that an entity can confuse a Manifest, ROA, CSR or BGPsec=20 >>> update so there's no issue with which public keys are used to >>> verify the signatures on those data structures? >>=20 >> Gahhhh =E2=80=A6 so that=E2=80=99s a little tortured; it=E2=80=99s a = continuation of the >> whole =E2=80=9Cthese certs don=E2=80=99t really affect the rest of = the RPKI". How >> about: >>=20 >> BGPsec Router Certificates are used only to verify the signature on >> the BGPsec certificate request (only CAs process these) and the >> signature on a BGPsec Update Message [ID.sidr-bgpsec-protocol] (only >> BGPsec routers process these); BGPsec Router Certificates are not >> used to process Manifests and ROAs or verify signatures on >> Certificates or CRLs. >=20 > Yep, better. Incorporated in my editor=E2=80=99s copy. spt= From nobody Wed Jan 4 16:40:46 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AA612946D for ; Wed, 4 Jan 2017 16:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, 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 yx3jwLOKnogw for ; Wed, 4 Jan 2017 16:40:40 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 F165912947A for ; Wed, 4 Jan 2017 16:40:37 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id c47so506295219qtc.2 for ; Wed, 04 Jan 2017 16:40:37 -0800 (PST) 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=SUQpKi6YtsaRImZP1GQoiDyeQ9gRbyMiCRP7quZZwQU=; b=Z1uS3qfvjuhLuRN7FrLohBwCzbyECaLKaRnx4C/fgUdb9Y6ysrJ43/H77VzE1SC1vl PFPgLjpgKBvdDMbOSwMH3YX/tFTtpfT1ja8xye47xbgkKRPRgqEuzUm0n98yHO+3gBFW R2j1vbTlfyJe5l/sD2N2u/1QWgj8NTmI9+wPI= 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=SUQpKi6YtsaRImZP1GQoiDyeQ9gRbyMiCRP7quZZwQU=; b=nWwBz6RewdTObeOmuDmyrKPy8qEJcsUXyP8LhuojP27/AitxGUE/ssR8hII6eas86g rlgoUr4Bo7hme9ikv2e2hQBgD4FovWTCtgHuV035R7Gr2ynz9mYc4aejH5HxliMzqbWG fDe0Q1iccm1x5Fs+mRaNiishH33FkbjcshJd9SM2pJQAvGuqKumeP/43yzG5jLsN45Rj UDAZszKXyiyRCfrkqlyNtud3ZL0j6/P5NJ4RduCwVGs66wpDxvz1cEcnMyBiEFp0+AQ7 WlpUo/odTlFZdnqISR87maY19gcvdOWWmK08MJr594ga3kdcZHZPBcO0Gnc9GfUlkbR+ 1Yjg== X-Gm-Message-State: AIkVDXLX3pYKq2C9uEQHCH9wBZM2MZlaKpPBrYlo7KkJ+4sKkp/CGx1p3VwQlQWwTNp+Rw== X-Received: by 10.237.32.70 with SMTP id 64mr62407792qta.163.1483576837111; Wed, 04 Jan 2017 16:40:37 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id j204sm2313792qke.36.2017.01.04.16.40.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Jan 2017 16:40:35 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Wed, 4 Jan 2017 19:40:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2E7D8CAE-4C41-40AA-86E1-3E63B6F0F064@sn3rd.com> References: <148353788046.13042.160471261406266.idtracker@ietfa.amsl.com> <20170104200413.1DFD04581178@minas-ithil.hactrn.net> <99955d9c-4771-dd45-f019-313661631e87@cs.tcd.ie> <20170104221557.73CF84581C4F@minas-ithil.hactrn.net> <0811b400-fc2a-8675-7b74-4b549940de65@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Rob Austein , Chris Morrow , sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 00:40:41 -0000 In my editor=E2=80=99s copy. spt > On Jan 4, 2017, at 19:19, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > Yep, I guess the text below is good enough. >=20 > Thanks, > S. >=20 > On 04/01/17 23:56, Sean Turner wrote: >> Common name encoding options that are supported are >> printableString and UTF8String. For BGPsec Router Certificates, it >> is RECOMMENDED that the common name attribute contain the literal >> string "ROUTER-" followed by the 32-bit AS Number [RFC3779] encoded >> as eight hexadecimal digits and that the serial number attribute >> contain the 32-bit BGP Identifier [RFC4271] (i.e., the router ID) >> encoded as eight hexadecimal digits. If there is more than one AS >> number, the choice of which to include in the common name is at the >> discretion of the Issuer. If the same certificate is issued to more >> than one router (hence the private key is shared among these >> routers), the choice of the router ID used in this name is at the >> discretion of the Issuer. >=20 From nobody Wed Jan 4 16:52:08 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81721294AC for ; Wed, 4 Jan 2017 16:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 2kQPoM5SyITK for ; Wed, 4 Jan 2017 16:52:05 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 32F461294B0 for ; Wed, 4 Jan 2017 16:52:05 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id n21so418483312qka.3 for ; Wed, 04 Jan 2017 16:52:05 -0800 (PST) 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=3KWTKhi6ZWFqcVA+qbp12Y/8xx04rTjfHgWaXDKcnIo=; b=OJ0JSQ9GLFiPD+Xtf0MMxhk6qxw4h2TMOn87Pg1HpAj4mjlDVoRWX+NyH6KxJvETBa I+BtyVF7R/8LkUAQ3P4HgHoiOcJCoR4AyeVXzgQl7WYg1puTgFq6q6ZNMAdyKS6p8gqi 69owZBbDy7YWaauQJOVLdFHVbDO2WrBliXAX4= 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=3KWTKhi6ZWFqcVA+qbp12Y/8xx04rTjfHgWaXDKcnIo=; b=c0ibjdWul4tdjZ6x8YUaZl0NJ4udqsrIyZ80nL5Q7yJAsj9fharpyeTTEgNZx/Verk X8baKGSTKhzUujj7pGGio8txuk4XBZorMMUXSiTetUmpK/0/InLfZrImzWME7AIlUfoD 9Tg0eHwjodKCuc6b5FXtjNoqf6v7srn0LbjI647s5Lc/As/rcuYkTYy9nzvf0pe+iEDS HpzTbB/3X/iDiVi0Wug5zyWmgy8pV2LmWE//2np7muSFi58yOZTjGrs63Ix+M/B2WrNM UFT4EaZOA3UkuaVIVzY4XllADDZ8IrB03kZojXg0Lxyk9/boz4OYSr8vubaMSkdibqIL mC2g== X-Gm-Message-State: AIkVDXL8A187CMezVoAJ2VkcQ2deMr9jVOpvec4lGJbUSUGyGgAnmQ/mCbYsHuQkJozt8A== X-Received: by 10.55.125.194 with SMTP id y185mr67229649qkc.38.1483577524324; Wed, 04 Jan 2017 16:52:04 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id 53sm47101653qtm.5.2017.01.04.16.52.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Jan 2017 16:52:03 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Wed, 4 Jan 2017 19:52:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148328799488.25220.17994465220699555250.idtracker@ietfa.amsl.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sidr@ietf.org, draft-ietf-sidr-bgpsec-pki-profiles.all@ietf.org, secdir@ietf.org Subject: Re: [sidr] Review of draft-ietf-sidr-bgpsec-pki-profiles-19 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 00:52:06 -0000 > On Jan 3, 2017, at 16:47, Yaron Sheffer wrote: >=20 > Hi Sean, >=20 > Please see below. >=20 > On 03/01/17 18:12, Sean Turner wrote: >> Yaron, >>=20 >> Thanks for the review. >>=20 >>=20 >>> On Jan 1, 2017, at 11:26, Yaron Sheffer >>> wrote: >>>=20 >>> Reviewer: Yaron Sheffer >>> Review result: Has Nits >>>=20 >>> * 3.1.1: The serial number in RFC 6487 is still a real, unique = serial >>> number that uniquely identifies the certificate. Here it is used as >>> something other than a serial number, which is explicitly NOT = unique, >>> and the CA is left to decide how to make it unique in the face of >>> potentially repeating BGP IDs. If this is not a real issue (e.g. >>> because duplicate IDs are rare and never within a RIR), please say >>> so. >>>=20 >> As Rob pointed out this paragraph is talking about the serial number = naming attribute. Maybe something like: >>=20 >> r/only two attributes/only two naming attributes >> and >> r/common name and serial number/common name (i.e., X520CommonName) = and serial number (i.e., X520SerialNumber)=20 >>=20 >> People ought to them be able to track down the definitions. >>=20 > I'm good with these changes. However, according to Randy's response to = my review, the text later on is subtly incorrect (or at least = misleading). Router IDs are not globally unique, but the combination of = AS Number and Router ID is in fact globally unique. This bit is now OBE based on Stephen=92s discuss. >>> * 3.2: earlier we said that Basic Constraints must not be included = in >>> the EE cert. Now we are saying that only a particular boolean flag >>> must not be honored when processing the Cert Request. What happens = if >>> Basic Constraints is included in the Cert Request but with other >>> flags? >>>=20 >> The CA is ultimately the one who decides what gets issued. A good CA = would know to only issue properly formatted BGPsec certificates either = by ignoring the improperly requested =93feature" or rejecting it = outright. Since these CAs really aren=92t open CAs then the CA ought = not get caught off-guard with requests. > I'm not sure I understand. Why not give a consistent advice to EEs and = CAs, e.g., reject any request that includes any Basic Constraints. So there=92s really no good way to put this but it=92s primarily because = the common PKCS#10/PKCS#7 dance doesn=92t support errors; it=92s either = success or silence. It=92s better to assume they=92ve dorked their = request and to give =91em a proper certificate. Remember these CAs are = pretty clued into what=92s going on here this isn=92t the webPKI. >>> * 3.3: ID.sidr-rfc6485bis -> RFC 7935 >>>=20 >> drat I missed one. >>=20 >>=20 >>> * 6: in the paragraph that discusses hash functions, please spell = out >>> the names of the two key identifiers, because I cannot determine = what >>> they are from the document. >>>=20 >> Ack they=92re the key identifiers in the cert: Subject Key Identifier = and Issuer Key Identifier=20 >>=20 >> r/two key identifier extensions./two key identifier extensions (i.e., = Subject Key Identifier and Issuer Key Identifier) >>=20 > Yes. >>=20 >> spt >>=20 >=20 From nobody Wed Jan 4 16:58:39 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9BB1270B4; Wed, 4 Jan 2017 16:58:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148357791404.12990.5226692464513021947.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 16:58:34 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-20.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 00:58:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests Authors : Mark Reynolds Sean Turner Stephen Kent Filename : draft-ietf-sidr-bgpsec-pki-profiles-20.txt Pages : 12 Date : 2017-01-04 Abstract: This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in the Internet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end-entity (EE) certificates specified by this profile are issued to routers within an Autonomous System. Each of these certificates is issued under a Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Identifier Delegation extension. An EE certificate of this type asserts that the router(s) holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests, and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends the RPKI; therefore, this documents updates the RPKI Resource Certificates Profile (RFC 6487). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 4 17:03:51 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8287D1294B9 for ; Wed, 4 Jan 2017 17:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 t1N4l63qfddg for ; Wed, 4 Jan 2017 17:03:48 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 267E01294B3 for ; Wed, 4 Jan 2017 17:03:48 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id k15so267895691qtg.3 for ; Wed, 04 Jan 2017 17:03:48 -0800 (PST) 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=SIIjG1A7UvSNIusPLJqBilyA5e4Tym9oD7FEssJxJYI=; b=AEsTLtjOwoSi7oM4rjdUgg0aM3Bcn1PCoJarkYHvseWjzHIUj1yq8RRScgCGEE4B4I B8Xf1yuJKfMspEpNNyzE0p/Sse6t2SAwZqPmonYjES5tgrJ/GkY5Z5PL5w+I0VAa49R9 7JZiFeLzLdcQudyZX+CE4ANIwyfni2YSPh2zI= 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=SIIjG1A7UvSNIusPLJqBilyA5e4Tym9oD7FEssJxJYI=; b=sXYiGV+qI4Woc8NTBwEztGHV8kTgNeslndHOvLkTmQu1/Qtw6/ABXT1PAGc0BLN2sW uUs1rULSjblHx0/Qgh4Ykt6q4Tn4gUJCOUOhXyt+wA28sKyZxl6u11ZQhMJqOBbS8PDo ZQ0lvwXddxT+QMLFXjqZvHmVvLQxNUeW1dnalbmaEwO9u9EyI50RVpc8XDp1CGStCqfu 3k228Wi9lEHNTKJTzUTmoUc+cilLe+ECu+8WA8/2+RmBoMsfivWZc3UxahJEYk7Eg4k6 CJKBzYbENH/q9yILEN0bvi06yvJLLuYkizXIu9cqMmgk9sg88Vw2ync+xQdc/+nVowgD bwmA== X-Gm-Message-State: AIkVDXI/YkJmQ8wa2MRyIea+mBkZ05eqHxJpySAz8W0VuUQeo3pTtOwCpXd51aque9g/Vw== X-Received: by 10.237.57.137 with SMTP id m9mr68743754qte.35.1483578227251; Wed, 04 Jan 2017 17:03:47 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id q53sm47163139qtq.0.2017.01.04.17.03.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Jan 2017 17:03:46 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <148357791404.12990.5226692464513021947.idtracker@ietfa.amsl.com> Date: Wed, 4 Jan 2017 20:03:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4DBE0920-F544-4646-92BC-44CCC2570968@sn3rd.com> References: <148357791404.12990.5226692464513021947.idtracker@ietfa.amsl.com> To: The IESG X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-20.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 01:03:49 -0000 I believe this version addresses Stephen=E2=80=99s discuss points as = well as the other comments I=E2=80=99ve picked up along the way (minus = fighting with nroffedit to add references). spt > On Jan 4, 2017, at 19:58, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing of the = IETF. >=20 > Title : A Profile for BGPsec Router Certificates, = Certificate Revocation Lists, and Certification Requests > Authors : Mark Reynolds > Sean Turner > Stephen Kent > Filename : draft-ietf-sidr-bgpsec-pki-profiles-20.txt > Pages : 12 > Date : 2017-01-04 >=20 > Abstract: > This document defines a standard profile for X.509 certificates used > to enable validation of Autonomous System (AS) paths in the Border > Gateway Protocol (BGP), as part of an extension to that protocol > known as BGPsec. BGP is the standard for inter-domain routing in = the > Internet; it is the "glue" that holds the Internet together. BGPsec > is being developed as one component of a solution that addresses the > requirement to provide security for BGP. The goal of BGPsec is to > provide full AS path validation based on the use of strong > cryptographic primitives. The end-entity (EE) certificates = specified > by this profile are issued to routers within an Autonomous System. > Each of these certificates is issued under a Resource Public Key > Infrastructure (RPKI) Certification Authority (CA) certificate. > These CA certificates and EE certificates both contain the AS > Identifier Delegation extension. An EE certificate of this type > asserts that the router(s) holding the corresponding private key are > authorized to emit secure route advertisements on behalf of the > AS(es) specified in the certificate. This document also profiles = the > format of certification requests, and specifies Relying Party (RP) > certificate path validation procedures for these EE certificates. > This document extends the RPKI; therefore, this documents updates = the > RPKI Resource Certificates Profile (RFC 6487). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-20 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-pki-profiles-20= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Jan 4 17:11:16 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 838051270B4; Wed, 4 Jan 2017 17:11:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148357867253.12977.5831630075676973535.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 17:11:12 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org Subject: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-bgpsec-pki-profiles-20: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 01:11:12 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-sidr-bgpsec-pki-profiles-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss points. OLD COMMENTS below, I didn't edit 'em... - section 2: I think this is a bit badly written: "The use of BGPsec Router Certificates in no way affects RPKI RPs that process Manifests and ROAs because the public key found in the BGPsec Router Certificate is used only to verify the signature on the BGPsec certificate request (only CAs process these) and the signature on a BGPsec Update Message [ID.sidr-bgpsec-protocol] (only BGPsec routers process these)." Do you mean that there's no way that an entity can confuse a Manifest, ROA, CSR or BGPsec update so there's no issue with which public keys are used to verify the signatures on those data structures? - section 3: As noted in my comments on the BGPsec protocol, it'd be better to call out the SKI here if you don't add the direct ref to 6487 to the BGPsec protocol draft. From nobody Wed Jan 4 17:29:39 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E331294C9; Wed, 4 Jan 2017 17:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 NgGGRm_8c-ng; Wed, 4 Jan 2017 17:29:34 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 C96321294C8; Wed, 4 Jan 2017 17:29:34 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cOws0-0005cy-VR; Thu, 05 Jan 2017 01:29:33 +0000 Date: Thu, 05 Jan 2017 10:29:31 +0900 Message-ID: From: Randy Bush To: "Ben Campbell" In-Reply-To: <661F8C18-7B04-4E88-A97A-BBA8314C3FD4@nostrum.com> References: <148348795694.28027.8646303758093237302.idtracker@ietfa.amsl.com> <661F8C18-7B04-4E88-A97A-BBA8314C3FD4@nostrum.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: The IESG , sidr wg list Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 01:29:36 -0000 >>> -4, first paragraph: I found "either" followed by "and/or" a bit >>> confusing. I suggest simply dropping the word "either". >> >> As described in [I-D.ietf-sidr-rtr-keying] BGPsec-speaking routers >> are either capable of generating their own public/private >> key-pairs and having their certificates signed and published in >> the RPKI by the RPKI CA system, and/or are given public/private >> key-pairs by the operator. >> >> but the router(s) might not be capable of generating key-pairs. they >> might, they might not, the op may generate or not, or both. an >> absurd corner case might be that a router with two ASs has the as0 >> key stuffed by the as0 noc, and the as1 key is generated on device >> because that is the as1 policy. > > I merely meant that "either" seemed odd for non-exclusive options. I > take your argument to mean that the options really are non-exclusive. ok, i will drop the either. >>> -4, last paragraph: "a prudent operator will..." sounds like it >>> might be worthy of a SHOULD. >> >> given the previous, how about lower case should > > That would not seem to change anything :-) My point was that the > language seemed stated in a way that _might_ justify a 2119 > keyword. ok, upcased SHOULD >>> -7, paragraph 6: This seems to say that signed paths MUST be >>> signed. Does the "MUST be signed if sent to external BGP speakers" >>> mean that the existing signature must not be stripped (as stated >>> more weakly in the previous sentence), or does it mean the sender >>> must re-sign the path? >> >> Because of possible RPKI version skew, an AS Path which does not >> validate at router R0 might validate at R1. Therefore, signed >> paths that are Not Valid and yet propagated (because they are >> chosen as best path) should have their signatures left intact and >> MUST be signed if sent to external BGPsec speakers. >> >> i am not seeing where bgpsec stripping was suggested; in fact, the >> opposite. if router r0 receives a signed path and intends to pass >> that signed path to the next listener, r0 must sign the path. i am >> at a loss to understand your question. clue bat please. > > Sorry, I did not mean that stripping was suggested; the previous > phrase (non-normatively) recommends against stripping. My question is, > since the subject of the sentence is "signed paths" whether the "MUST > be signed" language means "MUST NOT strip the signature" (which I > suspect to be the case), or something else. how about As the mildly stochastic timing of RPKI propagation may cause version skew across routers, an AS Path which does not validate at router R0 might validate at R1. Therefore, signed paths that are Not Valid and yet propagated (because they are chosen as best path) MUST NOT have signatures stripped and MUST be signed if sent to external BGPsec speakers. if not, use larger clue bat > As I mentioned in response to Alvaro's comment: Maybe section 2 should > cite the protocol rather than the overview? done randy From nobody Wed Jan 4 18:53:42 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD6F129864; Wed, 4 Jan 2017 18:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 64t9X5ndu6RJ; Wed, 4 Jan 2017 18:53:35 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 B924D129513; Wed, 4 Jan 2017 18:53:35 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id t125so331464948ywc.1; Wed, 04 Jan 2017 18:53:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=45DJNKetxloGT6VNEWjrOpROdQvwUNJJUqH0XVIYGeQ=; b=u7KbwpJUH7wdlPg6p7SrmMDg3VUZGoavt0SoZwLSbFUjA/KKMizKKYGvQAWW0+nejp E201oRg6GWiTo6GiUhVTy+MIDnioGDTUVNsAqwW7NbgI3QP3+Sc6xgcQwnprWHE6p4tz 0NbuUOTO6JkTpGdPww2xUAeVLTwfJVi++UYp7CW6+khlm4eI5UMbf82Abj5ndeM8ysmO RRqKcuXZs1NJFbzRzKLjVFZwiHnZqrB+lfm0pNxPAp3OPNyeVdBGKxE7CxcHi623KKaA 8PcqN6Xf8WuxuxPxh2coPKtjOwgBmOl+bXH4D6iEbCCluC7epFYN+dtQStdo4Ya1wNXd GFhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=45DJNKetxloGT6VNEWjrOpROdQvwUNJJUqH0XVIYGeQ=; b=f6F6oIL84h7+xVBemSljpgz6YHTS6XFJyOLxYh1QUZtHMeFrN3OlFLVuVkF+7WwC3X dnGvJpIutWYgbqiD6ZjTAM8z/xfKIH+GU0cOz26zjdSKVVzG2V3/VJEpatP3TO5MnsAw mNBIC2hUUspIhnzA71u2pc8Ln1NV/sI91CC9xYzgm3DesiNVuSHr2HPM6Ljn8LYMLrmg iHrkyb7beX5APgw0FNo+do1uXs+iDkJ66WRTrm3SVXIvXC9g64nxst5IMnrZHVfKunon znNiBbTLIWROkPjLEdS7wEdWIGwQA8ST5CHgLZSZtY6ZsfeA142p7iSOqAyWJmo6CLfW Ujqw== X-Gm-Message-State: AIkVDXJcGQTzGBg6z8z+YXTu966Y1957AgB0ImQzg5CHiXtQmlM05eVY+GM6jyw/V3KQwAtwwBLAd5+p3SogKQ== X-Received: by 10.13.197.68 with SMTP id h65mr66838993ywd.84.1483584815070; Wed, 04 Jan 2017 18:53:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.221.195 with HTTP; Wed, 4 Jan 2017 18:53:34 -0800 (PST) Received: by 10.37.221.195 with HTTP; Wed, 4 Jan 2017 18:53:34 -0800 (PST) In-Reply-To: References: <148355705100.13011.5709768999664450618.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Wed, 4 Jan 2017 20:53:34 -0600 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a114ea2f4e58c480545500149 Archived-At: Cc: iesg@ietf.org, sidr wg list Subject: Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 02:53:37 -0000 --001a114ea2f4e58c480545500149 Content-Type: text/plain; charset=UTF-8 Hi, Randy, On Jan 4, 2017 18:21, "Randy Bush" wrote: you are at the intersection (well actially union) of two twisty sets of passages, bgp routing and internet ops. > I'm wondering if "the transitive closure of a client's customers" has > a precise meaning. I know what a customer is, at the hand-waving > level the academic, overly-idealized, definitions of customer/provider/peer are in https://www.cs.princeton.edu/~jrex/papers/sigmetrics00.long.pdf, aka gao-rexford; though this has been shown to apply to the real internet far less strictly than many researchers have stubbornly assumed; see http://conferences2.sigcomm.org/imc/2015/papers/p71.pdf at the network ops level, a 'customer' is an ebgp-speaking AS to which you give routes learned from o other custimers o your peers o your upstreams/transits o your internals of course, by business arrangement, this might be restricted. this may be contrasted with peers and upstreams/transits, to whom you give only customer and internal routes. > Is "customer" being used a shorthand for another term that isn't > depending on an economic transaction? exactly > (If this was "the transitive closure of a client's clients", for > instance, I would know what that meant a route reflector's "clients" are ibgp speakers (stress is on the 'i') within the RR's AS. a (possibly improper) subset of those clients may be "customer aggregation" routers, i.e. connect via ebgp to ASs of external entities (aka customers). iff one or more of those RR clients (or their clients, cf 'transitive closure') speak bgpsec to a customer is the RR required to do bgpsec. if all the customers (which could be the null set) of of the RR's clients speak only bgp classic, there is no requirement that the RR speak bgpsec. I'm wondering if there's another term that's not wrong, and not more confusing. If you say there's not, I believe you! Thanks for catching me up. Spencer --001a114ea2f4e58c480545500149 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Randy,
On Jan 4, 2017 18:21, "Randy Bush" &l= t;randy@psg.com> wrote:
you are at the intersection (well act= ially union) of two twisty sets of
passages, bgp routing and internet ops.

> I'm wondering if "the transitive closure of a client's cu= stomers" has
> a precise meaning. I know what a customer is, at the hand-waving
> level

the academic, overly-idealized, definitions of customer/provider/peer=
are in https://www.cs.princeton.edu/~= jrex/papers/sigmetrics00.long.pdf,
aka gao-rexford; though this has been shown to apply to the real
internet far less strictly than many researchers have stubbornly
assumed; see http://conferences2.sigcomm.org/imc/2015/papers/p71.pdf

at the network ops level, a 'customer' is an ebgp-speaking AS to wh= ich
you give routes learned from
=C2=A0 o other custimers
=C2=A0 o your peers
=C2=A0 o your upstreams/transits
=C2=A0 o your internals
of course, by business arrangement, this might be restricted.

this may be contrasted with peers and upstreams/transits, to whom you
give only customer and internal routes.

> Is "customer" being used a shorthand for another term that i= sn't
> depending on an economic transaction?

exactly

> (If this was "the transitive closure of a client's clients&qu= ot;, for
> instance, I would know what that meant

a route reflector's "clients" are ibgp speakers (stress= is on the 'i')
within the RR's AS.=C2=A0 a (possibly improper) subset of those clients= may
be "customer aggregation" routers, i.e. connect via ebgp to ASs o= f
external entities (aka customers).=C2=A0 iff one or more of those RR client= s
(or their clients, cf 'transitive closure') speak bgpsec to a custo= mer
is the RR required to do bgpsec.=C2=A0 if all the customers (which could be=
the null set) of of the RR's clients speak only bgp classic, there is n= o
requirement that the RR speak bgpsec.

I'm wondering if there's another t= erm that's not wrong, and not more confusing. If you say there's no= t, I believe you!

Thanks= for catching me up.

Spe= ncer

=
--001a114ea2f4e58c480545500149-- From nobody Wed Jan 4 19:08:54 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A047212987B; Wed, 4 Jan 2017 19:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 jieJSr2eHURW; Wed, 4 Jan 2017 19:08:51 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 2D3C512986F; Wed, 4 Jan 2017 19:08:51 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cOyQ5-0006NJ-6K; Thu, 05 Jan 2017 03:08:49 +0000 Date: Thu, 05 Jan 2017 12:08:46 +0900 Message-ID: From: Randy Bush To: Spencer Dawkins at IETF In-Reply-To: References: <148355705100.13011.5709768999664450618.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: iesg@ietf.org, sidr wg list Subject: Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 03:08:52 -0000 spencer, [ btw, your mua seems not to do quoting level in its ascii rendering ] > you are at the intersection (well actially union) of two twisty sets of > passages, bgp routing and internet ops. > > > I'm wondering if "the transitive closure of a client's customers" has > > a precise meaning. I know what a customer is, at the hand-waving > > level > > the academic, overly-idealized, definitions of customer/provider/peer > are in https://www.cs.princeton.edu/~jrex/papers/sigmetrics00.long.pdf, > aka gao-rexford; though this has been shown to apply to the real > internet far less strictly than many researchers have stubbornly > assumed; see http://conferences2.sigcomm.org/imc/2015/papers/p71.pdf > > at the network ops level, a 'customer' is an ebgp-speaking AS to which > you give routes learned from > o other custimers > o your peers > o your upstreams/transits > o your internals > of course, by business arrangement, this might be restricted. > > this may be contrasted with peers and upstreams/transits, to whom you > give only customer and internal routes. > > > Is "customer" being used a shorthand for another term that isn't > > depending on an economic transaction? > > exactly > > > (If this was "the transitive closure of a client's clients", for > > instance, I would know what that meant > > a route reflector's "clients" are ibgp speakers (stress is on the 'i') > within the RR's AS. a (possibly improper) subset of those clients may > be "customer aggregation" routers, i.e. connect via ebgp to ASs of > external entities (aka customers). iff one or more of those RR clients > (or their clients, cf 'transitive closure') speak bgpsec to a customer > is the RR required to do bgpsec. if all the customers (which could be > the null set) of of the RR's clients speak only bgp classic, there is no > requirement that the RR speak bgpsec. > > > I'm wondering if there's another term that's not wrong, and not more > confusing. If you say there's not, I believe you! as we said in my long gone compiler days, 'customer cone' is a reserved word. > Thanks for catching me up. no extra charge randy From nobody Wed Jan 4 19:16:56 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 874EC12944F; Wed, 4 Jan 2017 19:16:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148358621555.12941.2980910611810370214.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 19:16:55 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-bgpsec-ops@ietf.org, sidr@ietf.org Subject: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 03:16:55 -0000 Terry Manderson has entered the following ballot position for draft-ietf-sidr-bgpsec-ops-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for creating a document to begin to pen the upcoming gotchas of BGPsec. I have a couple small comments. Section 3. "All non-ROA considerations in the section on RPKI Distribution and Maintenance of [RFC7115] apply." Apart from the sentence being stylistically terse (which I don't really care about), If you follow this as a reading list and hit section 3 of RFC7115 it leaves the reader wondering what considerations apply exactly. May I suggest: " The considerations for RPKI objects (Certificates, Certificate Revocation Lists (CRLs), manifests, Ghostbusters Records [RFC6481]), Trust Anchor Locators (TALs) [RFC6490], cache behaviours of synchronisation and validation from the section on RPKI Distribution and Maintenance of [RFC7115] apply. Specific considerations relating to ROA objects do not apply to this document" Forward apologies if that sounds pedantic. This is surely early days of BGPsec adoption and use. I have personal opinions about how adoption will go and what will be learnt or discovered along the way. So I do share Stephen's observation about painting one's self into a corner. From nobody Wed Jan 4 19:20:04 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BA4129888; Wed, 4 Jan 2017 19:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 IHSDM8x4k1jY; Wed, 4 Jan 2017 19:20:01 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 086851294EC; Wed, 4 Jan 2017 19:20:00 -0800 (PST) X-AuditID: c618062d-e8e5698000007359-98-586dc19311e3 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by (Symantec Mail Security) with SMTP id 7A.B7.29529.391CD685; Thu, 5 Jan 2017 04:46:27 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0319.002; Wed, 4 Jan 2017 22:19:59 -0500 From: Suresh Krishnan To: Sean Turner , Alexey Melnikov Thread-Topic: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) Thread-Index: AQHSZnEEWevxNHLRlky3ZRLPIAgPHw== Date: Thu, 5 Jan 2017 03:19:59 +0000 Message-ID: References: <148352385243.12916.15407627777806532255.idtracker@ietfa.amsl.com> <64ABB874-A355-4F91-93D6-6671CB6A354C@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyuXRPgu7kg7kRBk1bVC32vz/EZPFhyi92 ixl/JjJb9K++z2rxrPUlk8WVVY3MFt/nX2C1WDbpPKMDh8fOUwfYPPbOb2P3WLLkJ5PH1Jmz GT0OHmQMYI3isklJzcksSy3St0vgypj4/TB7wRy2iid737E2ME5m7WLk4JAQMJG4vSyki5GL Q0hgPaPE48cHmSGcZYwSB+/2sHQxcnKwARVt2PmZCcQWEfCS2LZlF1gRs8AEJonWHQtZQRLC AokSh+7PgipKkni67BwrhK0n8eLTbjCbRUBFYt3/v4wgNq+Ar8Tej1OZILYtZJR48GAeO0iC UUBM4vupNWCDmAXEJW49mQ9mSwgISCzZc54ZwhaVePn4HyuErSTx8fd8doh6HYkFuz+xQdja EssWvmaGWCYocXLmE5YJjCKzkIydhaRlFpKWWUhaFjCyrGLkKC0uyMlNNzLYxAiMqGMSbLo7 GO9P9zzEKMDBqMTD+4E3N0KINbGsuDL3EKMEB7OSCC/3DqAQb0piZVVqUX58UWlOavEhRmkO FiVx3rjV98OFBNITS1KzU1MLUotgskwcnFINjBM6FqTUfP/PqPuMS2hLTujhW0o3YkuC266v s862O+U0+fLyS0zbjzkUB7ncmRJ/sT77YeoHNoHzVgac398s2fOuRaurff2VuR/uRVw5auX7 PGiJQngDX6PKVD0rXyb32TnKEqs+KYsufLEoWiue0clUrOXGwqU//iZ/n+c1zahfcMk8nadK UUosxRmJhlrMRcWJADboIVakAgAA Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , sidr chairs , The IESG , sidr wg list , "m.waehlisch@fu-berlin.de" Subject: Re: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 03:20:02 -0000 On 01/04/2017 09:38 AM, Sean Turner wrote:=0A= >=0A= >> On Jan 4, 2017, at 05:09, Randy Bush wrote:=0A= >>=0A= >>> +1 to the comment from Suresh about order. I though that something like= =0A= >>> what he proposed will minimize memcopies and possibly use of memory why= =0A= >>> hashing. So I am also curious to know answer to his question.=0A= >>=0A= >> a vendor engineer actually implementing requested the change to the=0A= >> current syntax for ease of generating/parsing.=0A= >>=0A= >> randy=0A= >=0A= > I believe this is that thread that resulted in the final organization:=0A= >=0A= > https://mailarchive.ietf.org/arch/msg/sidr/8B_e4CNxQCUKeZ_AUzsdnn2f5MU=0A= =0A= Thanks for the pointer Sean. Very interesting.=0A= =0A= Regards=0A= Suresh=0A= =0A= From nobody Wed Jan 4 20:06:39 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490231298C1; Wed, 4 Jan 2017 20:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 VszDuU8u8ibQ; Wed, 4 Jan 2017 20:06:33 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 52F3C128BA2; Wed, 4 Jan 2017 20:06:33 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cOzJv-0006uS-0K; Thu, 05 Jan 2017 04:06:31 +0000 Date: Thu, 05 Jan 2017 13:06:28 +0900 Message-ID: From: Randy Bush To: "Terry Manderson" In-Reply-To: <148358621555.12941.2980910611810370214.idtracker@ietfa.amsl.com> References: <148358621555.12941.2980910611810370214.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: The IESG , sidr@ietf.org Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 04:06:34 -0000 > "The considerations for RPKI objects (Certificates, Certificate > Revocation Lists (CRLs), manifests, Ghostbusters Records [RFC6481]), > Trust Anchor Locators (TALs) [RFC6490], cache behaviours of > synchronisation and validation from the section on RPKI Distribution > and Maintenance of [RFC7115] apply. Specific considerations relating > to ROA objects do not apply to this document" done. one can tell you hang out with lawyers who are paid by the word. it says the exact same think with six times as many words. > This is surely early days of BGPsec adoption and use. I have personal > opinions about how adoption will go and what will be learnt or > discovered along the way. So I do share Stephen's observation about > painting one's self into a corner. we all have our worries. but when a major rtgsec hits the wsj, at elast we wil have a plan. randy From nobody Wed Jan 4 22:57:12 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248D612947E; Wed, 4 Jan 2017 22:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 PebUI4zUo97N; Wed, 4 Jan 2017 22:57:08 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 586EE1293EE; Wed, 4 Jan 2017 22:57:08 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cP1z0-0007XV-4O; Thu, 05 Jan 2017 06:57:06 +0000 Date: Thu, 05 Jan 2017 15:57:02 +0900 Message-ID: From: Randy Bush To: Sean Turner In-Reply-To: References: <148353788046.13042.160471261406266.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: The IESG , sidr@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 06:57:09 -0000 > Wait, I thought I wasn=A2t supposed to duplicate any of the crazy stuff > from 6487 :) duplication opens to errors in copying and makes later changes messier randy From nobody Wed Jan 4 23:24:38 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508401293EE; Wed, 4 Jan 2017 23:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 6gR7AHbzi8P4; Wed, 4 Jan 2017 23:24:34 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 38DAF1293DB; Wed, 4 Jan 2017 23:24:34 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cP2PW-0007bj-0Q; Thu, 05 Jan 2017 07:24:30 +0000 Date: Thu, 05 Jan 2017 16:24:27 +0900 Message-ID: From: Randy Bush To: Stephen Farrell In-Reply-To: References: <148353764984.13034.8506727126675155642.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: The IESG , sidr wg list Subject: Re: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 07:24:35 -0000 >> so, i think you are referring to >> >> As core BGPsec-capable routers may require large memory and/or modern >> CPUs, origin validation based on the Resource Public Key >> Infrastructure (RPKI), [RFC6811], will occur over some years and >> BGPsec will start to deploy after that. >> >> as rpki is deployed to a fair extent, origin validation is baked into >> current routers, and bgpsec in the core will require bigger hardware, OV >> before BGPsec would seem to be the sequence. >> >> otoh, your last statement is true, an operator will have to set up rpki >> data before deploying either origin validation or bgpsec. rpki is >> needed for both. >> >> so i am not sure what you are suggesting i do. > > I was suggesting re-wording so that the text cannot be read so > as to mean "don't bother with BGPsec until the entire world has > finished deploying OV." > > Maybe: > > As core BGPsec-capable routers may require large memory and/or modern > CPUs, origin validation based on the Resource Public Key > Infrastructure (RPKI), [RFC6811], will occur over some years and, > once origin validation has been deployed at an AS, then BGPsec > can start to deploy in that AS. > > Though I'm not sure that's precisely right either. ok, how about Origin Validation based on the Resource Public Key Infrastructure (RPKI), [RFC6811], is in its early phases. As BGPsec, [I-D.ietf-sidr-bgpsec-protocol] may require larger memory and/or more modern CPUs, it expected to be deployed incrementally over a longer time span. BGPsec is a new protocol with many operational considerations which this document attempts to describe. As with most operational practices, this document will likely evolve. i am still not in love with it. longitudinal study: how has the distribution of draft word count pre and post iesg review changed over time? for research papers, there is considerable pressure to be terse to get one's content into restricted page limits. randy From nobody Thu Jan 5 00:50:28 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F4212940D; Thu, 5 Jan 2017 00:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.301 X-Spam-Level: X-Spam-Status: No, score=-7.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, 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 RgqfbEmZMLih; Thu, 5 Jan 2017 00:50:20 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2C31294A3; Thu, 5 Jan 2017 00:50:20 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 5 Jan 2017 00:50:18 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Thu, 5 Jan 2017 00:50:18 -0800 From: Terry Manderson To: Randy Bush Thread-Topic: Terry Manderson's No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT) Thread-Index: AQHSZwItA0ivmlB5HkiF2bpgQHa6LKEpykUAgAD27gA= Date: Thu, 5 Jan 2017 08:50:18 +0000 Message-ID: References: <148358621555.12941.2980910611810370214.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3566487016_582112384" MIME-Version: 1.0 Archived-At: Cc: The IESG , "sidr@ietf.org" Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 08:50:23 -0000 --B_3566487016_582112384 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Super, Thanks. T. On 5/01/2017, 2:06 PM, "iesg on behalf of Randy Bush" wrote: > "The considerations for RPKI objects (Certificates, Certificate > Revocation Lists (CRLs), manifests, Ghostbusters Records [RFC6481]), > Trust Anchor Locators (TALs) [RFC6490], cache behaviours of > synchronisation and validation from the section on RPKI Distribution > and Maintenance of [RFC7115] apply. Specific considerations relating > to ROA objects do not apply to this document" done. one can tell you hang out with lawyers who are paid by the word. it says the exact same think with six times as many words. > This is surely early days of BGPsec adoption and use. I have personal > opinions about how adoption will go and what will be learnt or > discovered along the way. So I do share Stephen's observation about > painting one's self into a corner. we all have our worries. but when a major rtgsec hits the wsj, at elast we wil have a plan. randy --B_3566487016_582112384 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFCnU nk1w0vLLGbffqNfXpmlSnj2yMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE3MDEwNTA4NTAxNlowDQYJKoZIhvcNAQEBBQAEggEALE4OKdmSO6V0E/h4mjRK 2FDdgPqQ9AyzonvF/nOh5uZ3cFI458UTl8Cea0LPokVFG1ygSRdE4/WNXmJdzKppoWfuFTgJ cNu9tTJWacE5ptFwIXez0/v0vbX8x7b01WNiXmAjU2OHF7aBTo5eLabw4yn5fimmW5jBQIxU lhZG/Fyx2ZcKpwIouBYzg5UhNib4XsSUNzezns5FRRFFowgDFPgV2pneAxNbKLvV0Pvqlftp ElmZVthwt3HdqMFkr3cLgVRh0d1EDUreK7ujOnBmryZpX4LgQY9WXLzWVE1bs3GsGYV3GhKX FuKiA7VBDhxkUWd23R0IKj8HDfj+2+3Icg== --B_3566487016_582112384-- From nobody Thu Jan 5 01:48:14 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CE1129405; Thu, 5 Jan 2017 01:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=MmKdX5Rv; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=XmQgNKgF 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 kMaEy23S9JFq; Thu, 5 Jan 2017 01:48:10 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948951204D9; Thu, 5 Jan 2017 01:48:10 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C982C2085E; Thu, 5 Jan 2017 04:48:09 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Thu, 05 Jan 2017 04:48:09 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=dqHIpqN4rl8EiSs tuZEyYTTRDx0=; b=MmKdX5Rv4eifY9qQSZMJsNP5bRmGxyjDTtL4rWSVX3+Mb45 bk2CTizG6es7pJdq+dPToh+sd3VHV3y1moDfloUK+jKdeDDMIDgtDKB75bZjwzyx 19D/Cnv1bS09wqGz/PwB45upu/LIdRp3Dk1+1qUEYwvpEr4txObC9CtxXPCY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=dqHIpqN4rl8EiSstuZEyYTTRDx0=; b=XmQgNKgF8T0Pro4AhxjI V+FegXVQXcZx3X7Zzm2W6i7gsSIjURVylmlDHcRxc8jexJBHzzKwqbCKF7h0qwXs iJP0MoAhVJIDSOXL4OO31ZhXkOjowKg+UgvoUymPnpfxhDEefkRa20z+0MLuWT3v ALjN8eYULI3LAwzby4rPEDY= X-ME-Sender: X-Sasl-enc: qvENmQrBnIc3ANUztOX7gHMG6In6A/sWZSXfgt4o2Sx0 1483609689 Received: from [10.218.214.73] (unknown [148.252.128.226]) by mail.messagingengine.com (Postfix) with ESMTPA id 620D424077; Thu, 5 Jan 2017 04:48:09 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Thu, 5 Jan 2017 09:57:06 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <309117C0-FA5E-412A-B19B-F2C86B2DA02B@fastmail.fm> References: <148352385243.12916.15407627777806532255.idtracker@ietfa.amsl.com> <64ABB874-A355-4F91-93D6-6671CB6A354C@sn3rd.com> To: sidr wg list Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , "m.waehlisch@fu-berlin.de" , sidr chairs , The IESG Subject: Re: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 09:48:12 -0000 > On 5 Jan 2017, at 03:19, Suresh Krishnan wr= ote: >=20 >> On 01/04/2017 09:38 AM, Sean Turner wrote: >>=20 >>>> On Jan 4, 2017, at 05:09, Randy Bush wrote: >>>>=20 >>>> +1 to the comment from Suresh about order. I though that something like= >>>> what he proposed will minimize memcopies and possibly use of memory why= >>>> hashing. So I am also curious to know answer to his question. >>>=20 >>> a vendor engineer actually implementing requested the change to the >>> current syntax for ease of generating/parsing. >>>=20 >>> randy >>=20 >> I believe this is that thread that resulted in the final organization: >>=20 >> https://mailarchive.ietf.org/arch/msg/sidr/8B_e4CNxQCUKeZ_AUzsdnn2f5MU >=20 > Thanks for the pointer Sean. Very interesting. Indeed! I wish a few words about design could be added to the draft. From nobody Thu Jan 5 02:58:43 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671F51293E1; Thu, 5 Jan 2017 02:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 dioPK6o2C-4B; Thu, 5 Jan 2017 02:58:35 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 13095128DF6; Thu, 5 Jan 2017 02:58:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 836992D291; Thu, 5 Jan 2017 12:58:33 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVvMNwWEqE42; Thu, 5 Jan 2017 12:58:33 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 16D732D290; Thu, 5 Jan 2017 12:58:33 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1B585AA7-586B-4F64-92C7-696450E187F3"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <148180713687.27658.2938123182879685300.idtracker@ietfa.amsl.com> Date: Thu, 5 Jan 2017 12:58:32 +0200 Message-Id: References: <148180713687.27658.2938123182879685300.idtracker@ietfa.amsl.com> To: Roni Even X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: gen-art@ietf.org, draft-ietf-sidr-bgpsec-ops.all@ietf.org, ietf@ietf.org, sidr@ietf.org Subject: Re: [sidr] Review of draft-ietf-sidr-bgpsec-ops-12 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 10:58:37 -0000 --Apple-Mail=_1B585AA7-586B-4F64-92C7-696450E187F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for your review, Roni. > I think the document need an editorial review, a lot of text in > passive language, for example Authors =97 do take a note. I am posting a No Objection vote on the document in today=92s IESG = telechat. Jari --Apple-Mail=_1B585AA7-586B-4F64-92C7-696450E187F3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYbibYAAoJEM80gCTQU46qtJwP/ifurzLRWdDD8n4SVW8kDq7u 4PkS55XIoEh2gcZCdwOGOwzXpn0724D9yePxN6RII9PKocEy5WY65WcwZmQpnVlc 4UWaTHpnloyhYVueRKit/cI+nBE2jx0P6YWgoPQ+py/inCud/2YMDapIckVPLep4 fDJNulxZobXFuZVKR2/AUDY+K1vfrK+r3a/4QwMXCUdpaaOQ2rbL9GFBpMP0bc+L kvfYHC3AKoBBzz5Zf8Dn2bs9AEjKRhFqNTobR1CvGn5DM4WvsxE9+WoyQ8hPxODs b+mBiwwPUnb3sHuMrz/DswUuYv3ULjxalAoGuIPxO+Pgqq4kF7hlhaTrEJP5KAw9 UKjDMDjG7u+IzJIMFLreP7aBlSFNZWLoUDzEZ2AgkqVah8/ES3lOFefCYMyzK5+l xP+nQQz5J7SguiF/TyugHJ4fgRkgNAZv2tN5BPNi0aJZgUrSbV1yBdAinLpTGDgU iAcsr9AumDWaZZk4akxLy0uaacnwWdIWAldMQFhgv1npYJl2CQLHIl8SY2VA38go P0s+lF0s6r+QKCNWjABw1zZ4Cluj5V+VDc5AyNGBo14FlVmfm+KynqmTyLR2+Jsy UpLI+f3TS49h2HZc/hGyU6crRyA7T9jpFj2ca2HyODdSJBlpF/hJsMEnESAjSB9K F4pte2VlJ5UJGiXgnxJZ =iV3E -----END PGP SIGNATURE----- --Apple-Mail=_1B585AA7-586B-4F64-92C7-696450E187F3-- From nobody Thu Jan 5 03:10:55 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D58312946E; Thu, 5 Jan 2017 03:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 a8GvAqXloNfy; Thu, 5 Jan 2017 03:10:41 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCF412943F; Thu, 5 Jan 2017 03:10:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9C1852D291; Thu, 5 Jan 2017 13:10:40 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVm8NeDMpQ1k; Thu, 5 Jan 2017 13:10:40 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id F3D9B2D290; Thu, 5 Jan 2017 13:10:39 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_454B6028-C164-4E50-B231-A60C76316BBB"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <148346011373.28055.14231244831041167421.idtracker@ietfa.amsl.com> Date: Thu, 5 Jan 2017 13:10:39 +0200 Message-Id: References: <148346011373.28055.14231244831041167421.idtracker@ietfa.amsl.com> To: Dale Worley X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: gen-art@ietf.org, draft-ietf-sidr-bgpsec-pki-profiles.all@ietf.org, ietf@ietf.org, sidr@ietf.org Subject: Re: [sidr] [Gen-art] Review of draft-ietf-sidr-bgpsec-pki-profiles-19 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 11:10:43 -0000 --Apple-Mail=_454B6028-C164-4E50-B231-A60C76316BBB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dale, all, Thanks for the review, re-review, and changes. I=92m posting a No = Objection position for this draft in today=92s IESG telechat. But: > 3.1.1. Subject >=20 > However, each > certificate issued by an individual CA MUST contain a Subject name > that is unique to that CA context. >=20 > E-mail from Sean Turner on 22 Dec 2016 says: >=20 > I think this is just a case of a missing "CA" in front of the > word > "context" so tweaking it to: ".... that is unique to that CA > context". The certs only need to be unique on a per CA basis the > subject name does not need to be unique across the whole of the > RPKI. The combination of issuer+subject+serial # plus all the > parent certs provides the uniqueness. >=20 > However, there doesn't seem to be a standard meaning of the phrase > "CA > context". I can't find any occurrences in any RFC or in any I-D > other > than draft-ietf-trans-threat-analysis-NN. Is a good question. > It seems to me that the best solution is to put a cleaned-up version > of Sean's statement "The combination of issuer+subject+serial # plus > all parent certs provides the uniqueness." into the draft, as that is > admirably clear. (Unless, of course, there is a standard PKI phrase > for that requirement, in which case that could be used.) For > instance: >=20 > However, the combination of subject name, serial number, issuer, > and certification path must be globally unique. That would be clearer for me, assuming that is what was actually meant, = of course :-) > 3.3. BGPsec Router Certificate Validation >=20 > The validation procedure used for BGPsec Router Certificates is > identical to the validation procedure described in Section 7 of > [RFC6487] (and any RFC that updates this procedure), as modified > below. For example, in step 3: "The certificate contains all > field > that must be present" - refers to the fields that are required by > this specification. >=20 > This picks up the changes from Sean Turner's e-mail of 22 Dec 2016 > except it omits changing "that updates this procedure" to "that > updates that procedure", which seems to me to necessary to make the > wording correct. I think that=92s right. > step 3: "The certificate contains all field that must be present" >=20 > This doesn't match the text in RFC 6487, despite claiming to be > quoted: > s/all field/all fields/ and s/must/MUST/. Right. > 7. IANA Considerations >=20 > No IANA allocations are request of IANA, ... >=20 > I think this should be "No IANA allocations are requested of IANA", > or > probably better "No allocations are requested of IANA". >=20 > E-mail from Sean Turner on 22 Dec 2016 says "Alvaro had a similar > comment on the IANA considerations and he suggested the first > option.", but no change has been made. OK Jari --Apple-Mail=_454B6028-C164-4E50-B231-A60C76316BBB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYbimvAAoJEM80gCTQU46qW44P/R2D0hoEVbFfkbefr52qoQVw Z1Recdc7OHf+jEDM6NHvyVAdk4l0shcLUdF4pUZCshROrWpHLMDhkaIOUREEpo2y mnKKdpTWVX6EP5fkcoh2WWVpSEptBc/iixmeDvOgqxuvQqTg6LyebU/IwGvok4tT 9XT9hJm42aERA82TlPdPeB+OnGJBoQyNK4Vh9MVp0B+YOY0qaWwVkMjDBAKNQsBV 5GoIilh18FCFVRjI2qiUZHVWaCYQQYqnIaB6HYfa4E67o4GYsyQqJlrYTs8KPsmh gEHKDw/RD0c3gsVAvkNWjqMwjYj1h7xr2reFnUPZCriPubAtINyCaHu/aolwBVI0 K7B4vxydIRRAKd/VsQGYRWIpZAnjKnSqDEznzAFiBy79WjSR+HkigPzz/oH5kCov IWG9PpSEydNPtjHETlaPIaufN9DvBLgeCeWv5CMGxRYkDTQzNVt6pWlb0g+RqfkE ElQdceiqwPjGvZPnhR4NDkSiI2y7IPVZJcRs6nD0HnGN0zmRHxz9BNykRqMf1m8O DjsMDVNOOCTD0wiEbyPLWtDu+TRbHda+QGWUVwv7KJ05Lgco6W9ZaS7cf5nF11Db FHgBOAUCDT0gX1uq2VCVeq7DWS5ieC+qXb3/Z7LDBIF1ANM3VdWJkAe+e++UNI7R hnw/Y/71wMDZGhx1J7qP =csuK -----END PGP SIGNATURE----- --Apple-Mail=_454B6028-C164-4E50-B231-A60C76316BBB-- From nobody Thu Jan 5 03:12:27 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6568C12943F; Thu, 5 Jan 2017 03:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 biQ0kSD4cOS2; Thu, 5 Jan 2017 03:12:24 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 07C42129418; Thu, 5 Jan 2017 03:12:24 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cP5xv-0008SA-I1; Thu, 05 Jan 2017 11:12:16 +0000 Date: Thu, 05 Jan 2017 20:12:12 +0900 Message-ID: From: Randy Bush To: Jari Arkko In-Reply-To: References: <148180713687.27658.2938123182879685300.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: gen-art@ietf.org, Roni Even , ietf@ietf.org, sidr@ietf.org Subject: Re: [sidr] Review of draft-ietf-sidr-bgpsec-ops-12 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 11:12:25 -0000 thanks roni. i wonder how i missed your message. my bad. >> I think the document need an editorial review, a lot of text in >> passive language, for example i confess it is my normal mode, despite being a strunk and white fan. sometimes rfced agrees, sometimes not and fixes. unless it is a real problem, i think i will not chase this one. randy From nobody Thu Jan 5 04:01:57 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8421294AE; Thu, 5 Jan 2017 04:01:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jari Arkko" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148361771296.20653.10911868719969914017.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2017 04:01:52 -0800 Archived-At: Cc: draft-ietf-sidr-as-migration@ietf.org, sidr@ietf.org, morrowc@ops-netman.net, sidr-chairs@ietf.org Subject: [sidr] Jari Arkko's No Objection on draft-ietf-sidr-as-migration-06: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 12:01:53 -0000 Jari Arkko has entered the following ballot position for draft-ietf-sidr-as-migration-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Per Wassim Haddad's Gen-ART review (thanks!), there seems to be a word missing here: "Route Origin Validation as defined by RFC 6480 [RFC6480] does not modification to enable AS migration, ..." From nobody Thu Jan 5 04:33:48 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5AC112953F; Thu, 5 Jan 2017 04:33:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148361962380.20571.5512181482631486478.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2017 04:33:43 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-15.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 12:33:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : BGPsec Operational Considerations Author : Randy Bush Filename : draft-ietf-sidr-bgpsec-ops-15.txt Pages : 9 Date : 2017-01-05 Abstract: Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. It is expected to evolve as BGPsec is formalized and initially deployed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-ops-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 5 04:38:40 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE761129410; Thu, 5 Jan 2017 04:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 R3ADTN8LShhe; Thu, 5 Jan 2017 04:38:30 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 96E8B1288B8; Thu, 5 Jan 2017 04:38:30 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cP7JJ-0000K2-Js; Thu, 05 Jan 2017 12:38:26 +0000 Date: Thu, 05 Jan 2017 21:38:22 +0900 Message-ID: From: Randy Bush To: Roni Even In-Reply-To: <148180713687.27658.2938123182879685300.idtracker@ietfa.amsl.com> References: <148180713687.27658.2938123182879685300.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: gen-art@ietf.org, ietf@ietf.org, sidr@ietf.org Subject: Re: [sidr] Review of draft-ietf-sidr-bgpsec-ops-12 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 12:38:33 -0000 > I think the document need an editorial review, a lot of text in > passive language, for example third paragraph in section 1 > "BGPsec needs to be spoken only by an AS's eBGP speaking, AKA border, > routers, and is designed so that it can be used to protect > announcements which are originated by resource constrained edge > routers." is written in passive language and it is also a long > sentence. -15 has BGPsec needs to be spoken only by an AS's eBGP-speaking border routers. It is designed so that it can be used to protect announcements which are originated by resource constrained edge routers. This has special operational considerations, see Section 6. from wikipedia, the authority for everything :) Use of the passive in English varies with writing style and field. Some publications' style sheets discourage use of the passive voice,[3] while others encourage it.[4] Although some purveyors of usage advice, including George Orwell in Politics and the English Language and William Strunk, Jr. and E. B. White in The Elements of Style, discourage use of the passive in English, its usefulness is generally recognized, particularly in cases where the patient is more important than the agent,[5] but also in some cases where it is desired to emphasize the agent. randy From nobody Thu Jan 5 05:02:19 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F611288B8; Thu, 5 Jan 2017 05:02:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148362133698.20681.7770377914279192976.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2017 05:02:16 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-21.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 13:02:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests Authors : Mark Reynolds Sean Turner Stephen Kent Filename : draft-ietf-sidr-bgpsec-pki-profiles-21.txt Pages : 12 Date : 2017-01-05 Abstract: This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in the Internet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end-entity (EE) certificates specified by this profile are issued to routers within an Autonomous System. Each of these certificates is issued under a Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Identifier Delegation extension. An EE certificate of this type asserts that the router(s) holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests, and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends the RPKI; therefore, this documents updates the RPKI Resource Certificates Profile (RFC 6487). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 5 05:03:48 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF451294EB for ; Thu, 5 Jan 2017 05:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 lIbAgDF6C50r for ; Thu, 5 Jan 2017 05:03:46 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 5086D12711D for ; Thu, 5 Jan 2017 05:03:46 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id c47so518087381qtc.2 for ; Thu, 05 Jan 2017 05:03:46 -0800 (PST) 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=wE05mRFP2OXOaYgLqgu25uXHtDJ3YJW0N0/HnnXl12o=; b=cTdympKhCHhH9hhUsCpiNO0ui9Sw5VmkkhXdYkb18vISqUE8LrPLBfIHrijYiKlZEE aBV709nr49r3CGX7n65GeHBJZVZ3lKr7W/Kz7Zsk9NZqQCJ5NT7YduRNwJ0jid80g0GD 8roj1s8X5R7wsk/bHi6lEo9YiZUCKDEEdvSmo= 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=wE05mRFP2OXOaYgLqgu25uXHtDJ3YJW0N0/HnnXl12o=; b=eUobQkLQv//hBE958+Gg02QLvynKEP4/yR86UlepAyYr3lwvv+TGti2p9BRdVS+Ism Olct79XKUTLWS4SJL+3JRXj4Sca1JqCAtVvKldzP4+napfk73vuviHr9BGD5LB5i5Cyn bSgg0VHdtlNHjCx+MkkfgCkSbZSQgvdlFVeD/7GCTtHR6IkquPHe/jNdwfMC6QfyCIVr PnJEUwGbCXS9u0mP+TchuayZqTNUookQ3RXhVnIq4lret6DcMBmHpQjdCaSP0pnbbyVc XeKVqONOdm3KV3cqdETBkQTpAVWMLY3N0LdEGcuAnA9Vk+oDxfm6/s1D8JmAZ8oC3+fT Ms2w== X-Gm-Message-State: AIkVDXJ1ICez+WONmCq4BsMBF31vupuH6OWlC3x+8uWCjeeIz1TP9YhM9Pi2a5X8uPlCRg== X-Received: by 10.237.49.230 with SMTP id 93mr65117460qth.109.1483621425263; Thu, 05 Jan 2017 05:03:45 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id e63sm48057310qkc.29.2017.01.05.05.03.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Jan 2017 05:03:44 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <148362133698.20681.7770377914279192976.idtracker@ietfa.amsl.com> Date: Thu, 5 Jan 2017 08:03:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6207B29B-00FD-492E-9411-6C166A1BC73B@sn3rd.com> References: <148362133698.20681.7770377914279192976.idtracker@ietfa.amsl.com> To: The IESG X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-21.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 13:03:48 -0000 This version incorporates the things I missed in the GENART review = (thank Jari). spt > On Jan 5, 2017, at 08:02, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing of the = IETF. >=20 > Title : A Profile for BGPsec Router Certificates, = Certificate Revocation Lists, and Certification Requests > Authors : Mark Reynolds > Sean Turner > Stephen Kent > Filename : draft-ietf-sidr-bgpsec-pki-profiles-21.txt > Pages : 12 > Date : 2017-01-05 >=20 > Abstract: > This document defines a standard profile for X.509 certificates used > to enable validation of Autonomous System (AS) paths in the Border > Gateway Protocol (BGP), as part of an extension to that protocol > known as BGPsec. BGP is the standard for inter-domain routing in = the > Internet; it is the "glue" that holds the Internet together. BGPsec > is being developed as one component of a solution that addresses the > requirement to provide security for BGP. The goal of BGPsec is to > provide full AS path validation based on the use of strong > cryptographic primitives. The end-entity (EE) certificates = specified > by this profile are issued to routers within an Autonomous System. > Each of these certificates is issued under a Resource Public Key > Infrastructure (RPKI) Certification Authority (CA) certificate. > These CA certificates and EE certificates both contain the AS > Identifier Delegation extension. An EE certificate of this type > asserts that the router(s) holding the corresponding private key are > authorized to emit secure route advertisements on behalf of the > AS(es) specified in the certificate. This document also profiles = the > format of certification requests, and specifies Relying Party (RP) > certificate path validation procedures for these EE certificates. > This document extends the RPKI; therefore, this documents updates = the > RPKI Resource Certificates Profile (RFC 6487). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-21 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-pki-profiles-21= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Jan 5 05:42:38 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295AC129450; Thu, 5 Jan 2017 05:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 EHAXh9IzAAAF; Thu, 5 Jan 2017 05:42:36 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8952129437; Thu, 5 Jan 2017 05:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9184; q=dns/txt; s=iport; t=1483623756; x=1484833356; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XG48Q4aWisnR5HDnrTWd2awZtMANL4rL7O0MBNHGgP4=; b=MgSAr9GtQxKjUBw8oXwZsmEpLA6iXCg1KFFhAJEN8oyP26SrUhgwV6cT FyMQJDlmjGC9Nh7euazLv3yRu9vTkQTOs9k5O9T3g/hgbN7Ta1jjJWaqC XWWUl41wo16TodrlgSD6p/Dqb1VB43HHrSDxEJeP4Rtap5E6Dskxysgwx 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DlAgCKTG5Y/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnFHAQEBAQEfX4EMB4NIrkyDG4IPggmGIgIagT9BEgECAQEBAQE?= =?us-ascii?q?BAWMohGkGI1YQAgEIPwMCAgIwFBECBAENBYhwr0KCJSuJeAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2GRYICCIJXh04tgjEFlRaFegGRQpBakkUBJgkogTsVQgGEGBw?= =?us-ascii?q?YgUdzhisrgQOBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,321,1477958400"; d="scan'208,217";a="192796480" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jan 2017 13:42:35 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v05DgZAg005271 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Jan 2017 13:42:35 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 5 Jan 2017 07:42:35 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Thu, 5 Jan 2017 07:42:34 -0600 From: "Alvaro Retana (aretana)" To: Randy Bush , Terry Manderson Thread-Topic: Terry Manderson's No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT) Thread-Index: AQHSZwIsbLNh7zc5zEGlOyHa/hDrHqEpqL4AgABNKIA= Date: Thu, 5 Jan 2017 13:42:34 +0000 Message-ID: <56298C9D-1312-45E7-AA1C-9F9A0A44AD9A@cisco.com> References: <148358621555.12941.2980910611810370214.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: multipart/alternative; boundary="_000_56298C9D131245E7AA1C9F9A0A44AD9Aciscocom_" MIME-Version: 1.0 Archived-At: Cc: The IESG , "sidr@ietf.org" Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 13:42:38 -0000 --_000_56298C9D131245E7AA1C9F9A0A44AD9Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmFuZHk6DQoNCkp1c3Qgb25lIG5pdDogUkZDNjQ5MCB3YXMgb2Jzb2xldGVkIGJ5IHJmYzc3MzAu DQoNClNvcnJ5IEkgZGlkbuKAmXQgY2F0Y2ggdGhpcyBlYXJsaWVyLiAgSSB0aGluayB0aGlzIGlz IHRoZSBsYXN0IGNoYW5nZSBuZWVkZWQsIHNvIEnigJlsbCB0YWtlIGNhcmUgb2YgaXQgd2l0aCBh IG5vdGUgdG8gdGhlIFJGQyBFZGl0b3IuDQoNClRoYW5rcyENCg0KQWx2YXJvLg0KDQoNCk9uIDEv NC8xNywgMTE6MDYgUE0sICJpZXNnIG9uIGJlaGFsZiBvZiBSYW5keSBCdXNoIiA8aWVzZy1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzppZXNnLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBy YW5keUBwc2cuY29tPG1haWx0bzpyYW5keUBwc2cuY29tPj4gd3JvdGU6DQoNCiJUaGUgY29uc2lk ZXJhdGlvbnMgZm9yIFJQS0kgb2JqZWN0cyAoQ2VydGlmaWNhdGVzLCBDZXJ0aWZpY2F0ZQ0KUmV2 b2NhdGlvbiBMaXN0cyAoQ1JMcyksIG1hbmlmZXN0cywgR2hvc3RidXN0ZXJzIFJlY29yZHMgW1JG QzY0ODFdKSwNClRydXN0IEFuY2hvciBMb2NhdG9ycyAoVEFMcykgW1JGQzY0OTBdLCBjYWNoZSBi ZWhhdmlvdXJzIG9mDQpzeW5jaHJvbmlzYXRpb24gYW5kIHZhbGlkYXRpb24gZnJvbSB0aGUgc2Vj dGlvbiBvbiBSUEtJIERpc3RyaWJ1dGlvbg0KYW5kIE1haW50ZW5hbmNlIG9mIFtSRkM3MTE1XSBh cHBseS4gU3BlY2lmaWMgY29uc2lkZXJhdGlvbnMgcmVsYXRpbmcNCnRvIFJPQSBvYmplY3RzIGRv IG5vdCBhcHBseSB0byB0aGlzIGRvY3VtZW50Ig0KDQpkb25lLiAgb25lIGNhbiB0ZWxsIHlvdSBo YW5nIG91dCB3aXRoIGxhd3llcnMgd2hvIGFyZSBwYWlkIGJ5IHRoZSB3b3JkLg0KaXQgc2F5cyB0 aGUgZXhhY3Qgc2FtZSB0aGluayB3aXRoIHNpeCB0aW1lcyBhcyBtYW55IHdvcmRzLg0K --_000_56298C9D131245E7AA1C9F9A0A44AD9Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3Rl eHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNv SW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5SYW5keTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5KdXN0IG9u ZSBuaXQ6IFJGQzY0OTAgd2FzIG9ic29sZXRlZCBieSByZmM3NzMwLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPlNvcnJ5IEkgZGlkbuKAmXQgY2F0Y2ggdGhpcyBlYXJsaWVyLiZuYnNwOyBJIHRo aW5rIHRoaXMgaXMgdGhlIGxhc3QgY2hhbmdlIG5lZWRlZCwgc28gSeKAmWxsIHRha2UgY2FyZSBv ZiBpdCB3aXRoIGEgbm90ZSB0byB0aGUgUkZDIEVkaXRvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj5UaGFua3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+QWx2YXJvLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxLzQvMTcsIDExOjA2IFBN LCAmcXVvdDtpZXNnIG9uIGJlaGFsZiBvZiBSYW5keSBCdXNoJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86aWVzZy1ib3VuY2VzQGlldGYub3JnIj5pZXNnLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9u IGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOnJhbmR5QHBzZy5jb20iPnJhbmR5QHBzZy5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDow aW47Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3Rh cnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNp bmc6MHB4IiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJr aXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZxdW90O1Ro ZSBjb25zaWRlcmF0aW9ucyBmb3IgUlBLSSBvYmplY3RzIChDZXJ0aWZpY2F0ZXMsIENlcnRpZmlj YXRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlJldm9jYXRpb24gTGlzdHMgKENSTHMp LCBtYW5pZmVzdHMsIEdob3N0YnVzdGVycyBSZWNvcmRzIFtSRkM2NDgxXSksPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPlRydXN0IEFuY2hvciBMb2NhdG9ycyAoVEFMcykgW1JGQzY0OTBd LCBjYWNoZSBiZWhhdmlvdXJzIG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13 ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPnN5bmNo cm9uaXNhdGlvbiBhbmQgdmFsaWRhdGlvbiBmcm9tIHRoZSBzZWN0aW9uIG9uIFJQS0kgRGlzdHJp YnV0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmFuZCBNYWludGVuYW5jZSBvZiBb UkZDNzExNV0gYXBwbHkuIFNwZWNpZmljIGNvbnNpZGVyYXRpb25zIHJlbGF0aW5nPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPnRvIFJPQSBvYmplY3RzIGRvIG5vdCBhcHBseSB0byB0aGlz IGRvY3VtZW50JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5k YXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5kb25lLiZuYnNwOyZuYnNw O29uZSBjYW4gdGVsbCB5b3UgaGFuZyBvdXQgd2l0aCBsYXd5ZXJzIHdobyBhcmUgcGFpZCBieSB0 aGUgd29yZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFy ZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+aXQgc2F5cyB0aGUgZXhhY3Qg c2FtZSB0aGluayB3aXRoIHNpeCB0aW1lcyBhcyBtYW55IHdvcmRzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_56298C9D131245E7AA1C9F9A0A44AD9Aciscocom_-- From nobody Thu Jan 5 05:45:46 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D98129437; Thu, 5 Jan 2017 05:45:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148362394153.20677.9900839049383127449.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2017 05:45:41 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-16.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 13:45:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : BGPsec Operational Considerations Author : Randy Bush Filename : draft-ietf-sidr-bgpsec-ops-16.txt Pages : 9 Date : 2017-01-05 Abstract: Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. It is expected to evolve as BGPsec is formalized and initially deployed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-ops-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 5 05:46:24 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99976129437; Thu, 5 Jan 2017 05:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 unILADEwxEFx; Thu, 5 Jan 2017 05:46:17 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 AB7CD1294EB; Thu, 5 Jan 2017 05:46:16 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cP8Mu-0000bd-9l; Thu, 05 Jan 2017 13:46:12 +0000 Date: Thu, 05 Jan 2017 22:46:09 +0900 Message-ID: From: Randy Bush To: "Alvaro Retana (aretana)" In-Reply-To: <56298C9D-1312-45E7-AA1C-9F9A0A44AD9A@cisco.com> References: <148358621555.12941.2980910611810370214.idtracker@ietfa.amsl.com> <56298C9D-1312-45E7-AA1C-9F9A0A44AD9A@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "sidr@ietf.org" , The IESG Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 13:46:19 -0000 > Just one nit: RFC6490 was obsoleted by rfc7730. -16 pushed with fix From nobody Thu Jan 5 06:10:14 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95830129465; Thu, 5 Jan 2017 06:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 MPsv_UAGpB5E; Thu, 5 Jan 2017 06:10:10 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0128.outbound.protection.outlook.com [23.103.200.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A21126579; Thu, 5 Jan 2017 06:10:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N93aqEYEFvRFn0hVMxZ3RKqYkOpKP8zq2cU+xgZwx5A=; b=Ghg7S87a5jo0DscvuKWByd3eR6XoLCKSQDieNNamkvtKp9WPKAatgkwQZT9uA32sN9lWZkoeB2U68U2iAoA8qRWXFcB0ObLm9Y7af2EKOLxm7hpAdUBX/6iVHn/hdkTjT4CLR6Z/2GKg7ZKiooj3SE3G9t+DDzfrQMVk/72kOi4= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0445.namprd09.prod.outlook.com (10.161.252.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Thu, 5 Jan 2017 14:10:07 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0817.012; Thu, 5 Jan 2017 14:10:06 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) Thread-Index: AQHSZpHl3JK9Ep+Hw0SM2CHq7jfcT6Ep5Pcg Date: Thu, 5 Jan 2017 14:10:06 +0000 Message-ID: References: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> In-Reply-To: <148353798879.13011.5291414579598073386.idtracker@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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.220.168] x-ms-office365-filtering-correlation-id: 35952ddd-aa6b-48a0-4fec-08d435748d18 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0445; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0445; 7:0Ea8/SXUbWDe37w3v43I0eOgZHXddim0eRSK8T1x/J+vp40OODmsWB5Z3d7+5Ruwz7nX5JfGbWm64WnufwLpRD949aDpKlV/mdbxknlZ6VheGgRj/GtxzGAOYNzDiewQMyS1DmxQAAk+OhSE9ZphPPWpKmeJqVGT3FjZlnYITAKrahz5AVZ6koWmbOnZkLWw00k3ztY+ETW9IlSFCZQUTSlVoGhlr8udIggpFi7nItoefmryx1sG2o1lt6+3E8fQQll/21MyNLEO/DvDVqvPoU1b2ks8A9Pqw6enIfpgdJ8g/w83a+BfLsan5vHEkWjDFWrkULfmpK5J9AEp9Rt3kqiv/q7OZcRr0sompt+/2xxHu/ZNonkbLFVxBEi6a6fgm/0jf/wscrzJ6byzv4HsgscbYp3fMtyWnvnLDkIbeDZHvNoo/VibrR8r1Uj7I+qTWKnqsncoM6QSz0wayhn6GQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:DM2PR09MB0445; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0445; x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39410400002)(39850400002)(39840400002)(39450400003)(189002)(199003)(8676002)(38730400001)(305945005)(92566002)(66066001)(189998001)(5001770100001)(54356999)(54906002)(4326007)(2906002)(3660700001)(97736004)(3280700002)(5660300001)(3846002)(345774005)(7696004)(6116002)(102836003)(74316002)(77096006)(81156014)(81166006)(7736002)(6506006)(6436002)(230783001)(106356001)(33656002)(2900100001)(9686002)(68736007)(229853002)(8936002)(25786008)(2950100002)(86362001)(55016002)(76176999)(50986999)(122556002)(101416001)(106116001)(99286003)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0445; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2017 14:10:06.3557 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0445 Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , "sidr-chairs@ietf.org" , "m.waehlisch@fu-berlin.de" , "sidr@ietf.org" Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 14:10:12 -0000 Stephen, Thank you for the detailed review and comments. Please see my responses marked with [Sriram] inline below. [Sriram] Your DISCUSS points (1) and (3) were already discussed /being discussed in separate threads. > (2) Figure 8: It seems to me to be an error to omit the signer's ASN from the signed data and only have that included in the signer's certificate. Why is that intimate level of binding to the RPKI desirable? There may well be reasons but I'm not seeing 'em, and I am recalling that it took a chunk of effort to make CMS less dependent on X.509 for similar reasons (meaning identifying signers exclusively via cert issuer and serial in that case). I would expect that there could be demand to have some level of independence between BGPsec and RPKI for at least internal uses such as those noted in the spec already. [Sriram] Signer's ASN is indeed included in the signed data. In Figure 8, "Secure_Path Segment : N" corresponds to the signing AS (current AS) and that is where the=20 signer's ASN is included along with its pCount and Flags. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > - Figures 2 and 5 present the fields in different orders. That seems like a bad idea. [Sriram] Good catch. Already fixed in my editor copy of version-22.=20 > - 3.2: The reference to the pki profile doc is not precise enough, the string "key identifier" does not occur in that draft - it's in RFC6487, 4.8.2.=20 [Sriram] Again, a good catch. Already fixed in my editor copy of version-22= . =20 > - 4.1, last para: is the distinction between an "internal peer" and "iBGP peer" sufficiently clear to routing folk? For me they sound similar but I assume it's ok. [Sriram] I think it is well understood. But when I push version-22 out,=20 I=92ll consider if I should simply just use "iBGP peer" consistently=20 and avoid using "internal peer".=20 > - 5.2, I think you need to say something to the effect that every Secure_Path MUST have a signature with an algorithm that is supported. As I read the text, the algorithm as stated here could be read to not require that. E.g. the para before the bullets on p25 could be read to mean "drop all stuff involving unsupported algs and then continue to process the rest of the stuff." [Sriram] Seems like a bit of a pathological case.=20 Could happen only if the sender behavior was incorrect.=20 Sender is not required to know which algorithms a peer supports=20 but sender's expected behavior is this: MUST include a Signature_Block=20 for the "current" algorithm (which every BGPsec speaker=20 MUST support through the transition period),=20 and if the sender supports the "next" algorithm,=20 then it MUST include a Signature_Block for the "next" algorithm also. So the peer BGPsec receiver (who MUST support=20 at least the "current" algorithm) is not expected to be starved=20 of a Signature_Block it can work with. =20 > - section 7: WRT non-deterministic signature algorithms, I think it'd be useful to note here that all such algorithms require good random number generation on the signer's system and that failing in that respect can expose the signer's private key. IMO deterministic signature schemes are better for this reason but the need for a good RNG is I think a real operational issue worthy of note. [Sriram] I will include wording to cover this in Section 7 in version-22. Sriram = From nobody Thu Jan 5 06:22:34 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C00312954E; Thu, 5 Jan 2017 06:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=goL4hf39; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=q0sUVF3x 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 GmkBEhOIfB0w; Thu, 5 Jan 2017 06:22:30 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B7B1293F3; Thu, 5 Jan 2017 06:22:29 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4E7C620B77; Thu, 5 Jan 2017 09:22:29 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Thu, 05 Jan 2017 09:22:29 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=EirJYZ0QVGhTXp9 vd7Kg6dhmm84=; b=goL4hf39VxBAW3ch2CyP8RTOM91QwAdrv4v5tWqJEptwo1H ZuCZyTozCCrKvhWBFFLJqjXxIGxW4r4UybUoyQRPf82TrwtoTpaaDmSgLIqyKDT2 hx5F9oAd8wskjit6Jbhi3jZuiwV3RjwuBxtOIM2GiBmmWOg34E4ILotXBF1U= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=EirJYZ0QVGhTXp9vd7Kg6dhmm84=; b=q0sUVF3xC4OCgAVWwZWZ RepupgDvwZKDQt30qgfiOdOd5HWlhXzfm+flB9U+fiYJi2snobVauBcF1Ncy09MW 2pPNOjm4g0swwiMxxhQa7gTAZtPGNShZQNxA8THzmLgc49b70MxG4ERWZpHLT+T8 klFRwR2ildFvdOmFpB0SyA4= X-ME-Sender: X-Sasl-enc: idNP2hG5qUxFkvYxbp31ppcYvH+Mhaq/gOpk4/2rEfQq 1483626148 Received: from sjc-alcoop-8818.cisco.com (unknown [128.107.241.165]) by mail.messagingengine.com (Postfix) with ESMTPA id 7AB7E24077; Thu, 5 Jan 2017 09:22:28 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Thu, 5 Jan 2017 09:22:26 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <148354694377.12928.12337719277813930522.idtracker@ietfa.amsl.com> To: Randy Bush X-Mailer: Apple Mail (2.3124) Archived-At: Cc: The IESG , sidr@ietf.org Subject: Re: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 14:22:31 -0000 > On Jan 4, 2017, at 11:46 AM, Randy Bush wrote: > >> "Route Reflectors MUST have BGPsec enabled if and only if there are >> eBGP speakers in their client cone, i.e. an RR client or the >> transitive closure of a client's customers' customers' customers' >> etc." >> >> "MUST ... if and only if" is a strange construction. > > the syntax may be stressed but the semantics are correct. > >> I'm assuming what is meant here is that Route Reflectors MUST NOT >> enable BGPsec unless there are eBGP speakers in their client cone -- > > nope. if there are no bgpsec speakers in the client cone, the RRs MAY > still choose to validate. the point is that, if there are *any* bgpsec > speakers in the client cone, then you'll want them to receive signed > paths. hence the RRs would have to enable bgpsec signing. Ok, after reading it a few times I get it. > >> for a normative requirement I think it would be better to be specific >> rather than saying "etc." (e.g., "a client's customers or customers >> thereof" or something like that). > > how about tossing the extra words and going with > > i.e. an RR client or the transitive closure of a client's customers. Sounds good. > >> "Additionally, outsourcing verification is not prudent security >> practice." >> >> Isn't that part of the point of draft-ietf-sidr-rpki-rtr-rfc6810-bis >> though? I know this paragraph is not talking about that but since use >> of a trusted cache was mentioned in the protocol draft, this struck me >> as a slight discrepancy. > > 6810 sec 3 > > Local Caches: A local set of one or more collected and verified > caches. A relying party, e.g., router or other client, MUST have > a trust relationship with, and a trusted transport channel to, any > authoritative cache(s) it uses. > > contrast this with this document's > > BGPsec does not sign over communities, so they are not formally > trustable. Additionally, outsourcing verification is not prudent > security practice. Therefore an eBGP listener SHOULD NOT strongly > trust unsigned security signaling, such as communities, received > across a trust boundary. > > note that this document is advising not crossing a trust boundary > carrying data where integrity and authenticity are not protected, while > 6810 advises quite the opposite. Ok, fair enough. Alissa > > but if you want to stab me with outsourced security, have a look at > draft-ietf-sidr-origin-validation-signaling-10.txt. note that, while i > am a co-author, i raised my hum against adopting, progressing, ... it > was one of those rock and hard place things. > > randy From nobody Thu Jan 5 06:27:12 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B213C12956C; Thu, 5 Jan 2017 06:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 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, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham 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 JJOrVF2dW3EM; Thu, 5 Jan 2017 06:27:05 -0800 (PST) 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 2A918129568; Thu, 5 Jan 2017 06:27:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 945BBBE55; Thu, 5 Jan 2017 14:27:02 +0000 (GMT) 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 ZQxSZLLboTA4; Thu, 5 Jan 2017 14:27:01 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4096EBDF9; Thu, 5 Jan 2017 14:27:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483626420; bh=+hkSROEZbJUN7cR4NDymPzjAz7fbh/4HjPdin4TAk2M=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=H6vTaVZCFd7sN6W34TAMkvhHG+F8xlR5PKSOjkYHcAnT/8C6kQBhIrKKc92htnYVC Es0vvCVK269+Nm9lnxgCYUoBmfyx+YIIvInLeHP5rtnVi3oxeYlNc/nuySTDCfUqL1 9cPx2ZQUCvsCZRSPWgVoWmYkYQKYaXV+HFvgBQ0s= To: "Sriram, Kotikalapudi (Fed)" , The IESG References: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <304ad58d-fa44-45e3-6fb1-4e7b189007cd@cs.tcd.ie> Date: Thu, 5 Jan 2017 14:26:59 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010702050903010705030903" Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , "sidr-chairs@ietf.org" , "m.waehlisch@fu-berlin.de" , "sidr@ietf.org" Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 14:27:08 -0000 This is a cryptographically signed message in MIME format. --------------ms010702050903010705030903 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 05/01/17 14:10, Sriram, Kotikalapudi (Fed) wrote: > Stephen, >=20 > Thank you for the detailed review and comments. > Please see my responses marked with [Sriram] inline below. >=20 > [Sriram] Your DISCUSS points (1) and (3) were already > discussed /being discussed in separate threads. Yep, thanks. I need to check back to see how close we are to resolving those, but I had thought the ball wasn't in my court at the moment:-) I'm sure we'll sort 'em soon though. >=20 >> (2) Figure 8: It seems to me to be an error to omit the > signer's ASN from the signed data and only have that > included in the signer's certificate. Why is that intimate > level of binding to the RPKI desirable? There may well be > reasons but I'm not seeing 'em, and I am recalling that it > took a chunk of effort to make CMS less dependent on > X.509 for similar reasons (meaning identifying signers > exclusively via cert issuer and serial in that case). I > would expect that there could be demand to have some level > of independence between BGPsec and RPKI for at least > internal uses such as those noted in the spec already. >=20 > [Sriram] Signer's ASN is indeed included in the signed data. > In Figure 8, "Secure_Path Segment : N" corresponds > to the signing AS (current AS) and that is where the=20 > signer's ASN is included along with its pCount and Flags. Hmm. That's the target ASN of the previous signer though. I thought there were cases where they could differ? But if not, then you probably need to state that as a rule for checking signatures, is that there already? (Happy to check later, but don't have time right now.) One other thing below... >=20 >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >=20 >> - Figures 2 and 5 present the fields in different orders. > That seems like a bad idea. >=20 > [Sriram] Good catch. Already fixed in my editor copy of version-22.=20 >=20 >> - 3.2: The reference to the pki profile doc is not precise > enough, the string "key identifier" does not occur in that > draft - it's in RFC6487, 4.8.2.=20 >=20 > [Sriram] Again, a good catch. Already fixed in my editor copy of versio= n-22. =20 >=20 >> - 4.1, last para: is the distinction between an "internal > peer" and "iBGP peer" sufficiently clear to routing folk? > For me they sound similar but I assume it's ok. >=20 > [Sriram] I think it is well understood. But when I push version-22 out,= =20 > I=E2=80=99ll consider if I should simply just use "iBGP peer" consisten= tly=20 > and avoid using "internal peer".=20 >=20 >> - 5.2, I think you need to say something to the effect > that every Secure_Path MUST have a signature with an > algorithm that is supported. As I read the text, the > algorithm as stated here could be read to not require > that. E.g. the para before the bullets on p25 could be > read to mean "drop all stuff involving unsupported algs > and then continue to process the rest of the stuff." >=20 > [Sriram] Seems like a bit of a pathological case.=20 > Could happen only if the sender behavior was incorrect.=20 Yes, but 5.2 is verifier behaviour and out not assume a correct signer, so I do thing the alg presented here needs to cover such things. > Sender is not required to know which algorithms a peer supports=20 > but sender's expected behavior is this: MUST include a Signature_Block = > for the "current" algorithm (which every BGPsec speaker=20 > MUST support through the transition period),=20 Where does it say that the current/next thing applies to the entire world of BGPsec? I didn't read it that way as it happens, but rather that the current/next could involve different algorithms at different nodes at the same time. So e.g. I read it to be allowed that a migration from rsa/sha256 then to ecdsa then to eddsa could occur with some non-updated nodes still signing with rsa/sha256 whilst some shiny new nodes are doing ecdsa and eddsa and others are in between. I do agree that a global current/next pair of algs is nicer, if that is what's wanted. But I don't recall the text saying that. (Again happy to check later, but no time right now;-) Cheers, S. > and if the sender supports the "next" algorithm,=20 > then it MUST include a Signature_Block for the "next" algorithm also. > So the peer BGPsec receiver (who MUST support=20 > at least the "current" algorithm) is not expected to be starved=20 > of a Signature_Block it can work with. =20 >=20 >> - section 7: WRT non-deterministic signature algorithms, I > think it'd be useful to note here that all such algorithms > require good random number generation on the signer's > system and that failing in that respect can expose the > signer's private key. IMO deterministic signature schemes > are better for this reason but the need for a good RNG is > I think a real operational issue worthy of note. >=20 > [Sriram] I will include wording to cover this in Section 7 in version-2= 2. >=20 > Sriram=20 >=20 --------------ms010702050903010705030903 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDUx NDI2NTlaMC8GCSqGSIb3DQEJBDEiBCAHjn57WMyRldaEwcP8gfzmam3rER8NrTwdCyF9w+ML LjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQA+GifCgGcjRwlGht3SKDmq7dlaLDtlKmbqePcnBi4ieQFoYfhV9sdl j9BUCOyssfR3HTrHJWMSIBaqBDUBCezkx1dYOFbi513koctmx1tPFNl97sNr7iD6SdM0RnAg GJePA4nSyucwIdnM3lWkMktxLhqwvN7ST0XewpjiPDoFat0UlYmOCl3shLXK5pMgcjWsgngR ryB0J4Q8OgRcwx7cW961qYTxTAXux9Qt5Gf8ktzskHzagItYIdolmAztwl7ToMdsRRPYFfq/ av0/wstIge9V/L5CI+9UCXNAhrxpfDT5R4TMILc0RrLz7X7XmQbswygn3IxkDqPp0zMvTvCL AAAAAAAA --------------ms010702050903010705030903-- From nobody Thu Jan 5 06:32:03 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D1512956D; Thu, 5 Jan 2017 06:31:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148362671909.20702.5167377044454314977.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2017 06:31:59 -0800 Archived-At: Cc: draft-ietf-sidr-bgpsec-ops@ietf.org, morrowc@ops-netman.net, sidr-chairs@ietf.org, sidr@ietf.org, jiangsheng@huawei.com Subject: [sidr] Benoit Claise's No Objection on draft-ietf-sidr-bgpsec-ops-16: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 14:31:59 -0000 Benoit Claise has entered the following ballot position for draft-ietf-sidr-bgpsec-ops-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Happy to see an operational considerations document at the same time at the protocol specifications, even if we know that "It is expected to evolve as BGPsec is formalized and initially deployed." Thanks Randy Proposal: one extra section on migration/deployability There is text in draft-ietf-sidr-bgpsec-protocol-21 How will migration from BGP to BGPsec look like? What are the benefits for the first adopters? Initially small groups of contiguous ASes would be doing BGPsec. There would be possibly one or more such groups in different geographic regions of the global Internet. Only the routes originated within each group and propagated within its borders would get the benefits of cryptographic AS path protection. As BGPsec adoption grows, each group grows in size and eventually they join together to form even larger BGPsec capable groups of contiguous ASes. The benefit for early adopters starts with AS path security within the contiguous-AS regions spanned by their respective groups. Over time they would see those contiguous-AS regions grow much larger. From nobody Thu Jan 5 07:13:04 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD00129B53; Thu, 5 Jan 2017 07:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=Wsah31QP; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=PcC/TM1P 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 2oowypBMYKHc; Thu, 5 Jan 2017 07:12:59 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5E1129B4A; Thu, 5 Jan 2017 07:12:59 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 21DB020CF4; Thu, 5 Jan 2017 10:12:59 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 05 Jan 2017 10:12:59 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=9PtctHHKWnOHpBF2t63d+axT1I 8=; b=Wsah31QPBwga0+86xcdHE8vr4xPttsTB9VBFLDwfE9OM0kqPP6MlWacIqt 63+Z2JF3YGVeVRMSjdh1KW+QwN4c+0RIAwqYOWlh/bhVB4WP2tIFro4vSbChPj4T GQNDLV6A1xALnweDeok8TL3CyoKIx/1QxeVR7nhN2h+y/BVC8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=9P tctHHKWnOHpBF2t63d+axT1I8=; b=PcC/TM1PKUiH1Twp1WOaQQE4kZy8u+xyk4 EAhWxmR22f/J5qM3WWFujgo1n3kDg8fyX6p7QLr/iFuEO/1JdCSIS9IdIYcSHmBX dTKkUPBKDX4J+LCe75Js1aU85jrYZouLxFV2AyO0Aezx/LDlc9UWPes2Lwvzpf77 F2Y0Ylym4= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 056046ABED; Thu, 5 Jan 2017 10:12:58 -0500 (EST) Message-Id: <1483629178.1393702.838289753.6FA51C37@webmail.messagingengine.com> From: Alexey Melnikov To: sidr@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-8d3535ca In-Reply-To: <148355465867.12949.10785749487953700357.idtracker@ietfa.amsl.com> References: <148355465867.12949.10785749487953700357.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2017 15:12:58 +0000 Archived-At: Cc: sidr-chairs@ietf.org, draft-ietf-sidr-bgpsec-protocol@ietf.org, The IESG , m.waehlisch@fu-berlin.de Subject: Re: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-bgpsec-protocol-21=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 15:13:00 -0000 On Wed, Jan 4, 2017, at 06:30 PM, Mirja Kuehlewind wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-sidr-bgpsec-protocol-21: No Objection [...] > 1) Why do you need to send two different negotiation capabilities for > each direction instead of just using two flags in the same capability? > And similar why don't you just announce multiple address families in the > same capability (using variable length)?=20 This is a nit, but I was wondering about this myself. From nobody Thu Jan 5 07:26:57 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F52129B5F; Thu, 5 Jan 2017 07:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 agrvfWV9iv5e; Thu, 5 Jan 2017 07:26:56 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 39C7C12995C; Thu, 5 Jan 2017 07:26:56 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cP9wJ-000105-Br; Thu, 05 Jan 2017 15:26:51 +0000 Date: Fri, 06 Jan 2017 00:26:48 +0900 Message-ID: From: Randy Bush To: "Benoit Claise" In-Reply-To: <148362671909.20702.5167377044454314977.idtracker@ietfa.amsl.com> References: <148362671909.20702.5167377044454314977.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Sheng Jiang , The IESG , sidr wg list Subject: Re: [sidr] Benoit Claise's No Objection on draft-ietf-sidr-bgpsec-ops-16: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 15:26:57 -0000 > Proposal: one extra section on migration/deployability > There is text in draft-ietf-sidr-bgpsec-protocol-21 > > How will migration from BGP to BGPsec look like? What are the > benefits for the first adopters? Initially small groups of > contiguous ASes would be doing BGPsec. There would be possibly one > or more such groups in different geographic regions of the global > Internet. Only the routes originated within each group and > propagated within its borders would get the benefits of > cryptographic > AS path protection. As BGPsec adoption grows, each group grows in > size and eventually they join together to form even larger BGPsec > capable groups of contiguous ASes. The benefit for early adopters > starts with AS path security within the contiguous-AS regions > spanned > by their respective groups. Over time they would see those > contiguous-AS regions grow much larger. > > i see no merit in reproducing text from another document. i could refer to it, but i prefer to add 7. Routing Policy As BGPsec signed paths can not traverse non-BGPsec topology, partial BGPsec deployment forms islands of assured paths. As islands grow to touch each other, they become larger islands. randy From nobody Thu Jan 5 08:05:32 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DEF129B9A; Thu, 5 Jan 2017 08:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 zKW879FcaqiY; Thu, 5 Jan 2017 08:05:29 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 48AF2129B5D; Thu, 5 Jan 2017 08:05:23 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v05G5Ms6005292 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 5 Jan 2017 10:05:22 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Randy Bush" Date: Thu, 05 Jan 2017 10:05:21 -0600 Message-ID: <39D04FC6-BD42-4474-BEF5-9A3C370D7A1A@nostrum.com> In-Reply-To: References: <148348795694.28027.8646303758093237302.idtracker@ietfa.amsl.com> <661F8C18-7B04-4E88-A97A-BBA8314C3FD4@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: The IESG , sidr wg list Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 16:05:30 -0000 On 4 Jan 2017, at 19:29, Randy Bush wrote: > Sorry, I did not mean that stripping was suggested; the previous >> phrase (non-normatively) recommends against stripping. My question >> is, >> since the subject of the sentence is "signed paths" whether the "MUST >> be signed" language means "MUST NOT strip the signature" (which I >> suspect to be the case), or something else. > > > how about > > As the mildly stochastic timing of RPKI propagation may cause > version > skew across routers, an AS Path which does not validate at router > R0 > might validate at R1. Therefore, signed paths that are Not Valid > and > yet propagated (because they are chosen as best path) MUST NOT have > signatures stripped and MUST be signed if sent to external BGPsec > speakers. > > if not, use larger clue bat It's likely I have this particular bat by the wrong end. In the last sentence, does "MUST be signed" mean it must have a signature (which would seem to make "MUST NOT strip" and "MUST be signed" redundant), or does it mean the propagating router must add it's own signature in addition to the existing one(s)? Ben. From nobody Thu Jan 5 14:14:23 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A451295FA; Thu, 5 Jan 2017 14:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 3FqRR3JNlBCj; Thu, 5 Jan 2017 14:14:20 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 A9B31129686; Thu, 5 Jan 2017 14:14:20 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cPGIa-00036N-Pb; Thu, 05 Jan 2017 22:14:17 +0000 Date: Fri, 06 Jan 2017 07:14:14 +0900 Message-ID: From: Randy Bush To: "Ben Campbell" In-Reply-To: <39D04FC6-BD42-4474-BEF5-9A3C370D7A1A@nostrum.com> References: <148348795694.28027.8646303758093237302.idtracker@ietfa.amsl.com> <661F8C18-7B04-4E88-A97A-BBA8314C3FD4@nostrum.com> <39D04FC6-BD42-4474-BEF5-9A3C370D7A1A@nostrum.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: The IESG , sidr wg list Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 22:14:22 -0000 >> Sorry, I did not mean that stripping was suggested; the previous >>> phrase (non-normatively) recommends against stripping. My question >>> is, since the subject of the sentence is "signed paths" whether the >>> "MUST be signed" language means "MUST NOT strip the signature" >>> (which I suspect to be the case), or something else. >> >> how about >> >> As the mildly stochastic timing of RPKI propagation may cause >> version skew across routers, an AS Path which does not validate at >> router R0 might validate at R1. Therefore, signed paths that are >> Not Valid and yet propagated (because they are chosen as best >> path) MUST NOT have signatures stripped and MUST be signed if sent >> to external BGPsec speakers. >> >> if not, use larger clue bat > > It's likely I have this particular bat by the wrong end. > > In the last sentence, does "MUST be signed" mean it must have a > signature (which would seem to make "MUST NOT strip" and "MUST be > signed" redundant), or does it mean the propagating router must add > it's own signature in addition to the existing one(s)? yes, it must preserve the signed path and add its own signature. randy From nobody Thu Jan 5 14:18:12 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585D7129420; Thu, 5 Jan 2017 14:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 xoJD-L025IPG; Thu, 5 Jan 2017 14:18:10 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 47F6D129406; Thu, 5 Jan 2017 14:18:10 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v05MI96A044578 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 5 Jan 2017 16:18:09 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Randy Bush" Date: Thu, 05 Jan 2017 16:18:08 -0600 Message-ID: In-Reply-To: References: <148348795694.28027.8646303758093237302.idtracker@ietfa.amsl.com> <661F8C18-7B04-4E88-A97A-BBA8314C3FD4@nostrum.com> <39D04FC6-BD42-4474-BEF5-9A3C370D7A1A@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: The IESG , sidr wg list Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 22:18:11 -0000 On 5 Jan 2017, at 16:14, Randy Bush wrote: >>> Sorry, I did not mean that stripping was suggested; the previous >>>> phrase (non-normatively) recommends against stripping. My question >>>> is, since the subject of the sentence is "signed paths" whether the >>>> "MUST be signed" language means "MUST NOT strip the signature" >>>> (which I suspect to be the case), or something else. >>> >>> how about >>> >>> As the mildly stochastic timing of RPKI propagation may cause >>> version skew across routers, an AS Path which does not validate >>> at >>> router R0 might validate at R1. Therefore, signed paths that are >>> Not Valid and yet propagated (because they are chosen as best >>> path) MUST NOT have signatures stripped and MUST be signed if >>> sent >>> to external BGPsec speakers. >>> >>> if not, use larger clue bat >> >> It's likely I have this particular bat by the wrong end. >> >> In the last sentence, does "MUST be signed" mean it must have a >> signature (which would seem to make "MUST NOT strip" and "MUST be >> signed" redundant), or does it mean the propagating router must add >> it's own signature in addition to the existing one(s)? > > yes, it must preserve the signed path and add its own signature. Thanks, that helps. Would it make the last sentence say something to the effect of "... and MUST additionally be signed by the propagating router."? Ben. From nobody Thu Jan 5 14:24:35 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E231296D4; Thu, 5 Jan 2017 14:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 5QS1sNwNTXnl; Thu, 5 Jan 2017 14:24:29 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 B2BCF1296D3; Thu, 5 Jan 2017 14:24:29 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cPGSS-00039z-Kt; Thu, 05 Jan 2017 22:24:28 +0000 Date: Fri, 06 Jan 2017 07:24:27 +0900 Message-ID: From: Randy Bush To: "Ben Campbell" In-Reply-To: References: <148348795694.28027.8646303758093237302.idtracker@ietfa.amsl.com> <661F8C18-7B04-4E88-A97A-BBA8314C3FD4@nostrum.com> <39D04FC6-BD42-4474-BEF5-9A3C370D7A1A@nostrum.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: The IESG , sidr wg list Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 22:24:31 -0000 > Thanks, that helps. Would it make the last sentence say something to > the effect of "... and MUST additionally be signed by the propagating > router."? alvaro has asked me to stop editing randy From nobody Thu Jan 5 14:40:14 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDA2129993; Thu, 5 Jan 2017 14:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 2ixZR6q9pS82; Thu, 5 Jan 2017 14:40:08 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 CEAC612998F; Thu, 5 Jan 2017 14:40:08 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v05Me7bf047268 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 5 Jan 2017 16:40:08 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Randy Bush" Date: Thu, 05 Jan 2017 16:40:07 -0600 Message-ID: In-Reply-To: References: <148348795694.28027.8646303758093237302.idtracker@ietfa.amsl.com> <661F8C18-7B04-4E88-A97A-BBA8314C3FD4@nostrum.com> <39D04FC6-BD42-4474-BEF5-9A3C370D7A1A@nostrum.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: The IESG , sidr wg list Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 22:40:10 -0000 On 5 Jan 2017, at 16:24, Randy Bush wrote: >> Thanks, that helps. Would it make the last sentence say something to >> the effect of "... and MUST additionally be signed by the propagating >> router."? > > alvaro has asked me to stop editing > > randy Understood :-) From nobody Thu Jan 5 14:55:08 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C367C1296DD; Thu, 5 Jan 2017 14:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 9u0kpL-pcW9q; Thu, 5 Jan 2017 14:55:07 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 F070412966E; Thu, 5 Jan 2017 14:55:06 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cPGvs-0003F8-PB; Thu, 05 Jan 2017 22:54:53 +0000 Date: Fri, 06 Jan 2017 07:54:49 +0900 Message-ID: From: Randy Bush To: Keyur Patel In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Routing Directorate , Zhangxian Xian , Routing ADs , sidr , Jonathan Hardwick , Jon Hudson Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 22:55:08 -0000 did i miss the response to this? i think some of the points are important. randy From nobody Thu Jan 5 21:40:21 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BFB1294A7; Thu, 5 Jan 2017 21:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 GJZBVrVPzHcg; Thu, 5 Jan 2017 21:40:13 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0137.outbound.protection.outlook.com [23.103.200.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E732E127058; Thu, 5 Jan 2017 21:40:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8xSJcndiQbpppEVBnmC71mgA+GwsLjwuitbDLWrK8eo=; b=c8tJsFgKtwTJeukspNLFSw9ig30QlnlMeyidk3aNJwDcO8AHeyjxckvq7O2Z7RkFvqpRL+SGMUsN0dLiFkSr6AGA0aP+bsPiJM048pkwRaDL3OR+EzYGI31pobKnUYXbemIJTZJo2StW7KDqiOwYOUOrs6nYwtwIGMS287t6a/o= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Fri, 6 Jan 2017 05:40:10 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0817.012; Fri, 6 Jan 2017 05:40:10 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Keyur Patel , Jonathan Hardwick , "Alvaro Retana (aretana)" , Zhangxian Xian , Jon Hudson Thread-Topic: draft-ietf-sidr-bgpsec-protocol Thread-Index: AQHSZthkNfH8MXPYLkOmxwl9coeqv6EoZskAgAKH0dQ= Date: Fri, 6 Jan 2017 05:40:09 +0000 Message-ID: References: , In-Reply-To: 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=kotikalapudi.sriram@nist.gov; x-originating-ip: [71.191.56.66] x-ms-office365-filtering-correlation-id: 166ab968-80e2-4ba3-d405-08d435f67a92 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0446; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 7:oVVnRw8o6v3BFzgA7nhIrCydJ+z/fqjuKdHTNvOcJsiVEGtGV5s5kky4Qu7Jhuz88GKbbXrvMSPIu9aJJqNjl50XlV6Y//y/8eyib+qeEfVA7YyZqRV/GW7siRwuN8Eu7h6qYQLHryn3lDK7OiTHoVOCbFV3eoCYy6dFxDSOZ3xkNb3vXyrRo8ATCXb3msA9AzOp0DS5ax0O6eSBrYFZUOCicXUfwgtgv8ckTv7y2FsY3Bn9ch1XU7lA8P0o6bJsdloDB7WCowgmEN/MCkyvXVeigshe5gdQcpolfhyKMTrh/g5+BhqBA33aYfW9SAj0GrDUzipsyx3j0IgN5hE5yJKIlj4StGgAajuAi5lKcEqknU96LkwAKJEcFObG9sVoI5fBCCTP9hur8XXmlCEMJCuOTrbc1E+kUd+SpofEwBzsFCC16OiW187U1ih9YQa54fGdZfIPNRQ1KU4Oblf+PQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(20161123558021)(20161123562025)(20161123560025)(6072148); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446; x-forefront-prvs: 01792087B6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39850400002)(39410400002)(39860400002)(39450400003)(199003)(377454003)(189002)(7416002)(305945005)(106116001)(33656002)(66066001)(92566002)(55016002)(99286003)(50986999)(38730400001)(54356999)(6436002)(76176999)(74316002)(68736007)(25786008)(81166006)(81156014)(3660700001)(7696004)(2950100002)(106356001)(8676002)(8936002)(9686002)(5660300001)(122556002)(77096006)(229853002)(230783001)(2906002)(86362001)(39060400001)(6506006)(5890100001)(102836003)(101416001)(189998001)(5001770100001)(345774005)(97736004)(4326007)(54906002)(3846002)(3280700002)(2900100001)(6116002)(7736002)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2017 05:40:09.8650 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0446 Archived-At: Cc: Routing Directorate , "sidr-chairs@ietf.org" , Routing ADs , "mlepinski@ncf.edu" , sidr Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 05:40:15 -0000 Keyur, Thank you for taking the time to read and offer comments.=20 I find the comments very insightful and helpful.=20 My comments are marked with [Sriram] below. >From: Keyur Patel keyur@arrcus.com >Sent: Wednesday, January 4, 2017 5:53 PM >The document is well written, easy to read and follow. =20 >Some minor comments are listed below: >1) Section 4.1 =93The BGPsec Path attribute and the AS_PATH attribute are= mutually exclusive. That is, any update message containing the BGPsec Path= attribute MUST NOT contain the AS_PATH attribute=94. For any restarting s= peakers in a GR mode, where the bgp capability is not exchanged, the existi= ng stale routes won=92t have an AS_PATH attribute. We could add some clarif= ying that helps to indicate that such routes should be considered valid in = stale mode (till they get refreshed)? [Sriram] As you have clarified for me on the phone, what you are saying he= re is that the two BGPsec peers lost the BGPsec session and now restarting = in GR mode, but they have not exchanged BGPsec capability this time. Hence,= they are now simple BGP (non-BGPsec) peers in GR mode. RFC4271 considers u= pdate message received without a well-known AS_PATH attribute as an error, = and unfortunately in this case the cached BGPsec updates do not have AS_PAT= H (albeit they have BGPsec_Path). So you are saying "the router should not = panic" and instead simply treat each cached update as NOT-IN-ERROR even tho= ugh it is missing AS_PATH attribute. This way the GR can work properly. Of = course, shortly the updates will have AS_PATH (and not considered in error)= when they get refreshed (over the new simple BGP session). Per your sugges= tion, I will include new text in Section 7 to describe this required behavi= or for the GR mode. =20 >2) 4.1 4th paragraph: "Note also that new signatures are only added to a= BGPsec update message when a BGPsec speaker is generating an update messag= e to send to an external peer (i.e., when the AS number of the peer is not = equal to the BGPsec speaker's own AS number). Therefore, a BGPsec speaker = who only sends BGPsec update messages to peers within its own AS does not n= eed to possess any private signature keys." This text doesn't seem to apply= to confed peers? If so, it would be nice to clarify that this text doesn't= apply to any confed peers. [Sriram] You have clarified in our phone conversation that you consider the= inter-AS-member sessions as "iBGP" since they are all within a confederati= on AS domain. The BGPsec document considers the inter-AS-member sessions as= "eBGP" (not "iBGP") and intra-Member-AS sessions as "iBGP". You also clar= ified that you may call inter-AS-member sessions as "confederation-eBGP" se= ssions. Obviously, private key is required to sign over such "confederation= -eBGP/BGPsec" sessions. I understand your point. I will put in new text (no= tes) to clarify this in the document. >3) Section 5 and Section 5.2, 1st paragraph: RFC4271 considers update mes= sage received without a well-known AS_PATH attribute as an error. We need = some text to clarify the (error handling if any) behavior when an update me= ssage is received without a bgpsec and an aspath attribute. The current dra= ft text seems unclear about generation of bgpsec attribute as well (in a ib= gp scenario). Is it a requirement to generate an empty bgpsec attribute? [Sriram] As you have clarified for me over the phone, RFC 4271 (page 26) s= ays the following : "When a BGP speaker originates a route then: b) the originating speaker includes an empty AS_PATH attribute in all UPDATE messages sent to internal peers. (An empty AS_PATH attribute is one whose length field contains the value zero)." [Sriram] So what needs to be said in the BGPsec document is the following:= The BGPsec_Path attribute is not attached in updates originated inside an= AS and propagated to BGPsec capable internal peers. However, when a route = is originated inside an AS and propagated to non-BGPsec internal peers, an = empty AS_PATH attribute is included in the update (see [RFC 4271], page 26)= . >4) With an AS_PATH attribute in 4271 there was loop detection in place. = With BGPSec I don=92t see that being called explicitly other than a passin= g remark in section 5. Section 5.2 should have a check that allows a BGPsec= speaker to bail out of a validation procedure when a aspath loop is detect= ed. [Sriram] I agree. I will include loop detection in the list of error check= s in Section 5.2. Sriram From nobody Fri Jan 6 08:28:01 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9B7129B53; Fri, 6 Jan 2017 08:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 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_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 BgWziWx9xdIH; Fri, 6 Jan 2017 08:27:52 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0139.outbound.protection.outlook.com [23.103.200.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A478F1294C1; Fri, 6 Jan 2017 08:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SVgxYUxQ22CEkRILHJAqFeeMYF4fOx/bqk4vTfiTPew=; b=VWn7JGQcI5zwce3dq7qHHRwOGmXOPV8+pDuEG2hVac2d4e7XHzv1oRo5akl27xsBaXJeZToHVDx+d2sHsIU7JDwMS/0W2dv7RZ0TmVE7C00vvGijI4Vm6/1wPZi0wu+RygQUi4agR9tSrHgKsqwtm4TeLrOBOYj9GYZsa07tmy0= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Fri, 6 Jan 2017 16:27:50 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0817.012; Fri, 6 Jan 2017 16:27:50 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Keyur Patel , Jonathan Hardwick , "Alvaro Retana (aretana)" , Zhangxian Xian , Jon Hudson Thread-Topic: draft-ietf-sidr-bgpsec-protocol Thread-Index: AQHSZthkNfH8MXPYLkOmxwl9coeqv6EoZskAgAKH0dSAALXTbQ== Date: Fri, 6 Jan 2017 16:27:50 +0000 Message-ID: References: , , In-Reply-To: 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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.219.212] x-ms-office365-filtering-correlation-id: c8908edd-f6dc-4f0f-8693-08d43650f56f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0446; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 7:p0SLu568n6s12wrXMtgG6OLMDXqlmSiNN1lzywdpQnMVCD3S570Oibn1o6guqfergxgMmEIdJ+0BqpCtTssWO2FdDOG+3qmGjO/R4pON0ycL3zfFL9wf//FD2uBLytWQC33pFdD09dzk9Z5vSkHkKwMFmDtpAILbinsORIyDVAdOFiLnui5yJIcY1F9HF2hQUWUPJ1ErbZIu4BR6pZRxu9jozfl5DsiPEeXjbeBG+APR1AdrLG1P/YfuXUk98Kcg/zwZ2HwCURinmRdyXn4BzT8uUt3YIWIKP2YYv5yB1wNPrRFElFw1td9wlwULPTBd3sLdqYyfJCw/TdpIUargLya/h6OlNFtPkSWYO4ehnnb1ZZKlEu/HAOyk4nGBwXzcch0E7fPx3Gu0UaAEwmaWSpmeKsCDK7A69mL+PO6/wroKHbv+QAKtZstCaWC49n7t3TPSpmK+7oUyUWJFAuIOrw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(20161123558021)(20161123562025)(20161123560025)(6072148); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446; x-forefront-prvs: 01792087B6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39450400003)(39410400002)(39840400002)(39850400002)(377454003)(189002)(199003)(102836003)(6506006)(5890100001)(54896002)(230783001)(101416001)(122556002)(86362001)(2906002)(229853002)(77096006)(39060400001)(2900100001)(19627405001)(3846002)(3280700002)(105586002)(6116002)(7736002)(345774005)(5001770100001)(4326007)(54906002)(189998001)(97736004)(5660300001)(99286003)(92566002)(33656002)(55016002)(66066001)(7416002)(106116001)(81166006)(7696004)(3660700001)(25786008)(74316002)(81156014)(68736007)(2950100002)(8936002)(6606003)(106356001)(9686002)(8676002)(6436002)(54356999)(76176999)(50986999)(38730400001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB04460F8436EDBEA289420ED284630DM2PR09MB0446namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2017 16:27:50.7711 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0446 Archived-At: Cc: sidr , Routing Directorate , "sidr-chairs@ietf.org" , "mlepinski@ncf.edu" , Routing ADs Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 16:27:55 -0000 --_000_DM2PR09MB04460F8436EDBEA289420ED284630DM2PR09MB0446namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable My previous post of this message seems to have line wrap issue. Resending ... hopefully this avoids that issue. - Sriram ------------------- Keyur, Thank you for taking the time to read and offer comments. I find the comments very insightful and helpful. My comments are marked with [Sriram] below. >From: Keyur Patel keyur@arrcus.com >Sent: Wednesday, January 4, 2017 5:53 PM >The document is well written, easy to read and follow. >Some minor comments are listed below: >1) Section 4.1 =93The BGPsec Path attribute and the AS_PATH attribute are= mutually exclusive. That is, any update message containing the BGPsec Path= attribute MUST NOT contain the AS_PATH attribute=94. For any restarting s= peakers in a GR mode, where the bgp capability is not exchanged, the existi= ng stale routes won=92t have an AS_PATH attribute. We could add some clarif= ying that helps to indicate that such routes should be considered valid in = stale mode (till they get refreshed)? [Sriram] As you have clarified for me on the phone, what you are saying he= re is that the two BGPsec peers lost the BGPsec session and now restarting = in GR mode, but they have not exchanged BGPsec capability this time. Hence,= they are now simple BGP (non-BGPsec) peers in GR mode. RFC4271 considers u= pdate message received without a well-known AS_PATH attribute as an error, = and unfortunately in this case the cached BGPsec updates do not have AS_PAT= H (albeit they have BGPsec_Path). So you are saying "the router should not = panic" and instead simply treat each cached update as NOT-IN-ERROR even tho= ugh it is missing AS_PATH attribute. This way the GR can work properly. Of = course, shortly the updates will have AS_PATH (and not considered in error)= when they get refreshed (over the new simple BGP session). Per your sugges= tion, I will include new text in Section 7 to describe this required behavi= or for the GR mode. >2) 4.1 4th paragraph: "Note also that new signatures are only added to a= BGPsec update message when a BGPsec speaker is generating an update messag= e to send to an external peer (i.e., when the AS number of the peer is not = equal to the BGPsec speaker's own AS number). Therefore, a BGPsec speaker = who only sends BGPsec update messages to peers within its own AS does not n= eed to possess any private signature keys." This text doesn't seem to apply= to confed peers? If so, it would be nice to clarify that this text doesn't= apply to any confed peers. [Sriram] You have clarified in our phone conversation that you consider the= inter-AS-member sessions as "iBGP" since they are all within a confederati= on AS domain. The BGPsec document considers the inter-AS-member sessions as= "eBGP" (not "iBGP") and intra-Member-AS sessions as "iBGP". You also clar= ified that you may call inter-AS-member sessions as "confederation-eBGP" se= ssions. Obviously, private key is required to sign over such "confederation= -eBGP/BGPsec" sessions. I understand your point. I will put in new text (no= tes) to clarify this in the document. >3) Section 5 and Section 5.2, 1st paragraph: RFC4271 considers update mes= sage received without a well-known AS_PATH attribute as an error. We need = some text to clarify the (error handling if any) behavior when an update me= ssage is received without a bgpsec and an aspath attribute. The current dra= ft text seems unclear about generation of bgpsec attribute as well (in a ib= gp scenario). Is it a requirement to generate an empty bgpsec attribute? [Sriram] As you have clarified for me over the phone, RFC 4271 (page 26) s= ays the following : "When a BGP speaker originates a route then: b) the originating speaker includes an empty AS_PATH attribute in all UPDATE messages sent to internal peers. (An empty AS_PATH attribute is one whose length field contains the value zero)." [Sriram] So what needs to be said in the BGPsec document is the following:= The BGPsec_Path attribute is not attached in updates originated inside an= AS and propagated to BGPsec capable internal peers. However, when a route = is originated inside an AS and propagated to non-BGPsec internal peers, an = empty AS_PATH attribute is included in the update (see [RFC 4271], page 26)= . >4) With an AS_PATH attribute in 4271 there was loop detection in place. = With BGPSec I don=92t see that being called explicitly other than a passin= g remark in section 5. Section 5.2 should have a check that allows a BGPsec= speaker to bail out of a validation procedure when a aspath loop is detect= ed. [Sriram] I agree. I will include loop detection in the list of error check= s in Section 5.2. Sriram --_000_DM2PR09MB04460F8436EDBEA289420ED284630DM2PR09MB0446namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

My previous post of this message seems to have line wrap issue.

Resending ... hopefully this avoids that issue.   - Sriram

-------------------


Keyur,

Thank you for taking the time to read and offer comments.

I find the comments very insightful and helpful.

My comments are marked with [Sriram] below.

>From: Keyur Patel keyur@arrcus.com

>Sent: Wednesday, January 4, 2017 5:53 PM

>The document is well written, easy to read and follow.

>Some minor comments are listed below:

>1)  Section 4.1 =93The BGPsec Path attribute and the AS_PATH at= tribute are mutually exclusive. That is, any update message containing the = BGPsec Path attribute MUST NOT contain the AS_PATH attribute=94.  For = any restarting speakers in a GR mode, where the bgp capability is not exchanged, the existing stale routes won=92t have an AS_= PATH attribute. We could add some clarifying that helps to indicate that su= ch routes should be considered valid in stale mode (till they get refreshed= )?

[Sriram]  As you have clarified for me on the phone, what you are s= aying here is that the two BGPsec peers lost the BGPsec session and now res= tarting in GR mode, but they have not exchanged BGPsec capability this time= . Hence, they are now simple BGP (non-BGPsec) peers in GR mode. RFC4271 considers update message received without a well= -known AS_PATH attribute as an error, and unfortunately in this case the ca= ched BGPsec updates do not have AS_PATH (albeit they have BGPsec_Path). So = you are saying "the router should not panic" and instead simply treat each cached update as NOT-IN-ERRO= R even though it is missing AS_PATH attribute. This way the GR can work pro= perly. Of course, shortly the updates will have AS_PATH (and not considered= in error) when they get refreshed (over the new simple BGP session). Per your suggestion, I will include new text = in Section 7 to describe this required behavior for the GR mode.

>2)   4.1 4th paragraph: "Note also that new signature= s are only added to a BGPsec update message when a BGPsec speaker is genera= ting an update message to send to an external peer (i.e., when the AS numbe= r of the peer is not equal to the BGPsec speaker's own AS number).  Therefore, a BGPsec speaker who only sends BGPsec up= date messages to peers within its own AS does not need to possess any priva= te signature keys." This text doesn't seem to apply to confed peers? I= f so, it would be nice to clarify that this text doesn't apply to any confed peers.

[Sriram] You have clarified in our phone conversation that you consider = the inter-AS-member sessions as "iBGP" since they are all within = a confederation AS domain. The BGPsec document considers the inter-AS-membe= r sessions as "eBGP" (not "iBGP") and intra-Member-AS sessions as "iBGP".  You also clarified that you may call i= nter-AS-member sessions as "confederation-eBGP" sessions. Obvious= ly, private key is required to sign over such "confederation-eBGP/BGPs= ec" sessions. I understand your point. I will put in new text (notes) to clarify this in the document.

>3)  Section 5 and Section 5.2, 1st paragraph: RFC4271 considers= update message received without a well-known AS_PATH attribute as an error= .  We need some text to clarify the (error handling if any) behavior w= hen an update message is received without a bgpsec and an aspath attribute. The current draft text seems unclear about genera= tion of bgpsec attribute as well (in a ibgp scenario). Is it a requirement = to generate an empty bgpsec attribute?

[Sriram]  As you have clarified for me over the phone, RFC 4271 (pa= ge 26) says the following :

   "When a BGP speaker originates a route then:

   b) the originating speaker includes an empty AS_PATH attrib= ute in

         all UPDATE messages sen= t to internal peers.  (An empty AS_PATH

         attribute is one whose = length field contains the value zero)."

[Sriram]  So what needs to be said in the BGPsec document is the fo= llowing:  The BGPsec_Path attribute is not attached in updates origina= ted inside an AS and propagated to BGPsec capable internal peers. However, = when a route is originated inside an AS and propagated to non-BGPsec internal peers, an empty AS_PATH attribute is inc= luded in the update (see [RFC 4271], page 26).

>4)   With an AS_PATH attribute in 4271 there was loop dete= ction in place.  With BGPSec I don=92t see that being called explicitl= y other than a passing remark in section 5. Section 5.2 should have a check= that allows a BGPsec speaker to bail out of a validation procedure when a aspath loop is detected.

[Sriram]  I agree. I will include loop detection in the list of err= or checks in Section 5.2.

Sriram

--_000_DM2PR09MB04460F8436EDBEA289420ED284630DM2PR09MB0446namp_-- From nobody Fri Jan 6 09:20:13 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D842D129D14; Fri, 6 Jan 2017 09:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 nIB871_YAZUf; Fri, 6 Jan 2017 09:20:03 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30132.outbound.protection.outlook.com [40.107.3.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6D7129D18; Fri, 6 Jan 2017 09:20:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=I5Cm6kLp89MLtzkcCio139fFRI6UnhZowFQH5zO4gPo=; b=OO9m+ZFv56S8wapBtzU977j+UTUGCTdPZBaT+6YuvAumtfZFHSwjSWgWOuV+jyHt58ld98ZOthFY1As+gKHPU1oPDMNVXy4x+zDxVDJ6o3RpY1VWTHJfbBbaGR9geFZs/ja9sW1IF1Z3IBlGaVTaWkusGB6mrR7JQyTw+GPjjOA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.135.210.62) by DB6PR0701MB2998.eurprd07.prod.outlook.com (10.168.84.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.4; Fri, 6 Jan 2017 17:20:00 +0000 Message-ID: <00a001d26840$e5194580$4001a8c0@gateway.2wire.net> From: t.petch To: Rob Austein References: <148226796672.23778.11324483834700038816.idtracker@ietfa.amsl.com> <01f101d260f9$dee15c00$4001a8c0@gateway.2wire.net> <20161229231547.4552D456B7F2@minas-ithil.hactrn.net> Date: Fri, 6 Jan 2017 17:15:04 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.135.210.62] X-ClientProxiedBy: DB6P195CA0007.EURP195.PROD.OUTLOOK.COM (10.171.120.145) To DB6PR0701MB2998.eurprd07.prod.outlook.com (10.168.84.136) X-MS-Office365-Filtering-Correlation-Id: 5daf1bc9-6b1e-4318-7b06-08d436583f04 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:DB6PR0701MB2998; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2998; 3:w/n1/hA1NidDYO5nX5JgKjndzi73FdzyfWgTBkBwRrMnSTncclfRd0Kish+px0WvfqJ5L1TIQkDr1j1R4l7MtmHYVWcX966jQrOVdbCo+JpFTMQLhSC3pwMBGe1msSBHeQ6SaSapgrYgIq2m5FVOwtICdaKht+fhfETpbFNF18kMszboN+O18YjyuwdbChfKsJbONJKjWLz3afFNqKfuuYbUmhhtxL4a1cG/LYgSmU5KapQCOfip6W4+psvjeITEOBxrXQKllxWUgP21GOaqpw== X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2998; 25:RIx/ITkFcW6XDfNT/BHfmdIJUDvoUbsyrT4nXqKbdVHM6ZPjY1rNG1dE/nqSAWh3YiaaKYS7XidRLk8fr+hDQoSCvF6+q8NPxrpsvEadwhfdk5nT9YDLFR0JxkY9W1PV1Zn5n62GAd8uXeRLwUcspKG2QM3P7lhxgg+2oznSc+BE4kMBiQsWKzIUp9zLi8oYlpb/UsCbh8BduXfOLdRZQwQohDg0gW2wD6uezhyvsv7gLyzxpgiQQkQ94KUybfHA4k5J1EOYl0J4/emJWj9DrPavDSoHRYYVrVkkgctECOnCCutMetm5Cxj0Uj3l0h6OjltUvvvWlhRzVxVA52BcrpVLVYlFPv9XnxNkqpF4G++uL9G6ypt/zOFjegy8P3ErrF4fnXnkYJzj8BpOXa+1GwF+xQ1QIIgrvBoWG9MDtjEHJDp/1X4R3sM9Y4584lnJ3Ux61zfzdmKkqImSv9ohdS0jnDu6iZXPg+O20v1sMr1vn5gWyFhL07rMOl2KKgJYb4yjwGkk4Dh33XI7W/21U2no6Kehn3gQtXI8rYmwCk8Z2RgMEiFg2wVHPghUPEJnBk6jShioGCRqrY+fuYVeuU+LOMZZgyQ/IbIijNkoT3vNTCm6l6b/17vB6AgiyZgENui1JlBvipbafgSx3JVPTQAk6a461Hl2Kg5NioyIhKk8IPhiisrN7WGM40Tm2ob1M+6/8Q7csYxuxLv2v4EXZxD/WfEGILKgvLylXkNRJHkN12AdreJcX3NCJ7NsObPzZmHJpxg9/gLE4KcAU9MSjmC3Mzvvezp8CsEe19IZqQpGn8AzzzXr3qwVU/q0BL9FxMBQS1sYCO8hD+SdNS1edLiQvJM5yMuqhMu9PH0Dgb4If7kONVS7uBFQwVtXHCAA X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2998; 31:jaJbI86InA1UmRB091GtTl72B4sL+RBtIvcjzfaEy9k+LaY132A32jx3bfeX6IsyXmavtXWM01+EIZpHN4fOwj+eyCiwL5iqJtKIo3aKKynF5Rw4N1foUhCpH0vkSbg6iBKjpW3R1xqQOkeYDFubn8xXpYqkacklewUo8lv1v14OrWvoEn9Tiy/Sf6qibyXzH7p72L4hseZgFilVtBiKfdaWJqtni5w0EGugKjLX42vpAmVrTjyPG/4OqdYVDiuzzSGmZubHeRQbgvigHrI94g==; 4:jV3S6nU0/lyFypnbNzeOL1cAynFE4ps5+xSk0rs7WoptheJJOESjjWQwUHyi+OxcJLAGJkoJbYFdLCuH6BN+JX+zJCo98ucJtFv0dit+i8jUipCJWRcIBEn98jpRtgzJ7rK/7aAg5ji9/P5S1ftjz1FCH1gg45XxrmZvG4UsZkICfu/Flk3ZUs3gzuLs9v+nE7Uv2YU05GPPH4hxsi39W7dXAvrMEIgsf6e8pwsOzYdOYr7DKatv51Dko1C+ign2Bwrt1/ypdK0FVkq32SkDkKJm2gyMe2Zo3bU0TjKC+AU1H24EUfJNLXqSp8MBnUCwzqckH/aOhl40YBOL3CJkALVvNYQnx+SSNhWvJm6c94d3JVbOEJzgNsLTFrpWVagL/rhOYkhsqBPaatT3VXf8Q6lpNgDVtRZxRG9a/bvu6vFLgaZu319wEI19Dgg/FFh2k3kQsINgFnhJsu8eU5ap6+9cDiQWNlmFsPmIKYt9h3sI7jjnZghV72x98/SEBqhWyTsZzalNXiyDcIYbjESv9cIM4ULAtWhEIgNMnN3yOOPGmlxa2YY5Jt369GtM3Ncs8HjtV49zIb2e4GvQjB+Hzf+9g5sUroSEBvsx9L8wRJOCG3RmpFzSDV6YW3yo61MW X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:DB6PR0701MB2998; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2998; X-Forefront-PRVS: 01792087B6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(39450400003)(24454002)(51914003)(13464003)(189002)(377454003)(199003)(4720700003)(110136003)(68736007)(106356001)(33646002)(23756003)(230783001)(116806002)(6486002)(38730400001)(81686999)(81156014)(81816999)(6916009)(81166006)(1556002)(50986999)(230700001)(6496003)(50226002)(76176999)(5660300001)(14496001)(189998001)(9686003)(25786008)(229853002)(8676002)(84392002)(44736005)(86362001)(54906002)(97736004)(305945005)(4326007)(2906002)(61296003)(92566002)(7736002)(42186005)(105586002)(6306002)(44716002)(62236002)(3846002)(47776003)(50466002)(1456003)(6116002)(101416001)(66066001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2998; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB2998; 23:AcRK1nT3Bj6FniKQBoc+Xn7pFv+UOjtZQMqbK?= =?iso-8859-1?Q?+AVyIA9mnHb2Rbwz+o0HTmO/rP1lpzivJl3krt+xHcWVFFxn3W2uDSsLhZ?= =?iso-8859-1?Q?i5EQ48bP99wWEi5VQtsRyiLFO5DrjMVR+9BEC350wd/5d/Jelnbju/Nyih?= =?iso-8859-1?Q?+yY+HbFMmKynScd6bBwwv1FziEHmbmwVQ/ZI33DW2a0LokOONE4l+fN2tX?= =?iso-8859-1?Q?aaUB+WvfnEUGAdAjO0I/zwZGVBQmpB9RKjWPXmlkYQdXN26opw+p0ADu2B?= =?iso-8859-1?Q?ezCVBErqmiSbRQ64I+HFAXT6P/k7pjIznBVR0ZRLoE/cTNSvYaAnDMAiir?= =?iso-8859-1?Q?WeEukxO2JNyIXnUDyo2PxS+BYVtwEcOggyzNNljSF+U9gFDZjvTgn008fu?= =?iso-8859-1?Q?QKDhL0sjTejrSnRVrbLI3eN95aoDtvvI/3bG9NlVhiwgzZN8z4G7LOjiQx?= =?iso-8859-1?Q?IvbRUBxtgDLZ3TlkrKZcSIAUi8+1FBAdp9eaAdCPcJczv4L9lqcpwOZWAe?= =?iso-8859-1?Q?jelEPC7RPavjEp4m12KZPyvlR3WmmZp4LtVwKxRQcMLpR3bAyWFlnUzv0g?= =?iso-8859-1?Q?jL+ar39OIP4PKlZY7QpaWQg/RjapRirevmnzF/I81c7wsNr2CX5XxdFmMh?= =?iso-8859-1?Q?OaXa0VW3j+scCixy+C8fiRWZCZIrtLbKPEVEkUbz60z5Zz89AsEw1iXGk9?= =?iso-8859-1?Q?r8XJXhByFva6y7OpGiqrOa4N3aXzylwyb8dfI78QqDtSQ9I1O0q2EuxLmf?= =?iso-8859-1?Q?h5e5q/kS80ucCUPkDPh8TmDOGUVTjWU5ri3irc9NmwcrteccPQBfkjB7Na?= =?iso-8859-1?Q?xIOvqA+LefJ62HmYY5IeLHqFm7WG2f6Ts0N9lToCZk34wOFtdYp6QOPRMO?= =?iso-8859-1?Q?Wpid63EdapmQk2tE3hir2puWST21YvGfJ6BsTB7TBlZzZrlY+ZPPXKy8P/?= =?iso-8859-1?Q?cFwcPJ+NOsx+qnYeJZd1CZwloK4IBRB2lSRGlpLewse6ZlacRT2EIaw9dp?= =?iso-8859-1?Q?+E3GNj4gvr3LjATozALnG1wyirlptKXmIxHp0PzN4pajEHenR2tA0Wa0LG?= =?iso-8859-1?Q?CCVKWntks/RIutwR1ObjkiLqib22bAp/3UmWF8PJxO3IaIvUjm9nGE27Wt?= =?iso-8859-1?Q?HtR6aRqTgkf0qOPvfQ9X/17V2C60eKwCNExJo2xnp8PWD3TpfzQyf+vqdX?= =?iso-8859-1?Q?O/zoK/C4j5CJTsJUxh1vGpQrCRX+vZM/Fdl64UmoT/FJE3IxIZ6LhHoISb?= =?iso-8859-1?Q?x66W4p5W1AkzGwurnsuSCcgbLfqHxxxXNFb+I+YWo5XoZ4U9h7ZfYA6Jac?= =?iso-8859-1?Q?1Q7v751+TQvMyuGFoSIoSgEmzK4m6R6Y/Ey1/2ySHkU8Kq76jyjfoUL2A6?= =?iso-8859-1?Q?1cVL+Dtth/yi41pkJ39d1WPATBw73X5FZzBBs1qUKCLqJo38PazDeNnj25?= =?iso-8859-1?Q?MTw8HirRnYE+J9KHKqCqFyPQyMGdR8kCcGBffXyR9lDtleiADaESKEc0Vh?= =?iso-8859-1?Q?KsfcBxPeFYQGf7O2vF5HL2mR89wBeaoum8blbwtuNlV?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2998; 6:XbWZHSRRc1kGh4iBfKEQr7tGzHWPu7qcYvGz177INCy1uRC9DuR71pof1bDHq7ns3GRnoU+5LYKfKnCD+L41lK+Ec1bQoX3wMO1yYYFSL5Y+rlp8jpyIth1hRx6uQ7EK/TEgUlsn1vjU/svwuUwderg1q9lE9bCv0yPvxE1kuhCRr3t6QV6jyBN72Owlf94/3dj60cJQHzb2aNwvu5N271OpFzF9UqNuSOg4ptwdSkrghdfjufGLQtVurrpjDAPRS2bJo01AeubbDcfsGfgS81a2L4BFSqwXgeEL/Kt/11p2gHgiq1H1608B5ssyj5zfcqUVagszvIhTWTt2tFrWFMTdjnjxF0eelVNJDv9YOkolKHCnVPY/RvMyVz35ek+QOUEiURAaq67+fh7sqs6p7cZPk/iiLEb3NJ2r0ozn6KI=; 5:27d+8Ia8FWIneZY9AHdUjDmfb5OhAEq3wY0zL3ZyKyTeUT+Si1/y4sw99suH/N1RnjwcqKjPy9z2stX3Qusphe4mEqJtRMdUAbblOXtjOvdOgeDrIxnJJQi0L52wHV0YOjvo7hUSLtW2LqJrQs+H5g==; 24:R8tN4+qzt5FmpKu+Wujki/wo0uINhqDGjQ4pRkvhDjzklMREJHl4/67awJPZ3MMUY3h7WdE/W8CizpUx7AZ8Ne9Q1ZJgq0qGLG6b4WtEasg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2998; 7:RGnANoaY2/5YeF9S0L5CZE6mpCWqGdnA4+RGVi6hYI7VpAyRIVQ3v+Zrqi3D9ZaVIbP7VvruJ2YG41tNMbEXHXpAgcjtqTvW2lfUGwwpWnzdcDzYrvTw/B2fAGtSlyxZeGQnqLA0x3/syZkJrfDFPusRdaDJWLDp0Z1Glr6nLBFtf5jnEmNw7YKnQono2YpFvMwTnemUK2w7P/GMTk1ZnU74DR3J7gsSz/CEZHYOjYgMiFdjN9vyNgDQBVmuWYORY6uRYb5LTbhmm1TuvAiUwFLilU9Ezu99IRC+ZVcpgxtznm3Eh0erOuLPic/rrVJt9wHi8g+2mXqaAOXlv/oQcPN/aN2EGUfgB1AfqQUCl5i5jl2WZpXir/r23mgRK0Qx4Sq+QERAhcbGifL+6sqLK8zwWVQnW4B2YMKq3OHzl/RtmlShlJcLa7+0ERrZKavBFvGxm7lyBc6uAV1fQWbY+g== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2017 17:20:00.4029 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2998 Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, ietf , draft-ietf-sidr-rpki-oob-setup@ietf.org, sidr@ietf.org Subject: Re: [sidr] Last Call: (An Out-Of-Band Setup Protocol For RPKI Production Services) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:20:06 -0000 Looking some more at this, I would not want to try and troubleshoot this protocol with such a limited range of error messages. Not something I am likely to be doing but were I to, I would like to see an indication of the nature of the error (eg in attribute, element, certificate) and where the error was found (the relevant name) and for authentication errors, well, look at the certificate related TLS Alerts which suggest to me the level of detail that has found to be needed in at least some quarters. And bear in mind that you are making no recommendation about most of the certificate options, just that you expect them to be the usual ones:-) As it is, I would not know where to place most errors into the three possibilities provided. Tom Petch ----- Original Message ----- From: "Rob Austein" To: "tom p." Cc: "Chris Morrow" ; ; ; ; Sent: Thursday, December 29, 2016 11:15 PM Subject: Re: [sidr] Last Call: (An Out-Of-Band Setup Protocol For RPKI Production Services) to Proposed Standard > At Wed, 28 Dec 2016 10:55:15 +0000, tom p. wrote: > > > > When I saw BPKI in the Abstract, I thought 'typo'! Reading on, it > > isn't; in which case, it needs expanding in the Abstract. > > > > Appendix A is in RelaxNG; I would like a reference for that language. > > > > Is Appendix A Normative? i.e. in the event of a mismatch between the > > body of the I-D and Appendix A, which wins? If Appendix A, then that > > reference should be Normative. > > Thanks for the review! I agree with all of the above, will post > revisions post-LC unless there is reason to update sooner. > > Yes, I think the RelaxNG schema had best be normative. We already > found and fixed one minor disagreement between text and schema; > unsurprisingly, running code in that case agreed with the schema. > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Fri Jan 6 11:10:57 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7BF129D9C; Fri, 6 Jan 2017 11:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 ZWW5ObuqUaGw; Fri, 6 Jan 2017 11:10:53 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7917E129611; Fri, 6 Jan 2017 11:10:53 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id CD2DD13998; Fri, 6 Jan 2017 19:10:51 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 74B334602216; Fri, 6 Jan 2017 14:10:41 -0500 (EST) Date: Fri, 06 Jan 2017 14:10:41 -0500 From: Rob Austein To: t.petch In-Reply-To: <00a001d26840$e5194580$4001a8c0@gateway.2wire.net> References: <148226796672.23778.11324483834700038816.idtracker@ietfa.amsl.com> <01f101d260f9$dee15c00$4001a8c0@gateway.2wire.net> <20161229231547.4552D456B7F2@minas-ithil.hactrn.net> <00a001d26840$e5194580$4001a8c0@gateway.2wire.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170106191041.74B334602216@minas-ithil.hactrn.net> Archived-At: Cc: Rob Austein , Chris Morrow , sidr-chairs@ietf.org, sidr@ietf.org, draft-ietf-sidr-rpki-oob-setup@ietf.org, ietf Subject: Re: [sidr] Last Call: (An Out-Of-Band Setup Protocol For RPKI Production Services) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 19:10:54 -0000 At Fri, 6 Jan 2017 17:15:04 +0000, t.petch wrote: > > Looking some more at this, I would not want to try and troubleshoot this > protocol with such a limited range of error messages. > > Not something I am likely to be doing but were I to, I would like to see > an indication of the nature of the error (eg in attribute, element, > certificate) and where the error was found (the relevant name) and for > authentication errors, well, look at the certificate related TLS Alerts > which suggest to me the level of detail that has found to be needed in > at least some quarters. And bear in mind that you are making no > recommendation about most of the certificate options, just that you > expect them to be the usual ones:-) > > As it is, I would not know where to place most errors into the three > possibilities provided. Sort of agree, but.... The PDU is optional, and in practice has not been used much to date. In practice, diagnosing errors generally involves looking in some server log file, and errors to date have usually been reported via email or voice. We included the PDU because an earlier reviewer insisted, but we don't have enough experience using with it to know what kind of detail would really be useful. That being the case, my preference would be to leave the schema alone for now and wait for experience, after which we can revise the protocol if we see an opportunity for serious improvement. YMMV. FWIW, the three current error codes translate, roughly, to: * "I don't understand what you want me to do"; * "I think I understand what you want me to do and am willing but I hit an authorization problem while trying to do it"; and * "I don't feel like playing this game". I don't see all that much ambiguity between these three very broad categories, but I'm also not all that worried about it, because I don't expect the current simplistic version of the PDU to replace two human being having some kind of conversation after looking at log files. Again, YMMV. From nobody Fri Jan 6 15:04:24 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD1B129603; Fri, 6 Jan 2017 15:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 KHA-w8XcpbsN; Fri, 6 Jan 2017 15:04:20 -0800 (PST) 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 A5DD5129420; Fri, 6 Jan 2017 15:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39306; q=dns/txt; s=iport; t=1483743859; x=1484953459; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=r5EZAtX6X7BNysM+rLsMd/OlLhzi+WxoFKKYHwvbJ8Q=; b=Va2tZStl4JHjiOOMmfKwQAqv0KtCmkKuPfDXgf5WgCQzrPDwACyNFpQL EmMYI+Oev8DZaArFliQ06Ym29nAYTG4nVQSCm+RwbQcK04IXWtgxjp8ay oa232iJWdBh6sqOnkf5+V+kZerGLVuOjLS3ekar71uLcj1s6PtVSyMCWu Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmAgD7IXBY/5pdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnFIAQEBAQEfXzNZB41Qp0iCCYJsgzYCGoE8PxQBAgEBAQEBAQF?= =?us-ascii?q?jKIRpBiNWEAIBBgISJgoCAgIwFw4CBA4FFIhckmycHw+BIIIlK4l0AQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYZFggIIgleEDyECK4JxLYIxAQSVGoV7AYdQghuHWwq?= =?us-ascii?q?BbYUIiVyICYY3hBABHziBPBVEAYQZHIFfc4YqASQHgQOBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,326,1477958400"; d="scan'208,217";a="189550639" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jan 2017 23:04:18 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v06N4Ioe027318 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Jan 2017 23:04:18 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 6 Jan 2017 17:04:17 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Fri, 6 Jan 2017 17:04:17 -0600 From: "Alvaro Retana (aretana)" To: Tim Bruijnzeels Thread-Topic: [sidr] AD Review of draft-ietf-sidr-delta-protocol-04 Thread-Index: AQHSWsMmv8FEfthKGUScz+TLnYEy7KEeAgSAgA47ooA= Date: Fri, 6 Jan 2017 23:04:17 +0000 Message-ID: References: <7DE58D01-AC82-4099-9A46-99E625315637@cisco.com> <99DD12D4-6E13-40A4-95C7-17B12CB61F1C@ripe.net> In-Reply-To: <99DD12D4-6E13-40A4-95C7-17B12CB61F1C@ripe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: multipart/alternative; boundary="_000_EE84C61E77304559852A4CFBF8543756ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sidr-delta-protocol@ietf.org" , Chris Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] AD Review of draft-ietf-sidr-delta-protocol-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 23:04:22 -0000 --_000_EE84C61E77304559852A4CFBF8543756ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gMTIvMjgvMTYsIDExOjQzIEFNLCAiVGltIEJydWlqbnplZWxzIiA8dGltQHJpcGUubmV0PiB3 cm90ZToNCg0KDQoNClRpbToNCg0KDQoNCkhhcHB5IE5ldyBZZWFyISENCg0KDQoNCg0KDQp8IFRo YW5rIHlvdSBmb3IgeW91ciBpbi1kZXB0aCByZXZpZXcgOikgSXQgcmVhbGx5IGhlbHBzIHRvIGNs YXJpZnkgdGhlIGRvY3VtZW50LiBSZXBsaWVzIGluLWxpbmUuDQoNCnwNCg0KfCBJIGF0dGFjaGVk IGFuIHVwZGF0ZWQgZG9jdW1lbnQsIGJ1dC4uIEkgZGlkIG5vdCBkaXNjdXNzIHRoaXMgd2l0aCBj by1hdXRob3JzIHlldC4gU28sIEkgaW52aXRlIGFueSBvZiB0aGVtIHRvDQoNCnwgZGlzYWdyZWUg b3Igc3VnZ2VzdCBjaGFuZ2VzIHRvIHRoZSB0aGluZ3MgYmVsb3cuDQoNCg0KDQpUaGFua3MgZm9y IHRoYXQuICBJIGhhdmUgc29tZSBjb21tZW50cyBiZWxvdyDigJMgSSB3YW50IHVzIHRvIGRpc2N1 c3MgdGhlIFVwZGF0ZSBpc3N1ZSAoTTE2KSBzbyB3ZSBjYW4gc3RhcnQgdGhlIElFVEYgTGFzdCBD YWxsLg0KDQoNCg0KVGhhbmtzIQ0KDQoNCg0KQWx2YXJvLg0KDQoNCg0KDQoNCnwgT24gMjAgRGVj IDIwMTYsIGF0IDE0OjE1LCBBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSA8YXJldGFuYUBjaXNjby5j b20+IHdyb3RlOg0KDQrigKYNCg0KfCB8IE0yLiBTZWN0aW9uIDMuMi4gKENlcnRpZmljYXRlIEF1 dGhvcml0eSBVc2UpOiDigJxSZWx5aW5nIFBhcnRpZXMgdGhhdCBkbyBub3Qgc3VwcG9ydCB0aGlz IGRlbHRhIHByb3RvY29sIE1VU1QNCg0KfCB8IE5PVCByZWplY3QgYSBDQSBjZXJ0aWZpY2F0ZSBt ZXJlbHkgYmVjYXVzZSBpdCBoYXMgYW4gU0lBIGV4dGVuc2lvbiBjb250YWluaW5nIHRoaXMgbmV3 IGtpbmQgb2YNCg0KfCB8IEFjY2Vzc0Rlc2NyaXB0aW9uLuKAnSAgQnkgZGVmaW5pdGlvbiwgYW4g UlAgdGhhdCBoYXMgbmV2ZXIgZXZlbiBjb25zaWRlcmVkIHRoaXMgZG9jdW1lbnQgd2lsbCBub3Qg c3VwcG9ydA0KDQp8IHwgdGhlIGRlbHRhIHByb3RvY29sIOKAkyBJT1csIHRyeWluZyB0byBzcGVj aWZ5IHRoZSBiZWhhdmlvciBvZiBSUHMgdGhhdCBtYXkgaGF2ZSBuZXZlciBldmVuIHNlZW4gdGhp cw0KDQp8IHwgZG9jdW1lbnQgbWFrZXMgbm8gc2Vuc2UgdG8gbWUsIGFuZCBjYW7igJl0IGJlIGVu Zm9yY2VkLiAgV2hhdCBpcyB0aGUgY3VycmVudCBiZWhhdmlvciB3aGVuIGFuIFJQIHJlY2VpdmVz DQoNCnwgfCB0aGUgZXh0cmEgU0lBIGV4dGVuc2lvbj8NCg0KfA0KDQp8IFRoZSBwb2ludCBvZiBk b2N1bWVudGluZyB0aGlzIGlzIHRvIGdpdmUgUlAgc29mdHdhcmUgdGhlIG9wdGlvbiBvZiByZWNv Z25pc2luZyB0aGF0IGEgbmV3IHByb3RvY29sIGV4aXN0cywNCg0KfCBldmVuIGlmIHRoZXkgZG8g bm90IGZ1bGx5IHN1cHBvcnQgaXQgeWV0LiBJbiBwcmFjdGljZSBhbGwgY3VycmVudCBSUHMgZG8g dGhpcyAoc2VlIGJlbG93KSwgYW5kIGZ1dHVyZSBSUHMgc2hvdWxkDQoNCnwgY29uc2lkZXIgdGhp cyBkb2N1bWVudC4gV2UgaGF2ZSBpbiBmYWN0IGJlZW4gcHVibGlzaGluZyB0aGVzZSBhZGRpdGlv bmFsIFNJQXMgaW4gdGhlIFJJUEUgTkNDIHByb2R1Y3Rpb24NCg0KfCBSUEtJIGZvciBtb3JlIHRo YW4gYSB5ZWFyIHdpdGhvdXQgcHJvYmxlbXMuIEkgY2hhbmdlZCBpdCBzbGlnaHRseSB0byB0aGlz Og0KDQp8DQoNCnwgIlJlbHlpbmcgUGFydGllcyB0aGF0IGNob29zZSBub3QgdG8gc3VwcG9ydCB0 aGlzIGRlbHRhIHByb3RvY29sIHlldCwgTVVTVCBOT1QgcmVqZWN0IGEgQ0EgY2VydGlmaWNhdGUg bWVyZWx5DQoNCnwgYmVjYXVzZSBpdCBoYXMgYW4gU0lBIGV4dGVuc2lvbiBjb250YWluaW5nIHRo aXMgbmV3IGtpbmQgb2YgQWNjZXNzRGVzY3JpcHRpb24uIg0KDQp8DQoNCnwgQnV0LCBJIGNhbiBh bHNvIGxpdmUgd2l0aCB0YWtpbmcgdGhpcyBzZW50ZW5jZSBvdXQgYWx0b2dldGhlci4NCg0KDQoN Ckkgd291bGQgcHJlZmVyIGl0IGlmIHdlIGRvIHRoYXQuDQoNCg0KDQoNCg0K4oCmDQoNCnwgfCBN NC4gRnJvbSAzLjMuMi4gKFB1Ymxpc2hpbmcgVXBkYXRlcyk6IOKAnFRoZSB1cGRhdGUgbm90aWZp Y2F0aW9uIGZpbGUgU0hPVUxEIGJlIGtlcHQgc21hbGzigKZvbGRlciBkZWx0YSBmaWxlcw0KDQp8 IHwgdGhhdOKApndpbGwgcmVzdWx0IGluIHRvdGFsIHNpemUgb2YgZGVsdGFzIGV4Y2VlZGluZyB0 aGUgc2l6ZSBvZiB0aGUgc25hcHNob3QsIE1VU1QgYmUgZXhjbHVkZWQu4oCdICBIZXJlIHRoZQ0K DQp8IHwg4oCcU0hPVUxE4oCdIGFuZCB0aGUg4oCcTVVTVOKAnSBhcmUgaW4gY29udHJhZGljdGlv bjogeW91IGVpdGhlciBkbyBpdCBhbHdheXMgKE1VU1QpIG9yIHRoZXJlIG1heSBiZSBjYXNlcyB3 aGVuDQoNCnwgfCB5b3UgZG9u4oCZdCAoU0hPVUxEKS4gIHMvU0hPVUxEL3Nob3VsZA0KDQp8DQoN CnwgT2ssIEkgbW92ZWQgdGhlIGZpbGUgc2l6ZSBjb25jZXJuIHRvIHRoZSBuZXh0IGJ1bGxldCBw b2ludCBpbnN0ZWFkLCBzbyB0aGF0IHdlIGhhdmU6DQoNCnwNCg0KfCBvIEFueSBvbGRlciBkZWx0 YSBmaWxlcyB0aGF0LCB3aGVuIGNvbWJpbmVkIHdpdGggYWxsIG1vcmUgcmVjZW50IGRlbHRhIGZp bGVzLCB3aWxsIHJlc3VsdA0KDQp8ICAgaW4gYSB0b3RhbCBzaXplIG9mIGRlbHRhcyBleGNlZWRp bmcgdGhlIHNpemUgb2YgdGhlIHNuYXBzaG90LCBNVVNUIGJlIGV4Y2x1ZGVkIHRvIGF2b2lkDQoN CnwgICB0aGF0IFJQcyBkb3dubG9hZCBtb3JlIGRhdGEgdGhhbiBuZWNlc3NhcnkuDQoNCnwNCg0K fCBvIFRoZSBzZXJ2ZXIgTUFZIGFsc28gZXhjbHVkZSBtb3JlIHJlY2VudCBkZWx0YSBmaWxlcyBp ZiBpdCBmaW5kcyB0aGF0IHRoZWlyIHVzYWdlIGJ5IGENCg0KfCAgIHNtYWxsIG51bWJlciBvZiBS UHMgdGhhdCB3b3VsZCBiZSBmb3JjZWQgdG8gcGVyZm9ybSBhIGZ1bGwgc3luY2hyb25pc2F0aW9u IGlzIG91dHdlaWdoZWQNCg0KfCAgIHBlcmZvcm1hbmNlIGJlbmVmaXRzIG9mIGhhdmluZyBhIHNt YWxsZXIgdXBkYXRlIG5vdGlmaWNhdGlvbiBmaWxlLiBIb3dldmVyLCB0aGUgcmVwb3NpdG9yeQ0K DQp8ICAgc2VydmVyIE1VU1QgaW5jbHVkZSBhbGwgZGVsdGFzIHRoYXQgaXQgaGFzIGF2YWlsYWJs ZSBmb3IgdGhlIGxhc3QgdHdvIGhvdXJzLg0KDQp8DQoNCnwgSSBob3BlIHRoYXQgZXhwbGFpbnMg aXQgYmV0dGVyLiBJIGNoYW5nZWQgdGhlIFNIT1VMRCBpbiB0aGUgc2Vjb25kIGJ1bGxldCBwb2lu dCB0byBhIE1VU1QuIFRoZSB1bnNwb2tlbg0KDQp8IHJlYXNvbiBmb3IgdGhlIFNIT1VMRCB3YXMg dGhhdCBhIHB1YmxpY2F0aW9uIHNlcnZlciBtYXkgbm90IGhhdmUgZGVsdGFzLg0KDQoNCg0KVGhl IHByb2JsZW0gdGhhdCBJIHRoaW5rIGNhbiBzdGlsbCBleGlzdCBpcyB0aW1lIGRlcGVuZGVudDog IOKAnG9sZGVyIGRlbHRhIGZpbGVz4oCmTVVTVCBiZSBleGNsdWRlZOKApk1VU1QgaW5jbHVkZSBh bGwgZGVsdGFzIHRoYXQgaXMgaGFzIGF2YWlsYWJsZSBmb3IgdGhlIGxhc3QgdHdvIGhvdXJz4oCd LiAgV2hhdCBoYXBwZW5zIGlmIGFsbCDigJxvbGRlciBkZWx0YSBmaWxlc+KAnSBhcmUgbGVzcyB0 aGFuIHR3byBob3VycyBvbGQsIGJ1dCB0aGUgc2l6ZSB3b3VsZCBiZSB0b28gYmlnPyAgSXMgdGhl cmUgdGhlIHBvc3NpYmlsaXR5IG9mIGEgY2FzZSB3aGVyZSB0aGVyZSBhcmUgYSBsb3Qgb2YgY2hh bmdlcyB0aGF0IGhhcHBlbiBjbG9zZSB0b2dldGhlciAoYnV0IG1vcmUgdGhhbiBhIG1pbnV0ZSBh cGFydCkgdGhhdCB3b3VsZCB0aGVuIHJlc3VsdCBpbiBtYW55IGRlbHRhIGZpbGVzPyAgQmVzaWRl cyBub3QgcG9zdHBvbmluZyBwdWJsaWNhdGlvbiBmb3IgbW9yZSB0aGFuIGEgbWludXRlLCBJIGRv buKAmXQgcmVtZW1iZXIgb3RoZXIgbWVjaGFuaXNtcyB0aGF0IHdvdWxkIGF2b2lkIGEgbGFyZ2Ug bnVtYmVyIG9mIGNoYW5nZXPigKYgIElmIHRoaXMgY2FzZSBpcyBub3QgcG9zc2libGUsIHRoZW4g d2Ugc2hvdWxkIGJlIG9rIOKAkyBJIHdvdWxkIHN0aWxsIGxpa2UgdG8gdW5kZXJzdGFuZCB3aHku DQoNCg0KDQoNCg0K4oCmDQoNCnwgfCBNNy4gMy40LjEuIChQcm9jZXNzaW5nIHRoZSBVcGRhdGUg Tm90aWZpY2F0aW9uIEZpbGUpOiDigJxNVVNUIGlzc3VlIGFuIG9wZXJhdG9yIGVycm9y4oCdICBX aGF0IGlzIGFuIOKAnG9wZXJhdG9yDQoNCnwgfCBlcnJvcuKAnSBhbmQgaG93IGRvIHlvdSBpc3N1 ZSBvbmU/ICBJIGRpZG7igJl0IHNlZSBhbiBlcnJvciBkZWZpbml0aW9uIGluIHRoZSBzY2hlbWEu DQoNCnwNCg0KfCBJIHNlZSB5b3VyIHBvaW50LCBidXQuLiBhZmFpayBub25lIG9mIHRoZSBvdGhl ciBzaWRyIFJGQ3MgYW5kIEktRHMgZGVmaW5lIHRoaXMsIGFuZCBqdXN0IGF2b2lkIHRhbGtpbmcg YWJvdXQgdGhpcw0KDQp8IGFsdG9nZXRoZXIuIFRoaXMgd2FzIHVuZGVmaW5lZCBpbiBvdmVyIGZp dmUgeWVhcnMgb2YgZGVwbG95bWVudCB3aXRoIHJzeW5jLCBhbmQgeWV0IG9wZXJhdGlvbmFsIGlz c3VlcyB3aXRoDQoNCnwgcnN5bmMgYWxzbyBoYXBwZW4gYW5kIGdldCByZXBvcnRlZCBhbmQgcmVz b2x2ZWQgc29tZWhvdy4gSW4gc2hvcnQgSSBzdWdnZXN0IHRoYXQgSSBqdXN0IGxlYXZlIGl0IG91 dCBoZXJlIGFzDQoNCnwgd2VsbC4NCg0KDQoNCk5vLiAgU29ycnksIGJ1dCDigJxPdGhlcnMgZGlk buKAmXQgZG8gaXTigJ0gaXMgbm90IGEgdmFsaWQgcmVhc29uIGZvciBhbiBpbmNvbXBsZXRlIHNw ZWNpZmljYXRpb24uDQoNCg0KDQp8IEJ1dCB0byBjb250aW51ZTogQWxsIFJQcyBkbyBoYXZlIHRo ZSBjb21tb24gc2Vuc2UgdG8gaW5mb3JtIHRoZWlyIHVzZXJzIGFib3V0IGlzc3VlcyAoZS5nLiBh bHNvIHRoaW5ncyBsaWtlOg0KDQp8IGhleSwgdGhpcyBjZXJ0aWZpY2F0ZSBpcyBpbnZhbGlkIGJl Y2F1c2UuLiksIGJ1dCB0aGVyZSBpcyBubyBzdGFuZGFyZCBkZWZpbmVkLCBzbyB0aGV5IHVzZSB2 YXJpb3VzIGZvcm1hdHMgYW5kDQoNCnwgd2F5cy4gSSBkbyBzZWUgc29tZSBiZW5lZml0IGluIGRl ZmluaW5nIGF0IGxlYXN0IGEgY29tbW9uIHN0YW5kYXJkIGJlY2F1c2UgaXQgbWlnaHQgaGVscCAo MSkgbW9uaXRvcmluZywgKDIpDQoNCnwgbm9ybWF0aXZlIGRvY3VtZW50aW5nIG9mIGVycm9yIGNv bmRpdGlvbnMgYW5kIHJlc3BvbnNlcywgYW5kICgzKSBpbnRlcm9wIHRlc3RpbmcgYmV0d2VlbiBS UHMgKFJvYiwgRGF2aWQNCg0KfCBhbmQgSSBoYXZlIGRvbmUgdGhpcyBhIGZldyB0aW1lcyBhbmQg aXQncyBhIGJpdCBvZiBhIGhhc3NsZSkuIERvaW5nIHNvIGlzIGltbyBtYWpvciB3b3JrIGFuZCBz b21ldGhpbmcgZm9yIGENCg0KfCBzZXBhcmF0ZSBzaWRyLW9wcyBkb2N1bWVudC4NCg0KDQoNCk9u ZSBvZiB0aGUgcmVhc29ucyBJIGFkZGVkIHRoaXMgY29tbWVudCBpcyBiZWNhdXNlIGl0IHVzZXMg YSDigJxNVVNU4oCdOiB5b3XigJlyZSBtYW5kYXRpbmcgdGhlIGJlaGF2aW9yIGFzIHBhcnQgb2Yg dGhlIHNwZWNpZmljYXRpb24uICBJZiBpdCBpcyBhIG1hbmRhdG9yeSBiZWhhdmlvciwgdGhlbiB0 aGVyZSBzaG91bGQgYmUgc29tZXRoaW5nIHRoYXQgZ29lcyB3aXRoIGlzIGFzIHRvIGhvdyBpdCBp cyBkb25lLiAgT25lIHdheSBmb3J3YXJkIGlzIHRvIGNsYXJpZnkgd2hhdCB5b3UgbWVhbiBieSBh biDigJxvcGVyYXRvciBlcnJvcuKAnSwgd2hpY2ggKGludGVycHJldGluZyB0aGUgcGFyYWdyYXBo IGFib3ZlKSBpcyByZWFsbHkgYSBsb2cgbWVzc2FnZS4NCg0KDQoNCkkgYW0gZmluZSAoaWYgeW91 IHdhbnQgdG8gbWFuZGF0ZSB0aGUgYmVoYXZpb3IpIGZvciB5b3UgdG8gc2F5IHNvbWV0aGluZyBs aWtlOiDigJxNVVNUIGxvZyB0aGUgY29uZGl0aW9uIGZvciB0aGUgb3BlcmF0b3IgdG8gYmUgYXdh cmUgb2YgdGhlIHByb2JsZW3igJ0uICBObyBuZWVkIHRvIHNwZWNpZnkgdGhlIGNvbnRlbnRzLCBh IGNvbW1vbiBmb3JtYXQsIGV0Yy4NCg0KDQoNCkkgYWdyZWUgdGhhdCBpZiB5b3UgZGlkIHdhbnQg dG8gZGVmaW5lIGNvbW1vbiBmb3JtYXRzLCBjb250ZW50cywgZXRjLiB0aGVuIHRoYXQgd291bGQg YmVsb25nIHNvbWV3aGVyZSBlbHNlLg0KDQoNCg0KDQoNCuKApg0KDQp8IFNlZSBzZWN0aW9uIDMu NC41IG9mIGF0dGFjaGVkIGZpbGUgZm9yIGNsYXJpZmljYXRpb25zIHRoYXQgSSB0aGluayB3ZSBj YW4gZG8gaW4gdGhlIGNvbnRleHQgb2YgdGhpcyBkb2N1bWVudC4NCg0KfCBGb2xsb3dpbmcgeW91 ciBwcmV2aW91cyByZW1hcmsgdGhlIG9ubHkgbm9ybWF0aXZlIGFkZGl0aW9uIEkgZmVlbCBJIGNh biBhZGQgaXMgdGhpczogIkluIG9yZGVyIHRvIGhlbHAgcHJldmVudA0KDQp8IHRoaXMgUHVibGlj YXRpb24gU2VydmVycyBNVVNUIHBlcmZvcm0gcmVndWxhciB2YWxpZGF0aW9uIG9mIHRoZWlyIG93 biBSUkRQIHJlcG9zaXRvcnkuIg0KDQoNCg0KVGhlIG5ldyBzZWN0aW9uIGxvb2tzIG9rLCBleGNl cHQgZm9yIHRoZSBwYXJhZ3JhcGggdGhhdCBzYXlzOiDigJxUaGlzIHByb3RvY29sIGRvY3VtZW50 IGNhbm5vdCBkZWZpbmUgbm9ybWF0aXZlIHRleHTigKbigJ0gIE5vIG5lZWQgdG8gcHV0IHRoYXQg aW4gaGVyZS4NCg0KDQoNCg0KDQp8IHwgTTExLiBGcm9tIDMuNC4zLiAoUHJvY2Vzc2luZyBEZWx0 YSBGaWxlcyk6IOKAnGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgYSBSUCB1c2VzIGFkZGl0aW9uYWwg c3RyYXRlZ2llcyB0bw0KDQp8IHwgZGV0ZXJtaW5lIGlmIGFuIG9iamVjdCBpcyBzdGlsbCByZWxl dmFudCBmb3IgdmFsaWRhdGlvbiBiZWZvcmUgcmVtb3ZpbmcgaXQgZnJvbSBpdHMgbG9jYWwgc3Rv cmFnZeKAnS4gIE9rLCBsaWtlDQoNCnwgfCB3aGF0Pw0KDQp8DQoNCnwgSSB0aGluayBnb2luZyBp bnRvIHRvbyBtdWNoIGRldGFpbCBpcyBvdXQgb2Ygc2NvcGUgYmVjYXVzZSBpdCBjYW5ub3QgYmUg ZXhwbGFpbmVkIHdpdGhvdXQgaGF2aW5nIGEgZG9jdW1lbnQNCg0KfCBmb3JtYWxseSBkZXNjcmli aW5nIHZhbGlkYXRpb24gc3RyYXRlZ2llcy4gQnV0IEkgYWRkZWQgdGhpczoNCg0KfA0KDQp8IElu IHBhcnRpY3VsYXIgb2JqZWN0cyBzaG91bGQgbm90IGJlIHJlbW92ZWQgaWYgdGhleSBhcmUgaW5j bHVkZWQgaW4gYSBjdXJyZW50IHZhbGlkYXRlZCBtYW5pZmVzdC4NCg0KDQoNCk9rLiAgQXMgYmVm b3JlLCB0aGUgcmVhc29uIGZvciB0aGUgY29tbWVudCBpcyB0aGUgdXNlIG9mIOKAnFJFQ09NTUVO REVE4oCdLg0KDQoNCg0KDQoNCuKApg0KDQp8IHwgTTE2LiBTZWN0aW9uIDUuIChTZWN1cml0eSBD b25zaWRlcmF0aW9ucyk6IOKAnFJSRFAgcmVwbGFjZXMgdGhlIHVzZSBvZiByc3luYyBieSBIVFRQ U+KApuKAnS4gR2l2ZW4gdGhlDQoNCnwgfCBzdGF0ZW1lbnQgaW4gMy40LjEgYWJvdXQgdXNpbmcg 4oCcYW4gYWx0ZXJuYXRlIHJlcG9zaXRvcnkgcmV0cmlldmFsIG1lY2hhbmlzbeKAnSBhbmQgdGhl IHJlc3Qgb2YgdGhlIHRleHQgaW4gdGhpcw0KDQp8IHwgc2VjdGlvbiwgSSB3b3VsZCBhc3N1bWUg dGhhdCB0aGUgaW50ZW50IGlzIG5vdCByZWFsbHkgdG8g4oCccmVwbGFjZSB0aGUgdXNlIG9mIHJz eW5j4oCdICh3aXRoIGFuIHVwZGF0ZSB0bw0KDQp8IHwgUkZDNjQ4MCkuICAgTWF5YmUgSeKAmW0g cmVhZGluZyB0b28gbXVjaCBpbnRvIHRoZSBwaHJhc2UgYWJvdmUsIGJ1dCBwbGVhc2UgY2xhcmlm eS4NCg0KfA0KDQp8IEFzIGV4cGxhaW5lZCBhYm92ZSBpdCBpcyB0aGUgaW50ZW50IHRvIHJlcGxh Y2UgcnN5bmMuIEJ1dC4uIGEgbWlncmF0aW9uIGRvY3VtZW50IHNob3VsZCBiZSB3cml0dGVuIGFz IGENCg0KfCBzZXBhcmF0ZSBlZmZvcnQuDQoNCnwNCg0KfCBUaGF0IHNhaWQgSSB3b3VsZCBiZSBm aW5lIHdpdGgganVzdCB0YWtpbmcgb3V0Og0KDQp8DQoNCnwgICAgIFRoZSBvcmlnaW5hbCBSUEtJ IHRyYW5zcG9ydCBtZWNoYW5pc20gaXMgcnN5bmMsIHdoaWNoIG9mZmVycyBubyBjaGFubmVsDQoN CnwgICAgIHNlY3VyaXR5IG1lY2hhbmlzbS4gUlJEUCByZXBsYWNlcyB0aGUgdXNlIG9mIHJzeW5j IGJ5IEhUVFBTOw0KDQp8DQoNCnwgUGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBwcmVmZXIgdGhp cy4NCg0KDQoNCg0KDQpMZXQgbWUgdHJ5IHRvIG1ha2UgdGhlIHBvaW50IGFnYWluIOKAkyBJIGRp ZG7igJl0IGRvIGEgZ29vZCBqb2IgYWJvdmUuICBJbiBmYWN0LCByZWFkaW5nIHRoaXMgb3ZlciBJ IHdhbnQgdG8gY2hhbmdlIGl04oCmDQoNCg0KDQpJbiB0aGlzIGRvY3VtZW50IHlvdeKAmXJlIHNh eWluZzogaGVyZeKAmXMgYSBuZXcgcHJvdG9jb2wgdGhhdCBTSE9VTEQgYmUgdXNlZCBpbnN0ZWFk IG9mIHJzeW5jICgzLjQuMSkuDQoNCg0KDQpBbmQsIGFzIHlvdSBtZW50aW9uZWQgYWJvdmUsIHRo ZSBpbnRlbnQgaXMgdG8gZXZlbnR1YWxseSBwaGFzZSBvdXQgcnN5bmMgaW4gZmF2b3Igb2YgUlJE UC4gIFRpbWUgbGluZXMgdG8gcGhhc2UgaXQgb3V0IGFyZSByZWFsbHkgb3V0IG9mIHRoZSBzY29w ZSBvZiB0aGlzIChvciBJIHRoaW5rIGFueSBvdGhlciBSRkMpIGRvY3VtZW50IGJlY2F1c2UgaXQg aXMgc29tZXRoaW5nIHRoZSBSUEtJIGNvbW11bml0eSBhZ3JlZXMgb24gYW5kIG1pZ3JhdGVzIHRv LCBqdXN0IGxpa2UgYW55IG90aGVyIG5ldyBwcm90b2NvbC4NCg0KDQoNCkFsbCB0aGF0IGlzIGdv b2QuDQoNCg0KDQpIb3dldmVyLCBib3RoIFJGQzY0ODAgYW5kIFJGQzY0ODEgbWFuZGF0ZSB0aGUg dXNlIG9mIHJzeW5jOiDigJxhbGwgcHVibGljYXRpb24gcG9pbnRzIE1VU1QgYmUgYWNjZXNzaWJs ZSB2aWEgcnN5bmPigJ0gYW5kIOKAnHB1YmxpY2F0aW9uIHJlcG9zaXRvcnkgTVVTVCBiZSBhdmFp bGFibGUgdXNpbmcgcnN5bmPigJ0uICBXaGljaCBtZWFucyB0aGF0IHRvIGNvbXBseSB3aXRoIHRo ZSBSUEtJIGFyY2hpdGVjdHVyZSByc3luYyBNVVNUIGJlIHN1cHBvcnRlZCBmb3JldmVyLCByZWdh cmRsZXNzIG9mIHdoZXRoZXIgUlJEUCBpcyB1c2VkLCBvciBhIGRpZmZlcmVudCBwcm90b2NvbCB0 aGF0IG1heSBjb21lIGFsb25nIGluIHRoZSBmdXR1cmXigKZvciBldmVuIGlmIGl0IGlzIG5vdCBu ZWVkZWQgYXQgYWxsIGFueW1vcmUgKG5vdCBldmVuIGZvciBldmVudHVhbCBiYWNrdXApLiDimLkN Cg0KDQoNClRoZSBxdWVzdGlvbiBhYm91dCB1cGRhdGluZyBSRkM2NDgwIGFib3ZlIHNob3VsZCBo YXZlIGJlZW4gYSBzdGF0ZW1lbnQ6IHRoaXMgZG9jdW1lbnQgc2hvdWxkIHVwZGF0ZSBSRkM2NDgw L1JGQzY0ODEgc28gdGhhdCByc3luYyBpcyBub3QgcmVxdWlyZWQgYW55bW9yZS4NCg0KDQoNCkNo YW5naW5nIHRoZSB0ZXh0IGluIFJGQzY0ODAvUkZDNjQ4MSB0byBzYXkg4oCcTVVTVCB1c2UgUlJE UOKAnSB3b3VsZCBqdXN0IHJlc3VsdCBpbiBhbm90aGVyIHVwZGF0ZSBsYXRlciBpZiBhbm90aGVy IHByb3RvY29sIGV2ZXIgY29tZXMgYWxvbmcsIHNvIEkgdGhpbmsgdGhpcyBkb2N1bWVudCBzaG91 bGQgYmUgZXhwbGljaXQgaW4gdGhlIGNoYW5nZSAodG8gYWxsb3cgdGhlIG1vdmUgYXdheSBmcm9t IHJzeW5jKSwgYnV0IHN0aWxsIGdlbmVyaWPigKZmb3IgZXhhbXBsZSwgdGhlIHRleHQgaW4gUkZD NjQ4MC9SRkM2NDgxIGNhbiBiZSByZXBsYWNlZCB3aXRoIHNvbWV0aGluZyBsaWtlOiDigJxUaGUg cHVibGljYXRpb24gcG9pbnQgTVVTVCBiZSBhY2Nlc3NpYmxlIHVzaW5nIGEgcmV0cmlldmFsIG1l Y2hhbmlzbSBjb25zaXN0ZW50IHdpdGggdGhlIGFjY2Vzc01ldGhvZCBlbGVtZW50IHZhbHVlKHMp LiAgTXVsdGlwbGUgcmV0cmlldmFsIG1lY2hhbmlzbXMgY2FuIGJlIHN1cHBvcnRlZCBhdCB0aGUg cmVwb3NpdG9yeSBvcGVyYXRvcuKAmXMgZGlzY3JldGlvbuKAnS4NCg0KDQoNCkEgY2hhbmdlIGxp a2UgdGhhdCB3b3VsZCByZXF1aXJlIHRoYXQgdGhpcyBkb2N1bWVudCBiZSB0YWdnZWQgdG8gVXBk YXRlIFJGQzY0ODAvUkZDNjQ4MSAoYW5kIHdvdWxkIG9mIGNvdXJzZSByZXR1cm4gUkZDNjQ4MSB0 byBiZSBOb3JtYXRpdmUpLg0KDQoNCg0KDQoNCg0KDQrigKYNCg0KfCB8IFA0LiDigJx2ZXJzaW9u IDQgVVVJROKAnSAgUGxlYXNlIHByb3ZpZGUgYSByZWZlcmVuY2UuDQoNCnwNCg0KfCBhY2ssIEkg YXNzdW1lZCBpbmZvcm1hdGl2ZS4NCg0KDQoNCk5vcm1hdGl2ZSwgYmVjYXVzZSB0aGUgZG9jdW1l bnQgc2F5cyB0aGF0IGl0IE1VU1QgYmUgdXNlZC4gIEJUVywgcGxlYXNlIHB1dCB0aGUgcmVmZXJl bmNlIG9uIHRoZSBmaXJzdCBtZW50aW9uIG9mIFVVSUQuDQo= --_000_EE84C61E77304559852A4CFBF8543756ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <99985629E3655248A685CE44805C2928@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAg MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsN CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29Q bGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFp biBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpzcGFuLkVtYWlsU3R5bGUx Nw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNv bG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFs O30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQi Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+ DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPk9uIDEyLzI4LzE2LCAxMTo0MyBBTSwgJnF1b3Q7VGltIEJydWlqbnplZWxzJnF1b3Q7ICZs dDt0aW1AcmlwZS5uZXQmZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5U aW06PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhhcHB5IE5ldyBZZWFyISE8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij58IFRoYW5rIHlvdSBmb3IgeW91ciBpbi1kZXB0aCByZXZpZXcgOikgSXQg cmVhbGx5IGhlbHBzIHRvIGNsYXJpZnkgdGhlIGRvY3VtZW50LiBSZXBsaWVzIGluLWxpbmUuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IEkgYXR0YWNoZWQgYW4gdXBkYXRlZCBkb2N1bWVudCwg YnV0Li4gSSBkaWQgbm90IGRpc2N1c3MgdGhpcyB3aXRoIGNvLWF1dGhvcnMgeWV0LiBTbywgSSBp bnZpdGUgYW55IG9mIHRoZW0gdG8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+fCBkaXNhZ3JlZSBvciBzdWdnZXN0IGNoYW5nZXMgdG8gdGhlIHRoaW5ncyBiZWxvdy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhbmtzIGZvciB0aGF0LiZuYnNwOyBJIGhh dmUgc29tZSBjb21tZW50cyBiZWxvdyDigJMgSSB3YW50IHVzIHRvIGRpc2N1c3MgdGhlIFVwZGF0 ZSBpc3N1ZSAoTTE2KSBzbyB3ZSBjYW4gc3RhcnQgdGhlIElFVEYgTGFzdCBDYWxsLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFua3MhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPkFsdmFyby48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IE9uIDIwIERlYyAyMDE2LCBhdCAxNDox NSwgQWx2YXJvIFJldGFuYSAoYXJldGFuYSkgJmx0O2FyZXRhbmFAY2lzY28uY29tJmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPuKApjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCB8IE0yLiBTZWN0aW9uIDMuMi4gKENlcnRp ZmljYXRlIEF1dGhvcml0eSBVc2UpOiDigJxSZWx5aW5nIFBhcnRpZXMgdGhhdCBkbyBub3Qgc3Vw cG9ydCB0aGlzIGRlbHRhIHByb3RvY29sIE1VU1QNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+fCB8IE5PVCByZWplY3QgYSBDQSBjZXJ0aWZpY2F0ZSBtZXJlbHkgYmVj YXVzZSBpdCBoYXMgYW4gU0lBIGV4dGVuc2lvbiBjb250YWluaW5nIHRoaXMgbmV3IGtpbmQgb2YN CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCB8IEFjY2Vzc0Rlc2Ny aXB0aW9uLuKAnSZuYnNwOyZuYnNwO0J5IGRlZmluaXRpb24sIGFuIFJQIHRoYXQgaGFzIG5ldmVy IGV2ZW4gY29uc2lkZXJlZCB0aGlzIGRvY3VtZW50IHdpbGwgbm90IHN1cHBvcnQNCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCB8IHRoZSBkZWx0YSBwcm90b2NvbCDi gJMgSU9XLCB0cnlpbmcgdG8gc3BlY2lmeSB0aGUgYmVoYXZpb3Igb2YgUlBzIHRoYXQgbWF5IGhh dmUgbmV2ZXIgZXZlbiBzZWVuIHRoaXMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+fCB8IGRvY3VtZW50IG1ha2VzIG5vIHNlbnNlIHRvIG1lLCBhbmQgY2Fu4oCZdCBi ZSBlbmZvcmNlZC4mbmJzcDsmbmJzcDtXaGF0IGlzIHRoZSBjdXJyZW50IGJlaGF2aW9yIHdoZW4g YW4gUlAgcmVjZWl2ZXMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ fCB8IHRoZSBleHRyYSBTSUEgZXh0ZW5zaW9uPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+fDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCBU aGUgcG9pbnQgb2YgZG9jdW1lbnRpbmcgdGhpcyBpcyB0byBnaXZlIFJQIHNvZnR3YXJlIHRoZSBv cHRpb24gb2YgcmVjb2duaXNpbmcgdGhhdCBhIG5ldyBwcm90b2NvbCBleGlzdHMsDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwgZXZlbiBpZiB0aGV5IGRvIG5vdCBm dWxseSBzdXBwb3J0IGl0IHlldC4gSW4gcHJhY3RpY2UgYWxsIGN1cnJlbnQgUlBzIGRvIHRoaXMg KHNlZSBiZWxvdyksIGFuZCBmdXR1cmUgUlBzIHNob3VsZA0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij58IGNvbnNpZGVyIHRoaXMgZG9jdW1lbnQuIFdlIGhhdmUgaW4g ZmFjdCBiZWVuIHB1Ymxpc2hpbmcgdGhlc2UgYWRkaXRpb25hbCBTSUFzIGluIHRoZSBSSVBFIE5D QyBwcm9kdWN0aW9uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwg UlBLSSBmb3IgbW9yZSB0aGFuIGEgeWVhciB3aXRob3V0IHByb2JsZW1zLiBJIGNoYW5nZWQgaXQg c2xpZ2h0bHkgdG8gdGhpczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pnw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwgJnF1b3Q7UmVseWlu ZyBQYXJ0aWVzIHRoYXQgY2hvb3NlIG5vdCB0byBzdXBwb3J0IHRoaXMgZGVsdGEgcHJvdG9jb2wg eWV0LCBNVVNUIE5PVCByZWplY3QgYSBDQSBjZXJ0aWZpY2F0ZSBtZXJlbHkNCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCBiZWNhdXNlIGl0IGhhcyBhbiBTSUEgZXh0 ZW5zaW9uIGNvbnRhaW5pbmcgdGhpcyBuZXcga2luZCBvZiBBY2Nlc3NEZXNjcmlwdGlvbi4mcXVv dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwgQnV0LCBJIGNhbiBhbHNvIGxpdmUgd2l0aCB0 YWtpbmcgdGhpcyBzZW50ZW5jZSBvdXQgYWx0b2dldGhlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+SSB3b3VsZCBwcmVmZXIgaXQgaWYgd2UgZG8gdGhhdC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij7igKY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwgfCBNNC4g RnJvbSAzLjMuMi4gKFB1Ymxpc2hpbmcgVXBkYXRlcyk6IOKAnFRoZSB1cGRhdGUgbm90aWZpY2F0 aW9uIGZpbGUgU0hPVUxEIGJlIGtlcHQgc21hbGzigKZvbGRlciBkZWx0YSBmaWxlcw0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IHwgdGhhdOKApndpbGwgcmVzdWx0 IGluIHRvdGFsIHNpemUgb2YgZGVsdGFzIGV4Y2VlZGluZyB0aGUgc2l6ZSBvZiB0aGUgc25hcHNo b3QsIE1VU1QgYmUgZXhjbHVkZWQu4oCdJm5ic3A7Jm5ic3A7SGVyZSB0aGUNCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCB8IOKAnFNIT1VMROKAnSBhbmQgdGhlIOKA nE1VU1TigJ0gYXJlIGluIGNvbnRyYWRpY3Rpb246IHlvdSBlaXRoZXIgZG8gaXQgYWx3YXlzIChN VVNUKSBvciB0aGVyZSBtYXkgYmUgY2FzZXMgd2hlbg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij58IHwgeW91IGRvbuKAmXQgKFNIT1VMRCkuJm5ic3A7Jm5ic3A7cy9T SE9VTEQvc2hvdWxkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IE9rLCBJIG1vdmVkIHRoZSBm aWxlIHNpemUgY29uY2VybiB0byB0aGUgbmV4dCBidWxsZXQgcG9pbnQgaW5zdGVhZCwgc28gdGhh dCB3ZSBoYXZlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCBvIEFueSBvbGRlciBkZWx0YSBm aWxlcyB0aGF0LCB3aGVuIGNvbWJpbmVkIHdpdGggYWxsIG1vcmUgcmVjZW50IGRlbHRhIGZpbGVz LCB3aWxsIHJlc3VsdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCZu YnNwOyZuYnNwOyBpbiBhIHRvdGFsIHNpemUgb2YgZGVsdGFzIGV4Y2VlZGluZyB0aGUgc2l6ZSBv ZiB0aGUgc25hcHNob3QsIE1VU1QgYmUgZXhjbHVkZWQgdG8gYXZvaWQ8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwmbmJzcDsmbmJzcDsgdGhhdCBSUHMgZG93bmxvYWQg bW9yZSBkYXRhIHRoYW4gbmVjZXNzYXJ5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+fDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCBvIFRo ZSBzZXJ2ZXIgTUFZIGFsc28gZXhjbHVkZSBtb3JlIHJlY2VudCBkZWx0YSBmaWxlcyBpZiBpdCBm aW5kcyB0aGF0IHRoZWlyIHVzYWdlIGJ5IGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPnwmbmJzcDsmbmJzcDsgc21hbGwgbnVtYmVyIG9mIFJQcyB0aGF0IHdvdWxkIGJl IGZvcmNlZCB0byBwZXJmb3JtIGEgZnVsbCBzeW5jaHJvbmlzYXRpb24gaXMgb3V0d2VpZ2hlZDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCZuYnNwOyZuYnNwOyBwZXJm b3JtYW5jZSBiZW5lZml0cyBvZiBoYXZpbmcgYSBzbWFsbGVyIHVwZGF0ZSBub3RpZmljYXRpb24g ZmlsZS4gSG93ZXZlciwgdGhlIHJlcG9zaXRvcnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPnwmbmJzcDsmbmJzcDsgc2VydmVyIE1VU1QgaW5jbHVkZSBhbGwgZGVsdGFz IHRoYXQgaXQgaGFzIGF2YWlsYWJsZSBmb3IgdGhlIGxhc3QgdHdvIGhvdXJzLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+fCBJIGhvcGUgdGhhdCBleHBsYWlucyBpdCBiZXR0ZXIuIEkgY2hhbmdl ZCB0aGUgU0hPVUxEIGluIHRoZSBzZWNvbmQgYnVsbGV0IHBvaW50IHRvIGEgTVVTVC4gVGhlIHVu c3Bva2VuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwgcmVhc29u IGZvciB0aGUgU0hPVUxEIHdhcyB0aGF0IGEgcHVibGljYXRpb24gc2VydmVyIG1heSBub3QgaGF2 ZSBkZWx0YXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBwcm9ibGVtIHRoYXQg SSB0aGluayBjYW4gc3RpbGwgZXhpc3QgaXMgdGltZSBkZXBlbmRlbnQ6Jm5ic3A7IOKAnG9sZGVy IGRlbHRhIGZpbGVz4oCmTVVTVCBiZSBleGNsdWRlZOKApk1VU1QgaW5jbHVkZSBhbGwgZGVsdGFz IHRoYXQgaXMgaGFzIGF2YWlsYWJsZSBmb3IgdGhlIGxhc3QgdHdvIGhvdXJz4oCdLiZuYnNwOyBX aGF0IGhhcHBlbnMgaWYgYWxsIOKAnG9sZGVyIGRlbHRhIGZpbGVz4oCdIGFyZSBsZXNzIHRoYW4g dHdvIGhvdXJzDQogb2xkLCBidXQgdGhlIHNpemUgd291bGQgYmUgdG9vIGJpZz8mbmJzcDsgSXMg dGhlcmUgdGhlIHBvc3NpYmlsaXR5IG9mIGEgY2FzZSB3aGVyZSB0aGVyZSBhcmUgYSBsb3Qgb2Yg Y2hhbmdlcyB0aGF0IGhhcHBlbiBjbG9zZSB0b2dldGhlciAoYnV0IG1vcmUgdGhhbiBhIG1pbnV0 ZSBhcGFydCkgdGhhdCB3b3VsZCB0aGVuIHJlc3VsdCBpbiBtYW55IGRlbHRhIGZpbGVzPyZuYnNw OyBCZXNpZGVzIG5vdCBwb3N0cG9uaW5nIHB1YmxpY2F0aW9uIGZvciBtb3JlIHRoYW4NCiBhIG1p bnV0ZSwgSSBkb27igJl0IHJlbWVtYmVyIG90aGVyIG1lY2hhbmlzbXMgdGhhdCB3b3VsZCBhdm9p ZCBhIGxhcmdlIG51bWJlciBvZiBjaGFuZ2Vz4oCmJm5ic3A7IElmIHRoaXMgY2FzZSBpcyBub3Qg cG9zc2libGUsIHRoZW4gd2Ugc2hvdWxkIGJlIG9rIOKAkyBJIHdvdWxkIHN0aWxsIGxpa2UgdG8g dW5kZXJzdGFuZCB3aHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+4oCmPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IHwgTTcuIDMuNC4xLiAoUHJvY2Vzc2luZyB0aGUgVXBk YXRlIE5vdGlmaWNhdGlvbiBGaWxlKTog4oCcTVVTVCBpc3N1ZSBhbiBvcGVyYXRvciBlcnJvcuKA nSZuYnNwOyZuYnNwO1doYXQgaXMgYW4g4oCcb3BlcmF0b3INCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+fCB8IGVycm9y4oCdIGFuZCBob3cgZG8geW91IGlzc3VlIG9u ZT8mbmJzcDsmbmJzcDtJIGRpZG7igJl0IHNlZSBhbiBlcnJvciBkZWZpbml0aW9uIGluIHRoZSBz Y2hlbWEuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IEkgc2VlIHlvdXIgcG9pbnQsIGJ1dC4u IGFmYWlrIG5vbmUgb2YgdGhlIG90aGVyIHNpZHIgUkZDcyBhbmQgSS1EcyBkZWZpbmUgdGhpcywg YW5kIGp1c3QgYXZvaWQgdGFsa2luZyBhYm91dCB0aGlzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPnwgYWx0b2dldGhlci4gVGhpcyB3YXMgdW5kZWZpbmVkIGluIG92 ZXIgZml2ZSB5ZWFycyBvZiBkZXBsb3ltZW50IHdpdGggcnN5bmMsIGFuZCB5ZXQgb3BlcmF0aW9u YWwgaXNzdWVzIHdpdGgNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ fCByc3luYyBhbHNvIGhhcHBlbiBhbmQgZ2V0IHJlcG9ydGVkIGFuZCByZXNvbHZlZCBzb21laG93 LiBJbiBzaG9ydCBJIHN1Z2dlc3QgdGhhdCBJIGp1c3QgbGVhdmUgaXQgb3V0IGhlcmUgYXMNCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCB3ZWxsLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5Oby4mbmJzcDsgU29ycnksIGJ1dCDigJxPdGhlcnMgZGlkbuKA mXQgZG8gaXTigJ0gaXMgbm90IGEgdmFsaWQgcmVhc29uIGZvciBhbiBpbmNvbXBsZXRlIHNwZWNp ZmljYXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwgQnV0IHRvIGNvbnRpbnVl OiBBbGwgUlBzIGRvIGhhdmUgdGhlIGNvbW1vbiBzZW5zZSB0byBpbmZvcm0gdGhlaXIgdXNlcnMg YWJvdXQgaXNzdWVzIChlLmcuIGFsc28gdGhpbmdzIGxpa2U6DQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPnwgaGV5LCB0aGlzIGNlcnRpZmljYXRlIGlzIGludmFsaWQg YmVjYXVzZS4uKSwgYnV0IHRoZXJlIGlzIG5vIHN0YW5kYXJkIGRlZmluZWQsIHNvIHRoZXkgdXNl IHZhcmlvdXMgZm9ybWF0cyBhbmQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+fCB3YXlzLiBJIGRvIHNlZSBzb21lIGJlbmVmaXQgaW4gZGVmaW5pbmcgYXQgbGVhc3Qg YSBjb21tb24gc3RhbmRhcmQgYmVjYXVzZSBpdCBtaWdodCBoZWxwICgxKSBtb25pdG9yaW5nLCAo MikNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCBub3JtYXRpdmUg ZG9jdW1lbnRpbmcgb2YgZXJyb3IgY29uZGl0aW9ucyBhbmQgcmVzcG9uc2VzLCBhbmQgKDMpIGlu dGVyb3AgdGVzdGluZyBiZXR3ZWVuIFJQcyAoUm9iLCBEYXZpZA0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IGFuZCBJIGhhdmUgZG9uZSB0aGlzIGEgZmV3IHRpbWVz IGFuZCBpdCdzIGEgYml0IG9mIGEgaGFzc2xlKS4gRG9pbmcgc28gaXMgaW1vIG1ham9yIHdvcmsg YW5kIHNvbWV0aGluZyBmb3IgYQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij58IHNlcGFyYXRlIHNpZHItb3BzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5PbmUgb2YgdGhlIHJlYXNvbnMgSSBhZGRlZCB0aGlzIGNvbW1lbnQgaXMgYmVjYXVz ZSBpdCB1c2VzIGEg4oCcTVVTVOKAnTogeW914oCZcmUgbWFuZGF0aW5nIHRoZSBiZWhhdmlvciBh cyBwYXJ0IG9mIHRoZSBzcGVjaWZpY2F0aW9uLiZuYnNwOyBJZiBpdCBpcyBhIG1hbmRhdG9yeSBi ZWhhdmlvciwgdGhlbiB0aGVyZSBzaG91bGQgYmUgc29tZXRoaW5nIHRoYXQgZ29lcyB3aXRoIGlz IGFzIHRvIGhvdyBpdCBpcyBkb25lLiZuYnNwOw0KIE9uZSB3YXkgZm9yd2FyZCBpcyB0byBjbGFy aWZ5IHdoYXQgeW91IG1lYW4gYnkgYW4g4oCcb3BlcmF0b3IgZXJyb3LigJ0sIHdoaWNoIChpbnRl cnByZXRpbmcgdGhlIHBhcmFncmFwaCBhYm92ZSkgaXMgcmVhbGx5IGEgbG9nIG1lc3NhZ2UuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgYW0gZmluZSAoaWYgeW91IHdhbnQgdG8gbWFu ZGF0ZSB0aGUgYmVoYXZpb3IpIGZvciB5b3UgdG8gc2F5IHNvbWV0aGluZyBsaWtlOiDigJxNVVNU IGxvZyB0aGUgY29uZGl0aW9uIGZvciB0aGUgb3BlcmF0b3IgdG8gYmUgYXdhcmUgb2YgdGhlIHBy b2JsZW3igJ0uJm5ic3A7IE5vIG5lZWQgdG8gc3BlY2lmeSB0aGUgY29udGVudHMsIGEgY29tbW9u IGZvcm1hdCwgZXRjLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgYWdyZWUgdGhh dCBpZiB5b3UgZGlkIHdhbnQgdG8gZGVmaW5lIGNvbW1vbiBmb3JtYXRzLCBjb250ZW50cywgZXRj LiB0aGVuIHRoYXQgd291bGQgYmVsb25nIHNvbWV3aGVyZSBlbHNlLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPuKApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCBTZWUgc2Vj dGlvbiAzLjQuNSBvZiBhdHRhY2hlZCBmaWxlIGZvciBjbGFyaWZpY2F0aW9ucyB0aGF0IEkgdGhp bmsgd2UgY2FuIGRvIGluIHRoZSBjb250ZXh0IG9mIHRoaXMgZG9jdW1lbnQuDQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwgRm9sbG93aW5nIHlvdXIgcHJldmlvdXMg cmVtYXJrIHRoZSBvbmx5IG5vcm1hdGl2ZSBhZGRpdGlvbiBJIGZlZWwgSSBjYW4gYWRkIGlzIHRo aXM6ICZxdW90O0luIG9yZGVyIHRvIGhlbHAgcHJldmVudA0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij58IHRoaXMgUHVibGljYXRpb24gU2VydmVycyBNVVNUIHBlcmZv cm0gcmVndWxhciB2YWxpZGF0aW9uIG9mIHRoZWlyIG93biBSUkRQIHJlcG9zaXRvcnkuJnF1b3Q7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBuZXcgc2VjdGlvbiBsb29rcyBvaywg ZXhjZXB0IGZvciB0aGUgcGFyYWdyYXBoIHRoYXQgc2F5czog4oCcVGhpcyBwcm90b2NvbCBkb2N1 bWVudCBjYW5ub3QgZGVmaW5lIG5vcm1hdGl2ZSB0ZXh04oCm4oCdJm5ic3A7IE5vIG5lZWQgdG8g cHV0IHRoYXQgaW4gaGVyZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IHwgTTExLiBGcm9t IDMuNC4zLiAoUHJvY2Vzc2luZyBEZWx0YSBGaWxlcyk6IOKAnGl0IGlzIFJFQ09NTUVOREVEIHRo YXQgYSBSUCB1c2VzIGFkZGl0aW9uYWwgc3RyYXRlZ2llcyB0bw0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IHwgZGV0ZXJtaW5lIGlmIGFuIG9iamVjdCBpcyBzdGls bCByZWxldmFudCBmb3IgdmFsaWRhdGlvbiBiZWZvcmUgcmVtb3ZpbmcgaXQgZnJvbSBpdHMgbG9j YWwgc3RvcmFnZeKAnS4mbmJzcDsmbmJzcDtPaywgbGlrZQ0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij58IHwgd2hhdD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPnw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwg SSB0aGluayBnb2luZyBpbnRvIHRvbyBtdWNoIGRldGFpbCBpcyBvdXQgb2Ygc2NvcGUgYmVjYXVz ZSBpdCBjYW5ub3QgYmUgZXhwbGFpbmVkIHdpdGhvdXQgaGF2aW5nIGEgZG9jdW1lbnQNCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCBmb3JtYWxseSBkZXNjcmliaW5n IHZhbGlkYXRpb24gc3RyYXRlZ2llcy4gQnV0IEkgYWRkZWQgdGhpczo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPnwgSW4gcGFydGljdWxhciBvYmplY3RzIHNob3VsZCBub3QgYmUgcmVtb3ZlZCBp ZiB0aGV5IGFyZSBpbmNsdWRlZCBpbiBhIGN1cnJlbnQgdmFsaWRhdGVkIG1hbmlmZXN0LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Pay4mbmJzcDsgQXMgYmVmb3JlLCB0aGUgcmVhc29u IGZvciB0aGUgY29tbWVudCBpcyB0aGUgdXNlIG9mIOKAnFJFQ09NTUVOREVE4oCdLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPuKApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ fCB8IE0xNi4gU2VjdGlvbiA1LiAoU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMpOiDigJxSUkRQIHJl cGxhY2VzIHRoZSB1c2Ugb2YgcnN5bmMgYnkgSFRUUFPigKbigJ0uIEdpdmVuIHRoZQ0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IHwgc3RhdGVtZW50IGluIDMuNC4x IGFib3V0IHVzaW5nIOKAnGFuIGFsdGVybmF0ZSByZXBvc2l0b3J5IHJldHJpZXZhbCBtZWNoYW5p c23igJ0gYW5kIHRoZSByZXN0IG9mIHRoZSB0ZXh0IGluIHRoaXMNCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCB8IHNlY3Rpb24sIEkgd291bGQgYXNzdW1lIHRoYXQg dGhlIGludGVudCBpcyBub3QgcmVhbGx5IHRvIOKAnHJlcGxhY2UgdGhlIHVzZSBvZiByc3luY+KA nSAod2l0aCBhbiB1cGRhdGUgdG8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+fCB8IFJGQzY0ODApLiZuYnNwOyZuYnNwOyBNYXliZSBJ4oCZbSByZWFkaW5nIHRvbyBt dWNoIGludG8gdGhlIHBocmFzZSBhYm92ZSwgYnV0IHBsZWFzZSBjbGFyaWZ5LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+fCBBcyBleHBsYWluZWQgYWJvdmUgaXQgaXMgdGhlIGludGVudCB0byBy ZXBsYWNlIHJzeW5jLiBCdXQuLiBhIG1pZ3JhdGlvbiBkb2N1bWVudCBzaG91bGQgYmUgd3JpdHRl biBhcyBhDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwgc2VwYXJh dGUgZWZmb3J0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCBUaGF0IHNhaWQgSSB3b3VsZCBi ZSBmaW5lIHdpdGgganVzdCB0YWtpbmcgb3V0OiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPnw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUgb3JpZ2luYWwgUlBLSSB0cmFuc3BvcnQg bWVjaGFuaXNtIGlzIHJzeW5jLCB3aGljaCBvZmZlcnMgbm8gY2hhbm5lbDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O3NlY3VyaXR5IG1lY2hhbmlzbS4gUlJEUCByZXBsYWNlcyB0aGUgdXNlIG9mIHJzeW5jIGJ5IEhU VFBTOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCBQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91 IHByZWZlciB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkxldCBtZSB0cnkgdG8gbWFrZSB0aGUg cG9pbnQgYWdhaW4g4oCTIEkgZGlkbuKAmXQgZG8gYSBnb29kIGpvYiBhYm92ZS4mbmJzcDsgSW4g ZmFjdCwgcmVhZGluZyB0aGlzIG92ZXIgSSB3YW50IHRvIGNoYW5nZSBpdOKApjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5JbiB0aGlzIGRvY3VtZW50IHlvdeKAmXJlIHNheWluZzogaGVy ZeKAmXMgYSBuZXcgcHJvdG9jb2wgdGhhdCBTSE9VTEQgYmUgdXNlZCBpbnN0ZWFkIG9mIHJzeW5j ICgzLjQuMSkuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QW5kLCBhcyB5 b3UgbWVudGlvbmVkIGFib3ZlLCB0aGUgaW50ZW50IGlzIHRvIGV2ZW50dWFsbHkgcGhhc2Ugb3V0 IHJzeW5jIGluIGZhdm9yIG9mIFJSRFAuJm5ic3A7IFRpbWUgbGluZXMgdG8gcGhhc2UgaXQgb3V0 IGFyZSByZWFsbHkgb3V0IG9mIHRoZSBzY29wZSBvZiB0aGlzIChvciBJIHRoaW5rIGFueSBvdGhl ciBSRkMpIGRvY3VtZW50IGJlY2F1c2UgaXQgaXMgc29tZXRoaW5nIHRoZSBSUEtJIGNvbW11bml0 eQ0KIGFncmVlcyBvbiBhbmQgbWlncmF0ZXMgdG8sIGp1c3QgbGlrZSBhbnkgb3RoZXIgbmV3IHBy b3RvY29sLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BbGwgdGhhdCBpcyBnb29kLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Ib3dldmVyLCBib3RoIFJGQzY0ODAgYW5kIFJG QzY0ODEgbWFuZGF0ZSB0aGUgdXNlIG9mIHJzeW5jOiDigJxhbGwgcHVibGljYXRpb24gcG9pbnRz IE1VU1QgYmUgYWNjZXNzaWJsZSB2aWEgcnN5bmPigJ0gYW5kIOKAnHB1YmxpY2F0aW9uIHJlcG9z aXRvcnkgTVVTVCBiZSBhdmFpbGFibGUgdXNpbmcgcnN5bmPigJ0uJm5ic3A7IFdoaWNoIG1lYW5z IHRoYXQgdG8gY29tcGx5IHdpdGggdGhlIFJQS0kgYXJjaGl0ZWN0dXJlIHJzeW5jDQogTVVTVCBi ZSBzdXBwb3J0ZWQgZm9yZXZlciwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIFJSRFAgaXMgdXNlZCwg b3IgYSBkaWZmZXJlbnQgcHJvdG9jb2wgdGhhdCBtYXkgY29tZSBhbG9uZyBpbiB0aGUgZnV0dXJl 4oCmb3IgZXZlbiBpZiBpdCBpcyBub3QgbmVlZGVkIGF0IGFsbCBhbnltb3JlIChub3QgZXZlbiBm b3IgZXZlbnR1YWwgYmFja3VwKS4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3Mi Pkw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBxdWVzdGlvbiBhYm91 dCB1cGRhdGluZyBSRkM2NDgwIGFib3ZlIHNob3VsZCBoYXZlIGJlZW4gYSBzdGF0ZW1lbnQ6IHRo aXMgZG9jdW1lbnQgc2hvdWxkIHVwZGF0ZSBSRkM2NDgwL1JGQzY0ODEgc28gdGhhdCByc3luYyBp cyBub3QgcmVxdWlyZWQgYW55bW9yZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q2hh bmdpbmcgdGhlIHRleHQgaW4gUkZDNjQ4MC9SRkM2NDgxIHRvIHNheSDigJxNVVNUIHVzZSBSUkRQ 4oCdIHdvdWxkIGp1c3QgcmVzdWx0IGluIGFub3RoZXIgdXBkYXRlIGxhdGVyIGlmIGFub3RoZXIg cHJvdG9jb2wgZXZlciBjb21lcyBhbG9uZywgc28gSSB0aGluayB0aGlzIGRvY3VtZW50IHNob3Vs ZCBiZSBleHBsaWNpdCBpbiB0aGUgY2hhbmdlICh0byBhbGxvdyB0aGUgbW92ZSBhd2F5IGZyb20g cnN5bmMpLA0KIGJ1dCBzdGlsbCBnZW5lcmlj4oCmZm9yIGV4YW1wbGUsIHRoZSB0ZXh0IGluIFJG QzY0ODAvUkZDNjQ4MSBjYW4gYmUgcmVwbGFjZWQgd2l0aCBzb21ldGhpbmcgbGlrZTog4oCcVGhl IHB1YmxpY2F0aW9uIHBvaW50IE1VU1QgYmUgYWNjZXNzaWJsZSB1c2luZyBhIHJldHJpZXZhbCBt ZWNoYW5pc20gY29uc2lzdGVudCB3aXRoIHRoZSBhY2Nlc3NNZXRob2QgZWxlbWVudCB2YWx1ZShz KS4mbmJzcDsgTXVsdGlwbGUgcmV0cmlldmFsIG1lY2hhbmlzbXMgY2FuIGJlIHN1cHBvcnRlZA0K IGF0IHRoZSByZXBvc2l0b3J5IG9wZXJhdG9y4oCZcyBkaXNjcmV0aW9u4oCdLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5BIGNoYW5nZSBsaWtlIHRoYXQgd291bGQgcmVxdWlyZSB0aGF0 IHRoaXMgZG9jdW1lbnQgYmUgdGFnZ2VkIHRvIFVwZGF0ZSBSRkM2NDgwL1JGQzY0ODEgKGFuZCB3 b3VsZCBvZiBjb3Vyc2UgcmV0dXJuIFJGQzY0ODEgdG8gYmUgTm9ybWF0aXZlKS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PuKApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCB8IFA0LiDigJx2 ZXJzaW9uIDQgVVVJROKAnSZuYnNwOyZuYnNwO1BsZWFzZSBwcm92aWRlIGEgcmVmZXJlbmNlLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCBhY2ssIEkgYXNzdW1lZCBpbmZvcm1hdGl2ZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Tm9ybWF0aXZlLCBiZWNhdXNlIHRoZSBkb2N1bWVu dCBzYXlzIHRoYXQgaXQgTVVTVCBiZSB1c2VkLiZuYnNwOyBCVFcsIHBsZWFzZSBwdXQgdGhlIHJl ZmVyZW5jZSBvbiB0aGUgZmlyc3QgbWVudGlvbiBvZiBVVUlELjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_EE84C61E77304559852A4CFBF8543756ciscocom_-- From nobody Fri Jan 6 15:10:21 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CA812969B; Fri, 6 Jan 2017 15:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 4MhYRmdsXBiI; Fri, 6 Jan 2017 15:10:19 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33FD812968F; Fri, 6 Jan 2017 15:10:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18996; q=dns/txt; s=iport; t=1483744219; x=1484953819; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Mszwsp30dwU55hh43k3bpobeSSSwz1TSkkwQtIogL/Y=; b=eitqy0x3I5DyKDO1Sq7QJgiNWcB8Uy7QCMYCLmltattDRUObD/tinUoW dcrqWf33Qx+bICh353YVT3i1aTE5IGppIF5SHwYtaW3E/SAKTtct8YkBg oYxI2q669lWueB2pb7X7NdFcyx3nPDF8ZJxVMgCHP2wBguoBeMYy7y3Pc c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQDuInBY/4UNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnFIAQEBAQEfX4EMB41Qoh6FKoIJhiICGoE8PxQBAgEBAQEBAQF?= =?us-ascii?q?jKIRpBiNWEAIBCEICAgIwJQIEAQ0FH4hRsDmCJSuJdAEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2GRYICCIJXh04tgjEFlRqFewGRRoF3hQiJXIgJikcBHziBPBU1DwG?= =?us-ascii?q?EGRyBX3OHWYENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,326,1477958400"; d="scan'208,217";a="369579132" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jan 2017 23:10:18 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v06NAISf024765 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Jan 2017 23:10:18 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 6 Jan 2017 17:10:17 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Fri, 6 Jan 2017 17:10:17 -0600 From: "Alvaro Retana (aretana)" To: "Sriram, Kotikalapudi (Fed)" , Keyur Patel Thread-Topic: draft-ietf-sidr-bgpsec-protocol Thread-Index: AQHSaHILNfH8MXPYLkOmxwl9coeqvw== Date: Fri, 6 Jan 2017 23:10:17 +0000 Message-ID: <6C8E073D-F1AB-4588-8DFF-FAA0A2465273@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: multipart/alternative; boundary="_000_6C8E073DF1AB45888DFFFAA0A2465273ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sidr-chairs@ietf.org" , "mlepinski@ncf.edu" , sidr Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 23:10:21 -0000 --_000_6C8E073DF1AB45888DFFFAA0A2465273ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gMS82LzE3LCAxMjo0MCBBTSwgIlNyaXJhbSwgS290aWthbGFwdWRpIChGZWQpIiA8a290aWth bGFwdWRpLnNyaXJhbUBuaXN0Lmdvdj4gd3JvdGU6DQoNCg0KDQpbQ3V0IHRoZSBkaXN0cmlidXRp b24gbGlzdCBhIGxpdHRsZS5dDQoNCg0KDQpTcmlyYW06DQoNCg0KDQpIaSEgIEhhcHB5IE5ldyBZ ZWFyIQ0KDQoNCg0KSSBoYXZlIHNvbWUgY29tbWVudHMgb24gdGhpcywgcGxlYXNlIHNlZSBiZWxv dy4NCg0KDQoNClRoYW5rcyENCg0KDQoNCkFsdmFyby4NCg0KDQoNCg0KDQrigKYNCg0KfCB8IDEp ICBTZWN0aW9uIDQuMSDigJxUaGUgQkdQc2VjIFBhdGggYXR0cmlidXRlIGFuZCB0aGUgQVNfUEFU SCBhdHRyaWJ1dGUgYXJlIG11dHVhbGx5DQoNCnwgfCBleGNsdXNpdmUuIFRoYXQgaXMsIGFueSB1 cGRhdGUgbWVzc2FnZSBjb250YWluaW5nIHRoZSBCR1BzZWMgUGF0aCBhdHRyaWJ1dGUgTVVTVCBO T1QNCg0KfCB8IGNvbnRhaW4gdGhlIEFTX1BBVEggYXR0cmlidXRl4oCdLiAgRm9yIGFueSByZXN0 YXJ0aW5nIHNwZWFrZXJzIGluIGEgR1IgbW9kZSwgd2hlcmUgdGhlIGJncA0KDQp8IHwgY2FwYWJp bGl0eSBpcyBub3QgZXhjaGFuZ2VkLCB0aGUgZXhpc3Rpbmcgc3RhbGUgcm91dGVzIHdvbuKAmXQg aGF2ZSBhbiBBU19QQVRIIGF0dHJpYnV0ZS4gV2UNCg0KfCB8IGNvdWxkIGFkZCBzb21lIGNsYXJp ZnlpbmcgdGhhdCBoZWxwcyB0byBpbmRpY2F0ZSB0aGF0IHN1Y2ggcm91dGVzIHNob3VsZCBiZSBj b25zaWRlcmVkDQoNCnwgfCB2YWxpZCBpbiBzdGFsZSBtb2RlICh0aWxsIHRoZXkgZ2V0IHJlZnJl c2hlZCk/DQoNCnwNCg0KfCBbU3JpcmFtXSAgQXMgeW91IGhhdmUgY2xhcmlmaWVkIGZvciBtZSBv biB0aGUgcGhvbmUsIHdoYXQgeW91IGFyZSBzYXlpbmcgaGVyZSBpcyB0aGF0IHRoZQ0KDQp8IHR3 byBCR1BzZWMgcGVlcnMgbG9zdCB0aGUgQkdQc2VjIHNlc3Npb24gYW5kIG5vdyByZXN0YXJ0aW5n IGluIEdSIG1vZGUsIGJ1dCB0aGV5IGhhdmUgbm90DQoNCnwgZXhjaGFuZ2VkIEJHUHNlYyBjYXBh YmlsaXR5IHRoaXMgdGltZS4gSGVuY2UsIHRoZXkgYXJlIG5vdyBzaW1wbGUgQkdQIChub24tQkdQ c2VjKSBwZWVycw0KDQp8IGluIEdSIG1vZGUuIFJGQzQyNzEgY29uc2lkZXJzIHVwZGF0ZSBtZXNz YWdlIHJlY2VpdmVkIHdpdGhvdXQgYSB3ZWxsLWtub3duIEFTX1BBVEgNCg0KfCBhdHRyaWJ1dGUg YXMgYW4gZXJyb3IsIGFuZCB1bmZvcnR1bmF0ZWx5IGluIHRoaXMgY2FzZSB0aGUgY2FjaGVkIEJH UHNlYyB1cGRhdGVzIGRvIG5vdCBoYXZlDQoNCnwgQVNfUEFUSCAoYWxiZWl0IHRoZXkgaGF2ZSBC R1BzZWNfUGF0aCkuIFNvIHlvdSBhcmUgc2F5aW5nICJ0aGUgcm91dGVyIHNob3VsZCBub3QgcGFu aWMiDQoNCnwgYW5kIGluc3RlYWQgc2ltcGx5IHRyZWF0IGVhY2ggY2FjaGVkIHVwZGF0ZSBhcyBO T1QtSU4tRVJST1IgZXZlbiB0aG91Z2ggaXQgaXMgbWlzc2luZw0KDQp8IEFTX1BBVEggYXR0cmli dXRlLiBUaGlzIHdheSB0aGUgR1IgY2FuIHdvcmsgcHJvcGVybHkuIE9mIGNvdXJzZSwgc2hvcnRs eSB0aGUgdXBkYXRlcyB3aWxsDQoNCnwgaGF2ZSBBU19QQVRIIChhbmQgbm90IGNvbnNpZGVyZWQg aW4gZXJyb3IpIHdoZW4gdGhleSBnZXQgcmVmcmVzaGVkIChvdmVyIHRoZSBuZXcgc2ltcGxlDQoN CnwgQkdQIHNlc3Npb24pLiBQZXIgeW91ciBzdWdnZXN0aW9uLCBJIHdpbGwgaW5jbHVkZSBuZXcg dGV4dCBpbiBTZWN0aW9uIDcgdG8gZGVzY3JpYmUgdGhpcw0KDQp8IHJlcXVpcmVkIGJlaGF2aW9y IGZvciB0aGUgR1IgbW9kZS4NCg0KDQoNCkkgZG9u4oCZdCBoYXZlIGFuIG9iamVjdGlvbiBmb3Ig dGhpcyBiZWhhdmlvciwgYnV0IEkgdGhpbmsgd2Ugc2hvdWxkIG1ha2UgdGhlIFdHIChhbmQgaWRy ISkgYXdhcmUgb2YgdGhlIGNoYW5nZSBhbmQgZ2V0IHRoZWlyIGNvbW1lbnRzIChpZiBhbnkpIGJl Zm9yZSBJIGFwcHJvdmUgdGhlIHB1YmxpY2F0aW9uLg0KDQoNCg0KDQoNCuKApg0KDQp8IHwgMykg IFNlY3Rpb24gNSBhbmQgU2VjdGlvbiA1LjIsIDFzdCBwYXJhZ3JhcGg6IFJGQzQyNzEgY29uc2lk ZXJzIHVwZGF0ZSBtZXNzYWdlIHJlY2VpdmVkDQoNCnwgfCB3aXRob3V0IGEgd2VsbC1rbm93biBB U19QQVRIIGF0dHJpYnV0ZSBhcyBhbiBlcnJvci4gIFdlIG5lZWQgc29tZSB0ZXh0IHRvIGNsYXJp ZnkgdGhlDQoNCnwgfCAoZXJyb3IgaGFuZGxpbmcgaWYgYW55KSBiZWhhdmlvciB3aGVuIGFuIHVw ZGF0ZSBtZXNzYWdlIGlzIHJlY2VpdmVkIHdpdGhvdXQgYSBiZ3BzZWMgYW5kDQoNCnwgfCBhbiBh c3BhdGggYXR0cmlidXRlLiBUaGUgY3VycmVudCBkcmFmdCB0ZXh0IHNlZW1zIHVuY2xlYXIgYWJv dXQgZ2VuZXJhdGlvbiBvZiBiZ3BzZWMNCg0KfCB8IGF0dHJpYnV0ZSBhcyB3ZWxsIChpbiBhIGli Z3Agc2NlbmFyaW8pLiBJcyBpdCBhIHJlcXVpcmVtZW50IHRvIGdlbmVyYXRlIGFuIGVtcHR5IGJn cHNlYw0KDQp8IHwgYXR0cmlidXRlPw0KDQp8DQoNCnwgW1NyaXJhbV0gIEFzIHlvdSBoYXZlIGNs YXJpZmllZCBmb3IgbWUgb3ZlciB0aGUgcGhvbmUsIFJGQyA0MjcxIChwYWdlIDI2KSBzYXlzIHRo ZQ0KDQp8IGZvbGxvd2luZyA6DQoNCnwNCg0KfCAgIldoZW4gYSBCR1Agc3BlYWtlciBvcmlnaW5h dGVzIGEgcm91dGUgdGhlbjoNCg0KfCAgIGIpIHRoZSBvcmlnaW5hdGluZyBzcGVha2VyIGluY2x1 ZGVzIGFuIGVtcHR5IEFTX1BBVEggYXR0cmlidXRlIGluDQoNCnwgICAgICAgIGFsbCBVUERBVEUg bWVzc2FnZXMgc2VudCB0byBpbnRlcm5hbCBwZWVycy4gIChBbiBlbXB0eSBBU19QQVRIDQoNCnwg ICAgICAgICBhdHRyaWJ1dGUgaXMgb25lIHdob3NlIGxlbmd0aCBmaWVsZCBjb250YWlucyB0aGUg dmFsdWUgemVybykuIg0KDQp8DQoNCnwNCg0KfCBbU3JpcmFtXSAgU28gd2hhdCBuZWVkcyB0byBi ZSBzYWlkIGluIHRoZSBCR1BzZWMgZG9jdW1lbnQgaXMgdGhlIGZvbGxvd2luZzogIFRoZQ0KDQp8 IEJHUHNlY19QYXRoIGF0dHJpYnV0ZSBpcyBub3QgYXR0YWNoZWQgaW4gdXBkYXRlcyBvcmlnaW5h dGVkIGluc2lkZSBhbiBBUyBhbmQgcHJvcGFnYXRlZCB0bw0KDQp8IEJHUHNlYyBjYXBhYmxlIGlu dGVybmFsIHBlZXJzLiBIb3dldmVyLCB3aGVuIGEgcm91dGUgaXMgb3JpZ2luYXRlZCBpbnNpZGUg YW4gQVMgYW5kDQoNCnwgcHJvcGFnYXRlZCB0byBub24tQkdQc2VjIGludGVybmFsIHBlZXJzLCBh biBlbXB0eSBBU19QQVRIIGF0dHJpYnV0ZSBpcyBpbmNsdWRlZCBpbiB0aGUNCg0KfCB1cGRhdGUg KHNlZSBbUkZDIDQyNzFdLCBwYWdlIDI2KS4NCg0KDQoNClRoZSBSb3V0ZSBTZWxlY3Rpb24gU2Vj dGlvbiAoOS4xLjIpIGluIFJGQzQyNzEgaXMgbm90IGV4cGxpY2l0IGFib3V0IHBlcmZvcm1pbmcg bG9vcCBkZXRlY3Rpb24gb25seSBvbiBlQkdQIHNlc3Npb25zIOKAkyB0aGUgY3JpdGVyaWEgaXMg Z2VuZXJpYyB0byBhbnkgcm91dGUsIHNvIHRoZXJlIGlzIGEgcG9zc2liaWxpdHkgdGhhdCBhIEJH UHNlYy1jYXBhYmxlIHJvdXRlciBtYXkgd2FudCB0byBwZXJmb3JtIGxvb3AgZGV0ZWN0aW9uIG9u IGFuIGlCR1AtcmVjZWl2ZWQgVXBkYXRlLiAgR2l2ZW4gdGhpcyB0ZXh0IGZyb20gU2VjdGlvbiA1 IGluIHRoZSBCR1BzZWMgc3BlYzoNCg0KDQoNCiAgIFdoZW5ldmVyIHRoZSB1c2Ugb2YgQVMgcGF0 aCBpbmZvcm1hdGlvbiBpcyBjYWxsZWQgZm9yDQoNCiAgIChlLmcuLCBsb29wIGRldGVjdGlvbiwg b3IgdXNlIG9mIEFTIHBhdGggbGVuZ3RoIGluIGJlc3QgcGF0aA0KDQogICBzZWxlY3Rpb24pIHRo ZSBleHRlcm5hbGx5IHZpc2libGUgYmVoYXZpb3Igb2YgdGhlIGltcGxlbWVudGF0aW9uDQoNCiAg IHNoYWxsIGJlIHRoZSBzYW1lIGFzIGlmIHRoZSBpbXBsZW1lbnRhdGlvbiBoYWQgcnVuIHRoZSBh bGdvcml0aG0gaW4NCg0KICAgU2VjdGlvbiA0LjQgYW5kIHVzZWQgdGhlIHJlc3VsdGluZyBBU19Q QVRIIGF0dHJpYnV0ZSBhcyBpdCB3b3VsZCBmb3INCg0KICAgYSBub24tQkdQc2VjIHVwZGF0ZSBt ZXNzYWdlLg0KDQoNCg0K4oCmaG93IHNob3VsZCBhbiBpQkdQIHNwZWFrZXIgcGVyZm9ybSBsb29w IGRldGVjdGlvbiBpZiB0aGVyZeKAmXMgbm8gQkdQc2VjX1BhdGggYXR0cmlidXRlPyAgSW4gb3Ro ZXIgd29yZHMsIHRoZXJlIGlzIG5vIGRlZmluZWQgbWVjaGFuaXNtIHRvIHJ1biB0aGUgYWxnb3Jp dGhtIGluIDQuNCB3aXRob3V0IGl0Lg0KDQoNCg0KSeKAmW0gbm90IHN1Z2dlc3RpbmcgdGhhdCB5 b3UgaW5jbHVkZSBhbiBlbXB0eSBhdHRyaWJ1dGUsIGJ1dCB0aGF0IHlvdSBpbmRpY2F0ZSBpbiA0 LjQgdGhhdCBubyBCR1BzZWNfUGF0aCBhdHRyaWJ1dGUgaXMgZXF1aXZhbGVudCB0byBhbiBlbXB0 eSBBU19QQVRILg0KDQoNCg0KVGhhbmtzIQ0KDQoNCg0KQWx2YXJvLg0K --_000_6C8E073DF1AB45888DFFFAA0A2465273ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0 Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLlBsYWlu VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6 dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xv cj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5PbiAxLzYvMTcs IDEyOjQwIEFNLCAmcXVvdDtTcmlyYW0sIEtvdGlrYWxhcHVkaSAoRmVkKSZxdW90OyAmbHQ7a290 aWthbGFwdWRpLnNyaXJhbUBuaXN0LmdvdiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPltDdXQgdGhlIGRpc3RyaWJ1dGlvbiBsaXN0IGEgbGl0dGxlLl08L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPlNyaXJhbTo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhpISZuYnNwOyBIYXBweSBOZXcg WWVhciE8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgaGF2ZSBzb21lIGNvbW1lbnRzIG9uIHRoaXMsIHBs ZWFzZSBzZWUgYmVsb3cuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFua3MhPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5BbHZhcm8uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPuKApjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwg fCAxKSZuYnNwOyZuYnNwO1NlY3Rpb24gNC4xIOKAnFRoZSBCR1BzZWMgUGF0aCBhdHRyaWJ1dGUg YW5kIHRoZSBBU19QQVRIIGF0dHJpYnV0ZSBhcmUgbXV0dWFsbHkNCjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPnwgfCBleGNsdXNpdmUuIFRoYXQgaXMsIGFueSB1cGRhdGUgbWVzc2FnZSBj b250YWluaW5nIHRoZSBCR1BzZWMgUGF0aCBhdHRyaWJ1dGUgTVVTVCBOT1QNCjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPnwgfCBjb250YWluIHRoZSBBU19QQVRIIGF0dHJpYnV0ZeKAnS4m bmJzcDsmbmJzcDtGb3IgYW55IHJlc3RhcnRpbmcgc3BlYWtlcnMgaW4gYSBHUiBtb2RlLCB3aGVy ZSB0aGUgYmdwDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IHwgY2FwYWJpbGl0eSBp cyBub3QgZXhjaGFuZ2VkLCB0aGUgZXhpc3Rpbmcgc3RhbGUgcm91dGVzIHdvbuKAmXQgaGF2ZSBh biBBU19QQVRIIGF0dHJpYnV0ZS4gV2UNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwg fCBjb3VsZCBhZGQgc29tZSBjbGFyaWZ5aW5nIHRoYXQgaGVscHMgdG8gaW5kaWNhdGUgdGhhdCBz dWNoIHJvdXRlcyBzaG91bGQgYmUgY29uc2lkZXJlZA0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+fCB8IHZhbGlkIGluIHN0YWxlIG1vZGUgKHRpbGwgdGhleSBnZXQgcmVmcmVzaGVkKT88 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnw8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwgW1NyaXJhbV0mbmJzcDsmbmJzcDtBcyB5b3UgaGF2 ZSBjbGFyaWZpZWQgZm9yIG1lIG9uIHRoZSBwaG9uZSwgd2hhdCB5b3UgYXJlIHNheWluZyBoZXJl IGlzIHRoYXQgdGhlDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IHR3byBCR1BzZWMg cGVlcnMgbG9zdCB0aGUgQkdQc2VjIHNlc3Npb24gYW5kIG5vdyByZXN0YXJ0aW5nIGluIEdSIG1v ZGUsIGJ1dCB0aGV5IGhhdmUgbm90DQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IGV4 Y2hhbmdlZCBCR1BzZWMgY2FwYWJpbGl0eSB0aGlzIHRpbWUuIEhlbmNlLCB0aGV5IGFyZSBub3cg c2ltcGxlIEJHUCAobm9uLUJHUHNlYykgcGVlcnMNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPnwgaW4gR1IgbW9kZS4gUkZDNDI3MSBjb25zaWRlcnMgdXBkYXRlIG1lc3NhZ2UgcmVjZWl2 ZWQgd2l0aG91dCBhIHdlbGwta25vd24gQVNfUEFUSA0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+fCBhdHRyaWJ1dGUgYXMgYW4gZXJyb3IsIGFuZCB1bmZvcnR1bmF0ZWx5IGluIHRoaXMg Y2FzZSB0aGUgY2FjaGVkIEJHUHNlYyB1cGRhdGVzIGRvIG5vdCBoYXZlDQo8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij58IEFTX1BBVEggKGFsYmVpdCB0aGV5IGhhdmUgQkdQc2VjX1BhdGgp LiBTbyB5b3UgYXJlIHNheWluZyAmcXVvdDt0aGUgcm91dGVyIHNob3VsZCBub3QgcGFuaWMmcXVv dDsNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwgYW5kIGluc3RlYWQgc2ltcGx5IHRy ZWF0IGVhY2ggY2FjaGVkIHVwZGF0ZSBhcyBOT1QtSU4tRVJST1IgZXZlbiB0aG91Z2ggaXQgaXMg bWlzc2luZw0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCBBU19QQVRIIGF0dHJpYnV0 ZS4gVGhpcyB3YXkgdGhlIEdSIGNhbiB3b3JrIHByb3Blcmx5LiBPZiBjb3Vyc2UsIHNob3J0bHkg dGhlIHVwZGF0ZXMgd2lsbA0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCBoYXZlIEFT X1BBVEggKGFuZCBub3QgY29uc2lkZXJlZCBpbiBlcnJvcikgd2hlbiB0aGV5IGdldCByZWZyZXNo ZWQgKG92ZXIgdGhlIG5ldyBzaW1wbGUNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwg QkdQIHNlc3Npb24pLiBQZXIgeW91ciBzdWdnZXN0aW9uLCBJIHdpbGwgaW5jbHVkZSBuZXcgdGV4 dCBpbiBTZWN0aW9uIDcgdG8gZGVzY3JpYmUgdGhpcw0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+fCByZXF1aXJlZCBiZWhhdmlvciBmb3IgdGhlIEdSIG1vZGUuJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5JIGRvbuKAmXQgaGF2ZSBhbiBvYmplY3Rpb24gZm9yIHRoaXMgYmVoYXZpb3IsIGJ1 dCBJIHRoaW5rIHdlIHNob3VsZCBtYWtlIHRoZSBXRyAoYW5kIGlkciEpIGF3YXJlIG9mIHRoZSBj aGFuZ2UgYW5kIGdldCB0aGVpciBjb21tZW50cyAoaWYgYW55KSBiZWZvcmUgSSBhcHByb3ZlIHRo ZSBwdWJsaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij7igKY8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPnwgfCAzKSZuYnNwOyZuYnNwO1NlY3Rpb24gNSBhbmQgU2Vj dGlvbiA1LjIsIDFzdCBwYXJhZ3JhcGg6IFJGQzQyNzEgY29uc2lkZXJzIHVwZGF0ZSBtZXNzYWdl IHJlY2VpdmVkDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IHwgd2l0aG91dCBhIHdl bGwta25vd24gQVNfUEFUSCBhdHRyaWJ1dGUgYXMgYW4gZXJyb3IuJm5ic3A7Jm5ic3A7V2UgbmVl ZCBzb21lIHRleHQgdG8gY2xhcmlmeSB0aGUNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PnwgfCAoZXJyb3IgaGFuZGxpbmcgaWYgYW55KSBiZWhhdmlvciB3aGVuIGFuIHVwZGF0ZSBtZXNz YWdlIGlzIHJlY2VpdmVkIHdpdGhvdXQgYSBiZ3BzZWMgYW5kDQo8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij58IHwgYW4gYXNwYXRoIGF0dHJpYnV0ZS4gVGhlIGN1cnJlbnQgZHJhZnQgdGV4 dCBzZWVtcyB1bmNsZWFyIGFib3V0IGdlbmVyYXRpb24gb2YgYmdwc2VjDQo8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij58IHwgYXR0cmlidXRlIGFzIHdlbGwgKGluIGEgaWJncCBzY2VuYXJp bykuIElzIGl0IGEgcmVxdWlyZW1lbnQgdG8gZ2VuZXJhdGUgYW4gZW1wdHkgYmdwc2VjDQo8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IHwgYXR0cmlidXRlPzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+fCBbU3JpcmFtXSZuYnNwOyZuYnNwO0FzIHlvdSBoYXZlIGNsYXJpZmllZCBmb3Ig bWUgb3ZlciB0aGUgcGhvbmUsIFJGQyA0MjcxIChwYWdlIDI2KSBzYXlzIHRoZQ0KPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+fCBmb2xsb3dpbmcgOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+fDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+fCZuYnNwOyAmcXVvdDtXaGVuIGEgQkdQIHNwZWFrZXIgb3JpZ2luYXRlcyBhIHJvdXRlIHRo ZW46PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58Jm5ic3A7Jm5ic3A7 IGIpIHRoZSBvcmlnaW5hdGluZyBzcGVha2VyIGluY2x1ZGVzIGFuIGVtcHR5IEFTX1BBVEggYXR0 cmlidXRlIGluPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFsbCBVUERBVEUgbWVzc2FnZXMg c2VudCB0byBpbnRlcm5hbCBwZWVycy4mbmJzcDsmbmJzcDsoQW4gZW1wdHkgQVNfUEFUSDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdHRyaWJ1dGUgaXMgb25lIHdob3NlIGxlbmd0 aCBmaWVsZCBjb250YWlucyB0aGUgdmFsdWUgemVybykuJnF1b3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij58PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IFtTcmly YW1dJm5ic3A7Jm5ic3A7U28gd2hhdCBuZWVkcyB0byBiZSBzYWlkIGluIHRoZSBCR1BzZWMgZG9j dW1lbnQgaXMgdGhlIGZvbGxvd2luZzombmJzcDsmbmJzcDtUaGUNCjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPnwgQkdQc2VjX1BhdGggYXR0cmlidXRlIGlzIG5vdCBhdHRhY2hlZCBpbiB1 cGRhdGVzIG9yaWdpbmF0ZWQgaW5zaWRlIGFuIEFTIGFuZCBwcm9wYWdhdGVkIHRvDQo8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IEJHUHNlYyBjYXBhYmxlIGludGVybmFsIHBlZXJzLiBI b3dldmVyLCB3aGVuIGEgcm91dGUgaXMgb3JpZ2luYXRlZCBpbnNpZGUgYW4gQVMgYW5kDQo8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IHByb3BhZ2F0ZWQgdG8gbm9uLUJHUHNlYyBpbnRl cm5hbCBwZWVycywgYW4gZW1wdHkgQVNfUEFUSCBhdHRyaWJ1dGUgaXMgaW5jbHVkZWQgaW4gdGhl DQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IHVwZGF0ZSAoc2VlIFtSRkMgNDI3MV0s IHBhZ2UgMjYpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgUm91dGUgU2VsZWN0 aW9uIFNlY3Rpb24gKDkuMS4yKSBpbiBSRkM0MjcxIGlzIG5vdCBleHBsaWNpdCBhYm91dCBwZXJm b3JtaW5nIGxvb3AgZGV0ZWN0aW9uIG9ubHkgb24gZUJHUCBzZXNzaW9ucyDigJMgdGhlIGNyaXRl cmlhIGlzIGdlbmVyaWMgdG8gYW55IHJvdXRlLCBzbyB0aGVyZSBpcyBhIHBvc3NpYmlsaXR5IHRo YXQgYSBCR1BzZWMtY2FwYWJsZSByb3V0ZXIgbWF5IHdhbnQgdG8gcGVyZm9ybSBsb29wDQogZGV0 ZWN0aW9uIG9uIGFuIGlCR1AtcmVjZWl2ZWQgVXBkYXRlLiZuYnNwOyBHaXZlbiB0aGlzIHRleHQg ZnJvbSBTZWN0aW9uIDUgaW4gdGhlIEJHUHNlYyBzcGVjOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsgV2hlbmV2ZXIgdGhlIHVzZSBvZiBBUyBwYXRoIGluZm9ybWF0 aW9uIGlzIGNhbGxlZCBmb3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyAoZS5nLiwgbG9vcCBkZXRlY3Rpb24sIG9yIHVzZSBvZiBBUyBwYXRoIGxl bmd0aCBpbiBiZXN0IHBhdGg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyBzZWxlY3Rpb24pIHRoZSBleHRlcm5hbGx5IHZpc2libGUgYmVoYXZpb3Ig b2YgdGhlIGltcGxlbWVudGF0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsgc2hhbGwgYmUgdGhlIHNhbWUgYXMgaWYgdGhlIGltcGxlbWVudGF0 aW9uIGhhZCBydW4gdGhlIGFsZ29yaXRobSBpbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFNlY3Rpb24gNC40IGFuZCB1c2VkIHRoZSByZXN1bHRp bmcgQVNfUEFUSCBhdHRyaWJ1dGUgYXMgaXQgd291bGQgZm9yPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYSBub24tQkdQc2VjIHVwZGF0ZSBtZXNz YWdlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij7igKZob3cgc2hvdWxkIGFuIGlCR1Ag c3BlYWtlciBwZXJmb3JtIGxvb3AgZGV0ZWN0aW9uIGlmIHRoZXJl4oCZcyBubyBCR1BzZWNfUGF0 aCBhdHRyaWJ1dGU/Jm5ic3A7IEluIG90aGVyIHdvcmRzLCB0aGVyZSBpcyBubyBkZWZpbmVkIG1l Y2hhbmlzbSB0byBydW4gdGhlIGFsZ29yaXRobSBpbiA0LjQgd2l0aG91dCBpdC48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+SeKAmW0gbm90IHN1Z2dlc3RpbmcgdGhhdCB5b3UgaW5jbHVk ZSBhbiBlbXB0eSBhdHRyaWJ1dGUsIGJ1dCB0aGF0IHlvdSBpbmRpY2F0ZSBpbiA0LjQgdGhhdCBu byBCR1BzZWNfUGF0aCBhdHRyaWJ1dGUgaXMgZXF1aXZhbGVudCB0byBhbiBlbXB0eSBBU19QQVRI LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFua3MhPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5BbHZhcm8uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6C8E073DF1AB45888DFFFAA0A2465273ciscocom_-- From nobody Fri Jan 6 17:32:31 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328E11296D8 for ; Fri, 6 Jan 2017 17:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 MZUNWxax77Tq for ; Fri, 6 Jan 2017 17:32:29 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 4059F1297BC for ; Fri, 6 Jan 2017 17:32:29 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cPfrs-0003yX-M5; Sat, 07 Jan 2017 01:32:24 +0000 Date: Sat, 07 Jan 2017 10:32:22 +0900 Message-ID: From: Randy Bush To: Alvaro Retana In-Reply-To: <6C8E073D-F1AB-4588-8DFF-FAA0A2465273@cisco.com> References: <6C8E073D-F1AB-4588-8DFF-FAA0A2465273@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Kotikalapudi Sriram , Matthew Lepinski , sidr Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 01:32:30 -0000 re keyur's point 4. the issue is that 4271 has semantics of AS_PATH, bgpsec replaces it with BGPSEC_PATH, but bgpsec does not explicitly repeat things such as loop detection using BGPSEC_PATH. instead of this becoming another text explosion, a simple statement that, in bgpsec, the following AS_PATH semantics of 4271: , hold analogously for BGPSEC_PATH. randy From nobody Fri Jan 6 23:21:02 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED64D1298BB; Fri, 6 Jan 2017 23:20:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Peter Yee To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148377365496.17506.6284084883799824498.idtracker@ietfa.amsl.com> Date: Fri, 06 Jan 2017 23:20:54 -0800 Archived-At: Cc: draft-ietf-sidr-publication.all@ietf.org, ietf@ietf.org, sidr@ietf.org Subject: [sidr] Review of draft-ietf-sidr-publication-09 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 07:20:55 -0000 Reviewer: Peter Yee Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-sidr-publication-09 Reviewer: Peter Yee Review Date: 2017-01-06 IETF LC End Date: 2017-01-06 IESG Telechat date: 2017-01-19 Summary: This specification defines a protocol for handling objects in an RPKI repository. The document seems fairly straightforward and simple to understand. Major issues: Minor issues: Nits/editorial comments: Page 5, Section 2.2, last paragraph, last sentence: perhaps change "are permitted to" to "MAY"? Page 7, Section 2.6, 1st paragraph: change "RelaxNG" to "RELAX NG". (Hey, I had to look it up.) Page 14, Section 4, 1st paragraph after rsync enumation: "safely" is used but no subsequent mention is made of what is unsafe about the non-overlapping rsync directories. Is the reader expected to know something about rsync's safety? Nothing in the Security Considerations deals with this topic. Page 16, Section 6, 3rd paragraph, 2nd sentence: insert "private" before "keys". Insert "to" before "delete". Page 17, Section 7: it might be good to include references to: XML, RelaxNG, and maybe rsync (yeah, I know that one is a little tough). From nobody Sat Jan 7 15:40:45 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA46129406; Sat, 7 Jan 2017 15:40:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148383243975.2763.15066568719585600300.idtracker@ietfa.amsl.com> Date: Sat, 07 Jan 2017 15:40:39 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-rfc6810-bis-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 23:40:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : The Resource Public Key Infrastructure (RPKI) to Router Protocol Authors : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-rfc6810-bis-08.txt Pages : 33 Date : 2017-01-07 Abstract: In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 1 of the rpki-rtr protocol. RFC 6810 describes version 0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc6810-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-rtr-rfc6810-bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jan 7 15:51:21 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63068129684 for ; Sat, 7 Jan 2017 15:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 thQ0vg0ODqWL for ; Sat, 7 Jan 2017 15:51:12 -0800 (PST) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019FE129687 for ; Sat, 7 Jan 2017 15:51:11 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id A8E8739811 for ; Sat, 7 Jan 2017 23:51:10 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id A11784608565 for ; Sat, 7 Jan 2017 18:51:09 -0500 (EST) Date: Sat, 07 Jan 2017 18:51:09 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: <148383243975.2763.15066568719585600300.idtracker@ietfa.amsl.com> References: <148383243975.2763.15066568719585600300.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170107235109.A11784608565@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-rfc6810-bis-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 23:51:19 -0000 With apologies to the WG and our AD for taking so ridiculously long (deadlines on other projects, but that's no excuse), we have finally uploaded an updated I-D which we hope deals with most (all?) of the issues that came up during AD review, as well as a few minor clarifications and wording tweaks. No protocol changes, just (we hope) better description of the protocol. The one important change here in terms of IETF standardization is that we've dropped the notion that this document should obsolete RFC 6810. While Alvaro kindly offered to help us find a twisty path which would let us write a single document which would both deprecate RFC 6810 (protocol version zero) and also specifying how to downgrade from version one to version zero, on reflection the authors agreed that this is not worth the procedural headache. From nobody Sun Jan 8 21:22:27 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE40129AB1; Sun, 8 Jan 2017 21:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 C7aEu2vx31uO; Sun, 8 Jan 2017 21:22:23 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0118.outbound.protection.outlook.com [23.103.201.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F3B129AAE; Sun, 8 Jan 2017 21:22:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=04YAm9D1jO+bSlwc9GAWwTXKhAScoHXFCRREGo1Gs0A=; b=v0qRpwxAd2Z2f+LmNDVSFORzmxRclQnwHVY28VOoA9EchXFc2ueulCROzFtjiwr2EeSY+V9rI4kIz5GIamIAtbVOzhcwC+u3V5lsyiYQHZllPmigX/aPkLkqRY3c0btSusRWDrJ3zK6xfzjRaUra0p4HZ/haQG0MCAttlCUEGrI= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0447.namprd09.prod.outlook.com (10.161.252.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Mon, 9 Jan 2017 05:22:20 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0817.015; Mon, 9 Jan 2017 05:22:20 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) Thread-Index: AQHSZpHl3JK9Ep+Hw0SM2CHq7jfcT6Ep5PcggAANcYCABay7Cw== Date: Mon, 9 Jan 2017 05:22:20 +0000 Message-ID: References: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> , <304ad58d-fa44-45e3-6fb1-4e7b189007cd@cs.tcd.ie> In-Reply-To: <304ad58d-fa44-45e3-6fb1-4e7b189007cd@cs.tcd.ie> 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=kotikalapudi.sriram@nist.gov; x-originating-ip: [132.163.222.9] x-ms-office365-filtering-correlation-id: b24e88d1-3506-420b-27c8-08d4384f7c47 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0447; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0447; 7:KKIdX9ULdcCw0s9zRRwzgXzFCyTLQGgJjqxKFcsUL53R4juArMqGAPF0MEYXTa6UTtmDqjYw1eKV4FsmsCqCXTcFdGSDW8vHiufxhzUeFa5Fnj6AEbJX1eNE9ejVCzI3QwGUj/Ogq8ZdOsfhdazsNnQwmyIjd/Jj5+B1TEy8BVh/g5PhEMn+4+jBlXs9fl379Axh/CHA4KlU1oFx47xh1X2ikJrHGJl0GiPOUwrrhwD+tC/3V/IjxJhjn1CqNN/021Xjd9IaA9eQs7++rvTjiaUgSM3OxM41YCZE5cB2riyaLJaYgBLG/zYUZq4e+TFS74IpUc69VmcgmNRsRzZ0BjcGj9MZU30XQ2M2oEGEuN4HNwOjECkudolcUoMkW6zpwn+gKFe/gx/9vefOS7PkVw65TKgdsHOa/nGiFmvnwUZMZwW1/mM0CcYcYpJZlkRZUhvh52dF7o3U0/H6miEEiw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:DM2PR09MB0447; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0447; x-forefront-prvs: 0182DBBB05 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39850400002)(39450400003)(39410400002)(199003)(189002)(3846002)(102836003)(54906002)(9686003)(3280700002)(68736007)(230783001)(74316002)(3660700001)(7736002)(2900100001)(6116002)(5660300001)(33656002)(8936002)(122556002)(8676002)(2950100002)(86362001)(189998001)(101416001)(6436002)(55016002)(92566002)(99286003)(77096006)(4326007)(7696004)(305945005)(6506006)(5001770100001)(105586002)(229853002)(97736004)(2906002)(81156014)(106116001)(81166006)(25786008)(106356001)(66066001)(50986999)(38730400001)(54356999)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0447; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2017 05:22:20.1730 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0447 Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , "sidr-chairs@ietf.org" , "m.waehlisch@fu-berlin.de" , "sidr@ietf.org" Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 05:22:25 -0000 Stephen, Please see responses inline below. >>[Sriram] Signer's ASN is indeed included in the signed data. >> In Figure 8, "Secure_Path Segment : N" corresponds >> to the signing AS (current AS) and that is where the >> signer's ASN is included along with its pCount and Flags. >Hmm. That's the target ASN of the previous signer though. Semantically the "Secure_Path Segment: N" shown in the data to be hashed in Figure 8, contains the current=20 signer's ASN, although logically it is equal to=20 the target ASN of the previous signer.=20 >I thought there were cases where they could differ? But >if not, then you probably need to state that as a rule >for checking signatures, is that there already? (Happy to >check later, but don't have time right now.) They had differed in one situation but that was before we put in a fix for the confederation boundary, and that fix is in the second paragraph of Section 4.3 of version-21. So now we are good. Yes, now=20 a signer's ASN always equals the target ASN=20 used in the hashed data by the previous signer.=20 So in the signature validation, the verifier always plugs in its own ASN as the target ASN for validation of the most recently added signature. Without that the validation of that signature will fail. That rule is built in into the validation process (page 26): "For the first segment to be processed (the most recently added segment (i.e. N =3D K) given that there are K hops in the Secure_Path), the 'Target AS Number' is AS(K+1), the AS number of the BGPsec speaker validating the update message." >>> - 5.2, I think you need to say something to the effect >>> that every Secure_Path MUST have a signature with an >>> algorithm that is supported. As I read the text, the >>> algorithm as stated here could be read to not require >>> that. E.g. the para before the bullets on p25 could be >>> read to mean "drop all stuff involving unsupported algs >>> and then continue to process the rest of the stuff." >>> >> [Sriram] Seems like a bit of a pathological case. >> Could happen only if the sender behavior was incorrect. >Yes, but 5.2 is verifier behaviour and ought not >assume a correct signer, so I do think the alg >presented here needs to cover such things. Please see response below. >> Sender is not required to know which algorithms a peer supports >> but sender's expected behavior is this: MUST include a Signature_Block > for the "current" algorithm (which every BGPsec speaker >> MUST support through the transition period), >Where does it say that the current/next thing applies >to the entire world of BGPsec? I didn't read it that >way as it happens, but rather that the current/next >could involve different algorithms at different nodes >at the same time. > >So e.g. I read it to be allowed that a migration from >rsa/sha256 then to ecdsa then to eddsa could occur >with some non-updated nodes still signing with rsa/sha256 >whilst some shiny new nodes are doing ecdsa and eddsa and >others are in between. > >I do agree that a global current/next pair of algs >is nicer, if that is what's wanted. But I don't recall >the text saying that. (Again happy to check later, but >no time right now;-) The text does describe it in terms of=20 "a global current/new pair of algs" in Section 6.1 (p. 28, v-21): "To this end, a mandatory algorithm suites document exists which specifies a mandatory-to-use 'current' algorithm suite for use by all BGPsec speakers [I-D.ietf-sidr-bgpsec-algs]. It is anticipated that, in the future, the mandatory algorithm suites document will be updated to specify a transition from the 'current' algorithm suite to a 'new' algorithm suite. During the period of transition (likely a small number of years), all BGPsec update messages SHOULD simultaneously use both the 'current' algorithm suite and the 'new' algorithm suite. (Note that Section 3 and Section 4 specify how the BGPsec_Path attribute can contain signatures, in parallel, for two algorithm suites.) Once the transition is complete, use of the old 'current' algorithm will be deprecated, use of the 'new' algorithm will be mandatory, =85." Thank you. Sriram From nobody Sun Jan 8 21:41:46 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16F1129ADB; Sun, 8 Jan 2017 21:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 FNEO69FOrf_3; Sun, 8 Jan 2017 21:41:43 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0102.outbound.protection.outlook.com [23.103.201.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20696129AD6; Sun, 8 Jan 2017 21:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=X0UvsVUL7ST9Qp7ZvU2ZZv60fahPWzOa2akQUZ1ud7Q=; b=pKpKtOmMvWixmyt58wKawNA4RYFwsyEyzxXb0OVxysFwx+36CALLD0FtU6FVbXThVKmbbHjI6m+s4G/L1sAMMVlSkPWrkbXwp24Dc6oQ2/BSU8yMQ9SaFUHL6C78nprUSMLPyf/a8BClKoFHzxyVbN4+aNUbR4Gh92Rt4RsLw9o= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM5PR09MB1433.namprd09.prod.outlook.com (10.173.171.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.7; Mon, 9 Jan 2017 05:41:41 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0817.015; Mon, 9 Jan 2017 05:41:40 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Stephen Farrell , "Montgomery, Douglas (Fed)" , Russ Housley Thread-Topic: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) Thread-Index: AQHSZpHl3JK9Ep+Hw0SM2CHq7jfcT6EosxWAgAACfgCAAAebgIAADVwAgAAOQgCAAAG+AIAGyiWA Date: Mon, 9 Jan 2017 05:41:40 +0000 Message-ID: References: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> <3ae7d707-3229-2508-7aeb-2cd617aa97fd@cs.tcd.ie> , In-Reply-To: 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=kotikalapudi.sriram@nist.gov; x-originating-ip: [132.163.222.9] x-microsoft-exchange-diagnostics: 1; DM5PR09MB1433; 7:wXnFz3Oh3ccqPhqdwyIYpAiHe3IbrrDyJnSMZVoZtfxkLbsDwR6bBzPmPwF2Pice4puxodF4mFSPkISJTLSpMWt+TgUBKmFdECz+TGtymE7rHPUomvaK5KbcRe3gb7N4oe5lq1N8Si/3RVEVaz+ouVoeOXzdIjkfnhqAAKbC5VEsXFqRzksGt7EK86iTUwNKumlGUgLrvwO6wUAVwizp+hu8CPqea6N3HBCoDij5b8B7DvPiGuey3e06XwFARrOfJWnjIabw9DwU7naXcBJ057jecmPaHFyMW9zxdL7eylzWyS014o8wcLZlamxwX+J1+pNy7QuEHUReEIzlJCdg6u5IZe8UsBNEY6SB7A/CkdS7ciWAu6ifWTVCv6BfWqjmLDfVxxL6+JGCFlxo9qVthxOHaqUgRvkqbHDypW21Qm66cbrf/7CqyanOWV18K2bEvQdOc96rn0gKBvqSQ4ZeqQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39450400003)(39410400002)(39850400002)(24454002)(199003)(51414003)(377454003)(189002)(99286003)(230783001)(3846002)(6116002)(189998001)(102836003)(74316002)(54906002)(305945005)(68736007)(7736002)(5001770100001)(97736004)(2950100002)(81156014)(8936002)(81166006)(3280700002)(38730400001)(229853002)(9686003)(8676002)(3660700001)(77096006)(106356001)(105586002)(54356999)(2900100001)(101416001)(86362001)(2906002)(106116001)(93886004)(4326007)(76176999)(50986999)(7696004)(33656002)(5660300001)(6436002)(66066001)(25786008)(122556002)(6506006)(55016002)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1433; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 475a723c-8ed3-412c-415c-08d438522fac x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR09MB1433; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:DM5PR09MB1433; BCL:0; PCL:0; RULEID:; SRVR:DM5PR09MB1433; x-forefront-prvs: 0182DBBB05 received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2017 05:41:40.2532 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1433 Archived-At: Cc: IESG , IETF SIDR Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 05:41:45 -0000 Stephen, Please see response below. >From: sidr on behalf of Stephen Farrell >Sent: Wednesday, January 4, 2017 4:45 PM >To: Montgomery, Douglas (Fed); Russ Housley >Hiya, >On 04/01/17 21:39, Montgomery, Douglas (Fed) wrote: >> The RPKI validating caches *are* the relaying parties for BGPsec, they a= re >> (a) designed to be run on a separate box than the router itself and (b) >> their behavior WRT exchanges with RPKI repositories is independent of BG= P >> message processing by any of the routers that they serve. >Sure. That makes sense. But where's it stated for BGPsec that >the RP ought act that way? I propose adding the following paragraph in Section 7.=20 Please let me know if this would help resolve your concern/comment. =20 The deployment structure, technologies and best=20 practices concerning global RPKI data to reach routers=20 (via local RPKI caches) are described in [RFC6810]=20 [RFC7115] [I-D.ietf-sidr-bgpsec-ops]=20 [I-D.-ietf-sidr-delta-protocol] [rsync].=20 For example, serial-number based incremental update=20 mechanisms are used for efficient transfer of just the=20 data records that have changed since last update [RFC6810].=20 Update notification file is used by relying parties (RPs)=20 to discover whether any changes exist between the state of=20 the global RPKI repository and the RP's cache=20 [I-D.-ietf-sidr-delta-protocol]. The notification describes=20 the location of the files containing the snapshot and=20 incremental deltas which can be used by the RP to=20 synchronize with the repository. Making use of these=20 technologies and best practices results in enabling=20 robustness, efficiency, and better security for the=20 BGPsec routers and RPKI caches in terms of the flow=20 of RPKI data from repositories to RPKI caches=20 to routers (in distilled form).=20 If you feel that the following sentence adds additional value,=20 it can be added at the end: In particular, by following these methods, security concerns=20 related to possible correlation of RPKI data access=20 and BGP update events are also mitigated. =20 You may edit/suggesting any wording improvements.=20 I look forward to your further guidance on this.=20 Thank you. Sriram = From nobody Mon Jan 9 02:49:46 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB6E129BDE; Mon, 9 Jan 2017 02:49:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148395897584.24935.4865204550913882433.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2017 02:49:35 -0800 Archived-At: Cc: draft-ietf-sidr-adverse-actions.all@ietf.org, ietf@ietf.org, sidr@ietf.org Subject: [sidr] Review of draft-ietf-sidr-adverse-actions-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 10:49:36 -0000 Reviewer: Dan Romascanu Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-sidr-adverse-actions-03 Reviewer: Dan Romascanu Review Date: 2017-01-09 IETF LC End Date: 2017-01-10 IESG Telechat date: 2017-01-19 Summary: Major issues: Minor issues: Nits/editorial comments: 1. The title is slightly misleading, it can be interpreted that the document deals with cases where the CA or Resource Manager initiate the attacks. In reality the document deals with attacks made possible by the fact that the CA or Resource Managers are themselves under attack, or some management mistakes were made at the CA or Resource Manager. I would suggest a change in the title of the document: s/Adverse Actions by a Certification Authority (CA) or Repository Manager/Adverse Actions by means of a Certification Authority (CA) or Repository Manager/ 2. It is not clear why the numbering of the actions in the subsections of section 2 (2.1, 2,2, etc.) are prefixed by A, rather than continuing the indentation under 2.1, 2.2, etc. In other words - why A-1.1 and not 2.1.1, A-1.1.1 and not 2.1.1.1, etc. From nobody Mon Jan 9 03:37:26 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E55129BFC; Mon, 9 Jan 2017 03:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.601 X-Spam-Level: X-Spam-Status: No, score=-5.601 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham 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 Rh-zFr-47LwU; Mon, 9 Jan 2017 03:37:22 -0800 (PST) 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 DFC4D12940D; Mon, 9 Jan 2017 03:37:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 557B4BE47; Mon, 9 Jan 2017 11:37:19 +0000 (GMT) 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 SuwqV_nnUDz2; Mon, 9 Jan 2017 11:37:18 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 683F3BE38; Mon, 9 Jan 2017 11:37:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483961837; bh=FCK5u7pIsBc5JvH9wFQEFuNMkRFDEBxLuRbGgu03ojI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Xbo9VmJKqqSW40XDUzXnhbEfPkTlfxS10HBYJd9eMS3DsIg0nfykk70+dsWATvtKy a+ZEog5zYuBK92385uYzx/wZrADgQCKTJRGMaeSX9bV6gj6mjdlz5tTquABkiBLgd/ 8b4Akh8DbLsWlSdlsF70D3ZVNRIFTslPEoY4B3fg= To: "Sriram, Kotikalapudi (Fed)" , "Montgomery, Douglas (Fed)" , Russ Housley References: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> <3ae7d707-3229-2508-7aeb-2cd617aa97fd@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Mon, 9 Jan 2017 11:37:17 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030307020401030207000206" Archived-At: Cc: IESG , IETF SIDR Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 11:37:24 -0000 This is a cryptographically signed message in MIME format. --------------ms030307020401030207000206 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Adding the text you propose for section 7 seems good. You also asked about adding this: On 09/01/17 05:41, Sriram, Kotikalapudi (Fed) wrote: > In particular, by following these methods, security concerns=20 > related to possible correlation of RPKI data access=20 > and BGP update events are also mitigated. =20 Maybe better to say something like: "With these caching mechanisms it is believed that an attacker wouldn't be able to meaningfully correlate RPKI data flows with BGPsec RP actions, thus avoiding attacks that attempt to determine the set of ASes interacting with an RP via the interactions between the RP and RPKI servers." Also, I had a look back at the overall thread and I think this is where we're at: discuss point #1: the draft needs a bit of text saying how to handle an SKI that is not 20 bytes long. I don't think we have a text proposal but it should be easy enough, e.g. you could say "If the SKI in a certificate is not 20 bytes long then if it is longer, use the leftmost 20 bytes. If the SKI value is shorter than 20 bytes, then pad left with zero bytes." Note that I don't care which way you prefer to fix this, any way is fine. discuss point #2: this one's sorted. (I updated my ballot to indicate this one's cleared.) discuss point #3: with your suggested text and something like the above we should be good with this one too If you'd like to submit a revised ID with those changes then I should be fine to clear. Cheers, S. --------------ms030307020401030207000206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDkx MTM3MTdaMC8GCSqGSIb3DQEJBDEiBCAzLN1l5rarKYSbFgLZjhScwv2340tkvu9t5CmKmXbG aTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAHpQ1Qgdld4kg0sGYVUJQXjKSye6rifDFmwI3FvRROM9WLx0J3PWmm HbEp7Vi+u4ZLncHE64GaiioZa400W880Xd5XEQHGNCqVTpmW5EoiM+pgTAY/I0DgGxrHgztE Z7Cljq93zPTMhayiCtCoaV+Fh2MgafgRUwOt/6kKdsLwSSbEOfRHUzAOPPA0R4I1D9y7fKpu RPOqmizJa1nIAhu0FFT5RYcJsHtqMxWb4AjIpYt/viiIoAMNhDbDyPaOz550dxTzM402w0Pp h3KvpcLpNomysvAC1kPXQLly4FDaiL0DsXarUNZOjHAvXX9L3VR0wD0vnQrSUY/vEkrsku0A AAAAAAAA --------------ms030307020401030207000206-- From nobody Mon Jan 9 03:55:29 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCC4129530; Mon, 9 Jan 2017 03:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199] 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 yeADCoPuQP1a; Mon, 9 Jan 2017 03:55:26 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 C300D129C0F; Mon, 9 Jan 2017 03:55:25 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cQYXn-0006DV-0J; Mon, 09 Jan 2017 12:55:21 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-187.ripe.net) by titi.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1cQYXl-00056e-Tl; Mon, 09 Jan 2017 12:55:18 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_6FC83753-5FBF-4B11-A131-52AE7C864F90" From: Tim Bruijnzeels In-Reply-To: Date: Mon, 9 Jan 2017 12:55:16 +0100 Message-Id: References: <7DE58D01-AC82-4099-9A46-99E625315637@cisco.com> <99DD12D4-6E13-40A4-95C7-17B12CB61F1C@ripe.net> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------------ X-RIPE-Spam-Report: Spam Total Points: -12.6 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -3.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07197a2d12bb4e942ed404ce4524b12cf972 Archived-At: Cc: "draft-ietf-sidr-delta-protocol@ietf.org" , Chris Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] AD Review of draft-ietf-sidr-delta-protocol-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 11:55:28 -0000 --Apple-Mail=_6FC83753-5FBF-4B11-A131-52AE7C864F90 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alvaro, in-line > On 07 Jan 2017, at 00:04, Alvaro Retana (aretana) = wrote: >=20 > On 12/28/16, 11:43 AM, "Tim Bruijnzeels" > wrote: > =20 > Tim: > =20 > Happy New Year!! Thank you, you (all) too!! > =20 > =20 > | Thank you for your in-depth review :) It really helps to clarify the = document. Replies in-line. > | > | I attached an updated document, but.. I did not discuss this with = co-authors yet. So, I invite any of them to > | disagree or suggest changes to the things below. > =20 > Thanks for that. I have some comments below =E2=80=93 I want us to = discuss the Update issue (M16) so we can start the IETF Last Call. > =20 > Thanks! > =20 > Alvaro. > =20 > =20 > | On 20 Dec 2016, at 14:15, Alvaro Retana (aretana) > wrote: > =E2=80=A6 > | | M2. Section 3.2. (Certificate Authority Use): =E2=80=9CRelying = Parties that do not support this delta protocol MUST > | | NOT reject a CA certificate merely because it has an SIA extension = containing this new kind of > | | AccessDescription.=E2=80=9D By definition, an RP that has never = even considered this document will not support > | | the delta protocol =E2=80=93 IOW, trying to specify the behavior = of RPs that may have never even seen this > | | document makes no sense to me, and can=E2=80=99t be enforced. = What is the current behavior when an RP receives > | | the extra SIA extension? > | > | The point of documenting this is to give RP software the option of = recognising that a new protocol exists, > | even if they do not fully support it yet. In practice all current = RPs do this (see below), and future RPs should > | consider this document. We have in fact been publishing these = additional SIAs in the RIPE NCC production > | RPKI for more than a year without problems. I changed it slightly to = this: > | > | "Relying Parties that choose not to support this delta protocol yet, = MUST NOT reject a CA certificate merely > | because it has an SIA extension containing this new kind of = AccessDescription." > | > | But, I can also live with taking this sentence out altogether. > =20 > I would prefer it if we do that. > =20 ok > =20 > =E2=80=A6 > | | M4. =46rom 3.3.2. (Publishing Updates): =E2=80=9CThe update = notification file SHOULD be kept small=E2=80=A6older delta files > | | that=E2=80=A6will result in total size of deltas exceeding the = size of the snapshot, MUST be excluded.=E2=80=9D Here the > | | =E2=80=9CSHOULD=E2=80=9D and the =E2=80=9CMUST=E2=80=9D are in = contradiction: you either do it always (MUST) or there may be cases when > | | you don=E2=80=99t (SHOULD). s/SHOULD/should > | > | Ok, I moved the file size concern to the next bullet point instead, = so that we have: > | > | o Any older delta files that, when combined with all more recent = delta files, will result > | in a total size of deltas exceeding the size of the snapshot, MUST = be excluded to avoid > | that RPs download more data than necessary. > | > | o The server MAY also exclude more recent delta files if it finds = that their usage by a > | small number of RPs that would be forced to perform a full = synchronisation is outweighed > | performance benefits of having a smaller update notification file. = However, the repository > | server MUST include all deltas that it has available for the last = two hours. > | > | I hope that explains it better. I changed the SHOULD in the second = bullet point to a MUST. The unspoken > | reason for the SHOULD was that a publication server may not have = deltas. > =20 > The problem that I think can still exist is time dependent: =E2=80=9Col= der delta files=E2=80=A6MUST be excluded=E2=80=A6MUST include all deltas = that is has available for the last two hours=E2=80=9D. What happens if = all =E2=80=9Colder delta files=E2=80=9D are less than two hours old, but = the size would be too big? Is there the possibility of a case where = there are a lot of changes that happen close together (but more than a = minute apart) that would then result in many delta files? Besides not = postponing publication for more than a minute, I don=E2=80=99t remember = other mechanisms that would avoid a large number of changes=E2=80=A6 If = this case is not possible, then we should be ok =E2=80=93 I would still = like to understand why. > =20 Let me clarify first. No, it should never exceed snapshot file. But I = understand the wording is confusing, how about this instead then? o The server MAY also choose to exclude old delta files, even though = their combined size does not exceed the size of the snapshot file, if they find that = files of a certain age are only very infrequently requested. Since most Relying Parties will = keep close track of new deltas, excluding such deltas will help to keep the size of the = Notification File small and thus reduce the load on the Publication Server in particular. = However, if a server chooses to use this strategy they MUST not exclude such deltas if = they are less than two hours old, so that Relying Parties can safely use a one hour refresh = interval and suffer short (maintenance) outages without being forced to do a full = re-synchronisation. And, yes, two hours is arbitrary. I just felt that there should be some = reasonable limit to this. Another approach could be to say that the = servers MUST(?) establish first where some threshold lies of the time = window where e.g. on average 99.5% (again arbitrary of course) of all = requests ever for deltas are typically done. This is something that a = publication server can monitor over time. It might find that 99.5% of = such requests happen within 1 hour, 2, 5.. we don't really know at this = time - this needs deployment. Long story short.. I am also fine with leaving this out of the = specification altogether for now. But then I will probably seek to add = some wording on this in a -bis or update sometime later once we have = more operational experience (and data). > =E2=80=A6 > | | M7. 3.4.1. (Processing the Update Notification File): =E2=80=9CMUST = issue an operator error=E2=80=9D What is an =E2=80=9Coperator > | | error=E2=80=9D and how do you issue one? I didn=E2=80=99t see an = error definition in the schema. > | > | I see your point, but.. afaik none of the other sidr RFCs and I-Ds = define this, and just avoid talking about this > | altogether. This was undefined in over five years of deployment with = rsync, and yet operational issues with > | rsync also happen and get reported and resolved somehow. In short I = suggest that I just leave it out here as > | well. > =20 > No. Sorry, but =E2=80=9COthers didn=E2=80=99t do it=E2=80=9D is not a = valid reason for an incomplete specification. > =20 > | But to continue: All RPs do have the common sense to inform their = users about issues (e.g. also things like: > | hey, this certificate is invalid because..), but there is no = standard defined, so they use various formats and > | ways. I do see some benefit in defining at least a common standard = because it might help (1) monitoring, (2) > | normative documenting of error conditions and responses, and (3) = interop testing between RPs (Rob, David > | and I have done this a few times and it's a bit of a hassle). Doing = so is imo major work and something for a > | separate sidr-ops document. > =20 > One of the reasons I added this comment is because it uses a = =E2=80=9CMUST=E2=80=9D: you=E2=80=99re mandating the behavior as part of = the specification. If it is a mandatory behavior, then there should be = something that goes with is as to how it is done. One way forward is to = clarify what you mean by an =E2=80=9Coperator error=E2=80=9D, which = (interpreting the paragraph above) is really a log message. > =20 > I am fine (if you want to mandate the behavior) for you to say = something like: =E2=80=9CMUST log the condition for the operator to be = aware of the problem=E2=80=9D. No need to specify the contents, a = common format, etc. > =20 > I agree that if you did want to define common formats, contents, etc. = then that would belong somewhere else. Okay, so is your concern addressed if I change "MUST issue an operator = error" to =E2=80=9CMUST log the condition for the operator to be aware = of the problem=E2=80=9D? > =20 > =E2=80=A6 > | See section 3.4.5 of attached file for clarifications that I think = we can do in the context of this document. > | Following your previous remark the only normative addition I feel I = can add is this: "In order to help prevent > | this Publication Servers MUST perform regular validation of their = own RRDP repository." > =20 > The new section looks ok, except for the paragraph that says: =E2=80=9CT= his protocol document cannot define normative text=E2=80=A6=E2=80=9D No = need to put that in here. ok, will exclude > =20 > =20 > | | M11. =46rom 3.4.3. (Processing Delta Files): =E2=80=9Cit is = RECOMMENDED that a RP uses additional strategies to > | | determine if an object is still relevant for validation before = removing it from its local storage=E2=80=9D. Ok, like > | | what? > | > | I think going into too much detail is out of scope because it cannot = be explained without having a document > | formally describing validation strategies. But I added this: > | > | In particular objects should not be removed if they are included in = a current validated manifest. > =20 > Ok. As before, the reason for the comment is the use of = =E2=80=9CRECOMMENDED=E2=80=9D. > =20 > =20 > =E2=80=A6 > | | M16. Section 5. (Security Considerations): =E2=80=9CRRDP replaces = the use of rsync by HTTPS=E2=80=A6=E2=80=9D. Given the > | | statement in 3.4.1 about using =E2=80=9Can alternate repository = retrieval mechanism=E2=80=9D and the rest of the text in this > | | section, I would assume that the intent is not really to = =E2=80=9Creplace the use of rsync=E2=80=9D (with an update to > | | RFC6480). Maybe I=E2=80=99m reading too much into the phrase = above, but please clarify. > | > | As explained above it is the intent to replace rsync. But.. a = migration document should be written as a > | separate effort. > | > | That said I would be fine with just taking out:=20 > | > | The original RPKI transport mechanism is rsync, which offers no = channel > | security mechanism. RRDP replaces the use of rsync by HTTPS; > | > | Please let me know if you prefer this. > =20 > =20 > Let me try to make the point again =E2=80=93 I didn=E2=80=99t do a = good job above. In fact, reading this over I want to change it=E2=80=A6 > =20 > In this document you=E2=80=99re saying: here=E2=80=99s a new protocol = that SHOULD be used instead of rsync (3.4.1).=20 > =20 > And, as you mentioned above, the intent is to eventually phase out = rsync in favor of RRDP. Time lines to phase it out are really out of = the scope of this (or I think any other RFC) document because it is = something the RPKI community agrees on and migrates to, just like any = other new protocol. > =20 > All that is good. > =20 > However, both RFC6480 and RFC6481 mandate the use of rsync: =E2=80=9Call= publication points MUST be accessible via rsync=E2=80=9D and = =E2=80=9Cpublication repository MUST be available using rsync=E2=80=9D. = Which means that to comply with the RPKI architecture rsync MUST be = supported forever, regardless of whether RRDP is used, or a different = protocol that may come along in the future=E2=80=A6or even if it is not = needed at all anymore (not even for eventual backup). L > =20 > The question about updating RFC6480 above should have been a = statement: this document should update RFC6480/RFC6481 so that rsync is = not required anymore. > =20 > Changing the text in RFC6480/RFC6481 to say =E2=80=9CMUST use RRDP=E2=80= =9D would just result in another update later if another protocol ever = comes along, so I think this document should be explicit in the change = (to allow the move away from rsync), but still generic=E2=80=A6for = example, the text in RFC6480/RFC6481 can be replaced with something = like: =E2=80=9CThe publication point MUST be accessible using a = retrieval mechanism consistent with the accessMethod element value(s). = Multiple retrieval mechanisms can be supported at the repository = operator=E2=80=99s discretion=E2=80=9D. > =20 > A change like that would require that this document be tagged to = Update RFC6480/RFC6481 (and would of course return RFC6481 to be = Normative). Ok, I understand. But I will need a bit of time for the text. (baby = number two has his due date this Thursday so bear with me). > =20 >=20 > =E2=80=A6 > | | P4. =E2=80=9Cversion 4 UUID=E2=80=9D Please provide a reference. > | > | ack, I assumed informative. > =20 > Normative, because the document says that it MUST be used. BTW, = please put the reference on the first mention of UUID. ok, will do Thanks Tim --Apple-Mail=_6FC83753-5FBF-4B11-A131-52AE7C864F90 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Alvaro,

in-line

On 07 Jan 2017, at 00:04, = Alvaro Retana (aretana) <aretana@cisco.com> wrote:

On = 12/28/16, 11:43 AM, "Tim Bruijnzeels" <tim@ripe.net> wrote:
 
Tim:
 
Happy New = Year!!

Thank = you, you (all) too!!

 
 
| Thank you for your in-depth review :) It really = helps to clarify the document. Replies in-line.
|
| I attached an = updated document, but.. I did not discuss this with co-authors yet. So, = I invite any of them to
| = disagree or suggest changes to the things below.
 
Thanks for = that.  I have some comments below =E2=80=93 I want us to discuss = the Update issue (M16) so we can start the IETF Last Call.
 
Thanks!
 
Alvaro.
 
 
| On 20 Dec 2016, at = 14:15, Alvaro Retana (aretana) <aretana@cisco.com> wrote:
=E2=80=A6
| | M2. Section 3.2. = (Certificate Authority Use): =E2=80=9CRelying Parties that do not = support this delta protocol MUST
| | NOT reject a CA certificate merely because it = has an SIA extension containing this new kind of
| | = AccessDescription.=E2=80=9D  By definition, an RP that has = never even considered this document will not support
| | the delta = protocol =E2=80=93 IOW, trying to specify the behavior of RPs that may = have never even seen this
| = | document makes no sense to me, and can=E2=80=99t be = enforced.  What is the current behavior when an RP = receives
| | the = extra SIA extension?
|
| The point of = documenting this is to give RP software the option of recognising that a = new protocol exists,
| = even if they do not fully support it yet. In practice all current RPs do = this (see below), and future RPs should
| consider this document. We have in fact been = publishing these additional SIAs in the RIPE NCC production
| RPKI for more than = a year without problems. I changed it slightly to this:
|
| "Relying Parties = that choose not to support this delta protocol yet, MUST NOT reject a CA = certificate merely
| = because it has an SIA extension containing this new kind of = AccessDescription."
|
| But, I can also = live with taking this sentence out altogether.
 
I would prefer it if = we do that.
 

ok

 
=E2=80=A6
| | M4. =46rom 3.3.2. (Publishing Updates): =E2=80=9C= The update notification file SHOULD be kept small=E2=80=A6older delta = files
| | that=E2=80=A6will = result in total size of deltas exceeding the size of the snapshot, MUST = be excluded.=E2=80=9D  Here the
| | =E2=80=9CSHOULD=E2=80=9D and the =E2=80=9CMUST=E2= =80=9D are in contradiction: you either do it always (MUST) or there may = be cases when
| | you = don=E2=80=99t (SHOULD).  s/SHOULD/should
|
| Ok, I moved the = file size concern to the next bullet point instead, so that we have:
|
| o Any older delta = files that, when combined with all more recent delta files, will = result
|  = in a total size of deltas exceeding the size of the snapshot, MUST be = excluded to avoid
|   that RPs download more data than necessary.
|
| o The server MAY = also exclude more recent delta files if it finds that their usage by = a
|   small = number of RPs that would be forced to perform a full synchronisation is = outweighed
|  = performance benefits of having a smaller update notification file. = However, the repository
|   server MUST include all deltas that it has = available for the last two hours.
|
| I = hope that explains it better. I changed the SHOULD in the second bullet = point to a MUST. The unspoken
| reason for the SHOULD was that a publication = server may not have deltas.
 
The problem that I think can still exist is time = dependent:  =E2=80=9Colder delta files=E2=80=A6MUST be = excluded=E2=80=A6MUST include all deltas that is has available for the = last two hours=E2=80=9D.  What happens if all =E2=80=9Colder delta = files=E2=80=9D are less than two hours old, but the size would be too = big?  Is there the possibility of a case where there are a lot of = changes that happen close together (but more than a minute apart) that = would then result in many delta files?  Besides not postponing = publication for more than a minute, I don=E2=80=99t remember other = mechanisms that would avoid a large number of changes=E2=80=A6  If = this case is not possible, then we should be ok =E2=80=93 I would still = like to understand why.
 

Let me clarify first. No, it should never = exceed snapshot file. But I understand the wording is confusing, how = about this instead then?

 o The = server MAY also choose to exclude old delta files, even though their = combined size
   does not exceed the size of the = snapshot file, if they find that files of a certain age
  =  are only very infrequently requested. Since most Relying Parties = will keep close track of
   new deltas, excluding = such deltas will help to keep the size of the Notification File = small
   and thus reduce the load on the Publication = Server in particular. However, if a server
  =  chooses to use this strategy they MUST not exclude such deltas if = they are less than two
   hours old, so that Relying = Parties can safely use a one hour refresh interval and = suffer
   short (maintenance) outages without being = forced to do a full re-synchronisation.

And, yes, two hours is arbitrary. I just felt that = there should be some reasonable limit to this. Another approach could be = to say that the servers MUST(?) establish first where some threshold = lies of the time window where e.g. on average 99.5% (again arbitrary of = course) of all requests ever for deltas are typically done. This is = something that a publication server can monitor over time. It might find = that 99.5% of such requests happen within 1 hour, 2, 5.. we don't really = know at this time - this needs deployment.

Long story short.. I am also fine with leaving = this out of the specification altogether for now. But then I will = probably seek to add some wording on this in a -bis or update sometime = later once we have more operational experience (and data).



=E2=80=A6
| | M7. 3.4.1. = (Processing the Update Notification File): =E2=80=9CMUST issue an = operator error=E2=80=9D  What is an =E2=80=9Coperator
| | error=E2=80=9D = and how do you issue one?  I didn=E2=80=99t see an error = definition in the schema.
|
| I see = your point, but.. afaik none of the other sidr RFCs and I-Ds define = this, and just avoid talking about this
| altogether. This was undefined in over five years = of deployment with rsync, and yet operational issues with
| rsync also happen = and get reported and resolved somehow. In short I suggest that I just = leave it out here as
| = well.
 
No.  Sorry, but = =E2=80=9COthers didn=E2=80=99t do it=E2=80=9D is not a valid reason for = an incomplete specification.
 
| But to continue: All RPs do have the common sense = to inform their users about issues (e.g. also things like:
| hey, this = certificate is invalid because..), but there is no standard defined, so = they use various formats and
| ways. I do see some benefit in defining at least = a common standard because it might help (1) monitoring, (2)
| normative = documenting of error conditions and responses, and (3) interop testing = between RPs (Rob, David
| = and I have done this a few times and it's a bit of a hassle). Doing so = is imo major work and something for a
| separate sidr-ops document.
 
One of the reasons I = added this comment is because it uses a =E2=80=9CMUST=E2=80=9D: you=E2=80=99= re mandating the behavior as part of the specification.  If it is a = mandatory behavior, then there should be something that goes with is as = to how it is done.  One way forward is to clarify what you mean by = an =E2=80=9Coperator error=E2=80=9D, which (interpreting the paragraph = above) is really a log message.
 
I am fine (if you want to mandate the behavior) for = you to say something like: =E2=80=9CMUST log the condition for the = operator to be aware of the problem=E2=80=9D.  No need to specify = the contents, a common format, etc.
 
I agree that if you did want to define common = formats, contents, etc. then that would belong somewhere = else.

Okay, so is = your concern addressed if I change "MUST = issue an operator error" to =E2=80=9CMUST log the condition for the operator to be aware = of the problem=E2=80=9D?


 
=E2=80=A6
| See section 3.4.5 = of attached file for clarifications that I think we can do in the = context of this document.
| = Following your previous remark the only normative addition I feel I can = add is this: "In order to help prevent
| this Publication Servers MUST perform regular = validation of their own RRDP repository."
 
The new section looks ok, except for the paragraph = that says: =E2=80=9CThis protocol document cannot define normative = text=E2=80=A6=E2=80=9D  No need to put that in = here.

ok, will = exclude

 
  
| | M11. =46rom = 3.4.3. (Processing Delta Files): =E2=80=9Cit is RECOMMENDED that a RP = uses additional strategies to
| | determine if an object is still relevant for = validation before removing it from its local storage=E2=80=9D.  = Ok, like
| | = what?
|
| I think going into = too much detail is out of scope because it cannot be explained without = having a document
| = formally describing validation strategies. But I added this:
|
| In particular = objects should not be removed if they are included in a current = validated manifest.
 
Ok.  As before, = the reason for the comment is the use of =E2=80=9CRECOMMENDED=E2=80=9D.
 
 
=E2=80=A6
| | M16. Section 5. = (Security Considerations): =E2=80=9CRRDP replaces the use of rsync by = HTTPS=E2=80=A6=E2=80=9D. Given the
| | statement in 3.4.1 about using =E2=80=9Can = alternate repository retrieval mechanism=E2=80=9D and the rest of the = text in this
| | = section, I would assume that the intent is not really to =E2=80=9Creplace = the use of rsync=E2=80=9D (with an update to
| | = RFC6480).   Maybe I=E2=80=99m reading too much into the phrase = above, but please clarify.
|
| = As explained above it is the intent to replace rsync. But.. a migration = document should be written as a
| separate effort.
|
| = That said I would be fine with just taking out: 
|
|     The original RPKI transport = mechanism is rsync, which offers no channel
|     security mechanism. RRDP = replaces the use of rsync by HTTPS;
|
| = Please let me know if you prefer this.
 
 
Let me try to make the point again =E2=80=93 I = didn=E2=80=99t do a good job above.  In fact, reading this over I = want to change it=E2=80=A6
 
In this document you=E2=80=99re saying: here=E2=80=99= s a new protocol that SHOULD be used instead of rsync (3.4.1). 
 
And, as you mentioned = above, the intent is to eventually phase out rsync in favor of = RRDP.  Time lines to phase it out are really out of the scope of = this (or I think any other RFC) document because it is something the = RPKI community agrees on and migrates to, just like any other new = protocol.
 
All that is good.
 
However, both RFC6480 = and RFC6481 mandate the use of rsync: =E2=80=9Call publication points = MUST be accessible via rsync=E2=80=9D and =E2=80=9Cpublication = repository MUST be available using rsync=E2=80=9D.  Which means = that to comply with the RPKI architecture rsync MUST be supported = forever, regardless of whether RRDP is used, or a different protocol = that may come along in the future=E2=80=A6or even if it is not needed at = all anymore (not even for eventual backup). L
 
The question about updating RFC6480 above should = have been a statement: this document should update RFC6480/RFC6481 so = that rsync is not required anymore.
 
Changing the text in RFC6480/RFC6481 to say =E2=80=9C= MUST use RRDP=E2=80=9D would just result in another update later if = another protocol ever comes along, so I think this document should be = explicit in the change (to allow the move away from rsync), but still = generic=E2=80=A6for example, the text in RFC6480/RFC6481 can be replaced = with something like: =E2=80=9CThe publication point MUST be accessible = using a retrieval mechanism consistent with the accessMethod element = value(s).  Multiple retrieval mechanisms can be supported at the = repository operator=E2=80=99s discretion=E2=80=9D.
 
A change like that = would require that this document be tagged to Update RFC6480/RFC6481 = (and would of course return RFC6481 to be = Normative).

Ok, I = understand. But I will need a bit of time for the text. (baby number two = has his due date this Thursday so bear with me).

 

=E2=80=A6
| | P4. =E2=80=9Cversio= n 4 UUID=E2=80=9D  Please provide a reference.
|
| ack, I assumed = informative.
 
Normative, because = the document says that it MUST be used.  BTW, please put the = reference on the first mention of UUID.

ok, = will do


Thanks
Tim



= --Apple-Mail=_6FC83753-5FBF-4B11-A131-52AE7C864F90-- From nobody Mon Jan 9 05:15:04 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8381D129CA2; Mon, 9 Jan 2017 05:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 98bBV6VGPCqU; Mon, 9 Jan 2017 05:15:01 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4AF5129B3A; Mon, 9 Jan 2017 05:15:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15322; q=dns/txt; s=iport; t=1483967700; x=1485177300; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qY9yVaSOhuW4WzCRXB0c2mzSuF2z140N2CRMA7lGCuk=; b=NjtLmuhQ+0G2J+uvtSkanl1q3oQj0XfSG9ImMiv6XnrWujyc/apmItkN /bHzAlWp0lldP76mfhOC6FtD5m1NpptUVLtrEEzZNhlU3XEFdh467mDfz spfFq2Klhwlz85C6dNUOmJP2JtOU0IhhF5LkQMRAnbngVFOQqN7uU1akr w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQA7jHNY/5JdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnFJAQEBAQEfX4EMB4NIigiiHYUrggqGIgIagUc/FAECAQEBAQE?= =?us-ascii?q?BAWMohGkGI1YQAgEIEi0DAgICMBQDDgIEDgUUiFyvSoIlK4lhAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYZFggIIgleED4M/LYIxBZUchgABkUyBd45liAuKSQEfOIF?= =?us-ascii?q?AFUcBhhpzh1mBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,339,1477958400"; d="scan'208,217";a="368850347" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2017 13:14:59 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v09DExa7010918 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Jan 2017 13:14:59 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 9 Jan 2017 07:14:58 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Mon, 9 Jan 2017 07:14:58 -0600 From: "Alvaro Retana (aretana)" To: Tim Bruijnzeels Thread-Topic: [sidr] AD Review of draft-ietf-sidr-delta-protocol-04 Thread-Index: AQHSWsMmv8FEfthKGUScz+TLnYEy7KEeAgSAgA47ooCABE/kAP//wnMA Date: Mon, 9 Jan 2017 13:14:58 +0000 Message-ID: References: <7DE58D01-AC82-4099-9A46-99E625315637@cisco.com> <99DD12D4-6E13-40A4-95C7-17B12CB61F1C@ripe.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: multipart/alternative; boundary="_000_A78AA861BA514698957DF565DFD05A79ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sidr-delta-protocol@ietf.org" , Chris Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] AD Review of draft-ietf-sidr-delta-protocol-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 13:15:02 -0000 --_000_A78AA861BA514698957DF565DFD05A79ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGltOg0KDQpDb25ncmF0dWxhdGlvbnMhICDimLoNCg0KDQpJIHRoaW5rIHdl4oCZcmUgaW4gc3lu YyB3aXRoIGV2ZXJ5dGhpbmcgZWxzZSwganVzdCB0aGlzIGxhc3QgcGllY2UgaXMgb3V0c3RhbmRp bmcuDQoNClRoYW5rcyENCg0KQWx2YXJvLg0KDQpPbiAxLzkvMTcsIDY6NTUgQU0sICJUaW0gQnJ1 aWpuemVlbHMiIDx0aW1AcmlwZS5uZXQ8bWFpbHRvOnRpbUByaXBlLm5ldD4+IHdyb3RlOg0KDQoN Cg0KTGV0IG1lIHRyeSB0byBtYWtlIHRoZSBwb2ludCBhZ2FpbiDigJMgSSBkaWRu4oCZdCBkbyBh IGdvb2Qgam9iIGFib3ZlLiAgSW4gZmFjdCwgcmVhZGluZyB0aGlzIG92ZXIgSSB3YW50IHRvIGNo YW5nZSBpdOKApg0KDQpJbiB0aGlzIGRvY3VtZW50IHlvdeKAmXJlIHNheWluZzogaGVyZeKAmXMg YSBuZXcgcHJvdG9jb2wgdGhhdCBTSE9VTEQgYmUgdXNlZCBpbnN0ZWFkIG9mIHJzeW5jICgzLjQu MSkuDQoNCkFuZCwgYXMgeW91IG1lbnRpb25lZCBhYm92ZSwgdGhlIGludGVudCBpcyB0byBldmVu dHVhbGx5IHBoYXNlIG91dCByc3luYyBpbiBmYXZvciBvZiBSUkRQLiAgVGltZSBsaW5lcyB0byBw aGFzZSBpdCBvdXQgYXJlIHJlYWxseSBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoaXMgKG9yIEkgdGhp bmsgYW55IG90aGVyIFJGQykgZG9jdW1lbnQgYmVjYXVzZSBpdCBpcyBzb21ldGhpbmcgdGhlIFJQ S0kgY29tbXVuaXR5IGFncmVlcyBvbiBhbmQgbWlncmF0ZXMgdG8sIGp1c3QgbGlrZSBhbnkgb3Ro ZXIgbmV3IHByb3RvY29sLg0KDQpBbGwgdGhhdCBpcyBnb29kLg0KDQpIb3dldmVyLCBib3RoIFJG QzY0ODAgYW5kIFJGQzY0ODEgbWFuZGF0ZSB0aGUgdXNlIG9mIHJzeW5jOiDigJxhbGwgcHVibGlj YXRpb24gcG9pbnRzIE1VU1QgYmUgYWNjZXNzaWJsZSB2aWEgcnN5bmPigJ0gYW5kIOKAnHB1Ymxp Y2F0aW9uIHJlcG9zaXRvcnkgTVVTVCBiZSBhdmFpbGFibGUgdXNpbmcgcnN5bmPigJ0uICBXaGlj aCBtZWFucyB0aGF0IHRvIGNvbXBseSB3aXRoIHRoZSBSUEtJIGFyY2hpdGVjdHVyZSByc3luYyBN VVNUIGJlIHN1cHBvcnRlZCBmb3JldmVyLCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgUlJEUCBpcyB1 c2VkLCBvciBhIGRpZmZlcmVudCBwcm90b2NvbCB0aGF0IG1heSBjb21lIGFsb25nIGluIHRoZSBm dXR1cmXigKZvciBldmVuIGlmIGl0IGlzIG5vdCBuZWVkZWQgYXQgYWxsIGFueW1vcmUgKG5vdCBl dmVuIGZvciBldmVudHVhbCBiYWNrdXApLiDimLkNCg0KVGhlIHF1ZXN0aW9uIGFib3V0IHVwZGF0 aW5nIFJGQzY0ODAgYWJvdmUgc2hvdWxkIGhhdmUgYmVlbiBhIHN0YXRlbWVudDogdGhpcyBkb2N1 bWVudCBzaG91bGQgdXBkYXRlIFJGQzY0ODAvUkZDNjQ4MSBzbyB0aGF0IHJzeW5jIGlzIG5vdCBy ZXF1aXJlZCBhbnltb3JlLg0KDQpDaGFuZ2luZyB0aGUgdGV4dCBpbiBSRkM2NDgwL1JGQzY0ODEg dG8gc2F5IOKAnE1VU1QgdXNlIFJSRFDigJ0gd291bGQganVzdCByZXN1bHQgaW4gYW5vdGhlciB1 cGRhdGUgbGF0ZXIgaWYgYW5vdGhlciBwcm90b2NvbCBldmVyIGNvbWVzIGFsb25nLCBzbyBJIHRo aW5rIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIGV4cGxpY2l0IGluIHRoZSBjaGFuZ2UgKHRvIGFs bG93IHRoZSBtb3ZlIGF3YXkgZnJvbSByc3luYyksIGJ1dCBzdGlsbCBnZW5lcmlj4oCmZm9yIGV4 YW1wbGUsIHRoZSB0ZXh0IGluIFJGQzY0ODAvUkZDNjQ4MSBjYW4gYmUgcmVwbGFjZWQgd2l0aCBz b21ldGhpbmcgbGlrZTog4oCcVGhlIHB1YmxpY2F0aW9uIHBvaW50IE1VU1QgYmUgYWNjZXNzaWJs ZSB1c2luZyBhIHJldHJpZXZhbCBtZWNoYW5pc20gY29uc2lzdGVudCB3aXRoIHRoZSBhY2Nlc3NN ZXRob2QgZWxlbWVudCB2YWx1ZShzKS4gIE11bHRpcGxlIHJldHJpZXZhbCBtZWNoYW5pc21zIGNh biBiZSBzdXBwb3J0ZWQgYXQgdGhlIHJlcG9zaXRvcnkgb3BlcmF0b3LigJlzIGRpc2NyZXRpb27i gJ0uDQoNCkEgY2hhbmdlIGxpa2UgdGhhdCB3b3VsZCByZXF1aXJlIHRoYXQgdGhpcyBkb2N1bWVu dCBiZSB0YWdnZWQgdG8gVXBkYXRlIFJGQzY0ODAvUkZDNjQ4MSAoYW5kIHdvdWxkIG9mIGNvdXJz ZSByZXR1cm4gUkZDNjQ4MSB0byBiZSBOb3JtYXRpdmUpLg0KDQpPaywgSSB1bmRlcnN0YW5kLiBC dXQgSSB3aWxsIG5lZWQgYSBiaXQgb2YgdGltZSBmb3IgdGhlIHRleHQuIChiYWJ5IG51bWJlciB0 d28gaGFzIGhpcyBkdWUgZGF0ZSB0aGlzIFRodXJzZGF5IHNvIGJlYXIgd2l0aCBtZSkuDQoNCg== --_000_A78AA861BA514698957DF565DFD05A79ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAg MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsN CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1j b252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0K CWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLm1zb0lucw0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSI+VGltOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkNvbmdyYXR1bGF0aW9u cyEmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpXaW5nZGluZ3MiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+SSB0aGluayB3ZeKAmXJlIGluIHN5bmMgd2l0 aCBldmVyeXRoaW5nIGVsc2UsIGp1c3QgdGhpcyBsYXN0IHBpZWNlIGlzIG91dHN0YW5kaW5nLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij5BbHZhcm8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJn aW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIDEvOS8xNywgNjo1NSBBTSwgJnF1b3Q7VGltIEJydWlqbnplZWxzJnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dGltQHJpcGUubmV0Ij50aW1AcmlwZS5uZXQ8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdDtm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3 aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzow cHgiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9y OmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkxldCBtZSB0cnkgdG8gbWFrZSB0aGUgcG9p bnQgYWdhaW4g4oCTIEkgZGlkbuKAmXQgZG8gYSBnb29kIGpvYiBhYm92ZS4mbmJzcDsgSW4gZmFj dCwgcmVhZGluZyB0aGlzIG92ZXIgSSB3YW50IHRvIGNoYW5nZSBpdOKApjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFj ayI+SW4gdGhpcyBkb2N1bWVudCB5b3XigJlyZSBzYXlpbmc6IGhlcmXigJlzIGEgbmV3IHByb3Rv Y29sIHRoYXQgU0hPVUxEIGJlIHVzZWQgaW5zdGVhZCBvZiByc3luYyAoMy40LjEpLiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aTtjb2xvcjpibGFjayI+QW5kLCBhcyB5b3UgbWVudGlvbmVkIGFib3ZlLCB0aGUgaW50ZW50IGlz IHRvIGV2ZW50dWFsbHkgcGhhc2Ugb3V0IHJzeW5jIGluIGZhdm9yIG9mIFJSRFAuJm5ic3A7IFRp bWUgbGluZXMgdG8gcGhhc2UgaXQgb3V0IGFyZSByZWFsbHkgb3V0IG9mIHRoZSBzY29wZSBvZg0K IHRoaXMgKG9yIEkgdGhpbmsgYW55IG90aGVyIFJGQykgZG9jdW1lbnQgYmVjYXVzZSBpdCBpcyBz b21ldGhpbmcgdGhlIFJQS0kgY29tbXVuaXR5IGFncmVlcyBvbiBhbmQgbWlncmF0ZXMgdG8sIGp1 c3QgbGlrZSBhbnkgb3RoZXIgbmV3IHByb3RvY29sLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9y OmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+QWxsIHRoYXQg aXMgZ29vZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkhvd2V2ZXIsIGJvdGggUkZDNjQ4MCBhbmQgUkZDNjQ4 MSBtYW5kYXRlIHRoZSB1c2Ugb2YgcnN5bmM6IOKAnGFsbCBwdWJsaWNhdGlvbiBwb2ludHMgTVVT VCBiZSBhY2Nlc3NpYmxlIHZpYSByc3luY+KAnSBhbmQg4oCccHVibGljYXRpb24gcmVwb3NpdG9y eSBNVVNUIGJlDQogYXZhaWxhYmxlIHVzaW5nIHJzeW5j4oCdLiZuYnNwOyBXaGljaCBtZWFucyB0 aGF0IHRvIGNvbXBseSB3aXRoIHRoZSBSUEtJIGFyY2hpdGVjdHVyZSByc3luYyBNVVNUIGJlIHN1 cHBvcnRlZCBmb3JldmVyLCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgUlJEUCBpcyB1c2VkLCBvciBh IGRpZmZlcmVudCBwcm90b2NvbCB0aGF0IG1heSBjb21lIGFsb25nIGluIHRoZSBmdXR1cmXigKZv ciBldmVuIGlmIGl0IGlzIG5vdCBuZWVkZWQgYXQgYWxsIGFueW1vcmUgKG5vdCBldmVuDQogZm9y IGV2ZW50dWFsIGJhY2t1cCkuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpXaW5nZGluZ3M7Y29sb3I6YmxhY2siPkw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmk7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5U aGUgcXVlc3Rpb24gYWJvdXQgdXBkYXRpbmcgUkZDNjQ4MCBhYm92ZSBzaG91bGQgaGF2ZSBiZWVu IGEgc3RhdGVtZW50OiB0aGlzIGRvY3VtZW50IHNob3VsZCB1cGRhdGUgUkZDNjQ4MC9SRkM2NDgx IHNvIHRoYXQgcnN5bmMgaXMgbm90IHJlcXVpcmVkIGFueW1vcmUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmk7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5D aGFuZ2luZyB0aGUgdGV4dCBpbiBSRkM2NDgwL1JGQzY0ODEgdG8gc2F5IOKAnE1VU1QgdXNlIFJS RFDigJ0gd291bGQganVzdCByZXN1bHQgaW4gYW5vdGhlciB1cGRhdGUgbGF0ZXIgaWYgYW5vdGhl ciBwcm90b2NvbCBldmVyIGNvbWVzIGFsb25nLCBzbyBJIHRoaW5rDQogdGhpcyBkb2N1bWVudCBz aG91bGQgYmUgZXhwbGljaXQgaW4gdGhlIGNoYW5nZSAodG8gYWxsb3cgdGhlIG1vdmUgYXdheSBm cm9tIHJzeW5jKSwgYnV0IHN0aWxsIGdlbmVyaWPigKZmb3IgZXhhbXBsZSwgdGhlIHRleHQgaW4g UkZDNjQ4MC9SRkM2NDgxIGNhbiBiZSByZXBsYWNlZCB3aXRoIHNvbWV0aGluZyBsaWtlOiDigJxU aGUgcHVibGljYXRpb24gcG9pbnQgTVVTVCBiZSBhY2Nlc3NpYmxlIHVzaW5nIGEgcmV0cmlldmFs IG1lY2hhbmlzbSBjb25zaXN0ZW50DQogd2l0aCB0aGUgYWNjZXNzTWV0aG9kIGVsZW1lbnQgdmFs dWUocykuJm5ic3A7IE11bHRpcGxlIHJldHJpZXZhbCBtZWNoYW5pc21zIGNhbiBiZSBzdXBwb3J0 ZWQgYXQgdGhlIHJlcG9zaXRvcnkgb3BlcmF0b3LigJlzIGRpc2NyZXRpb27igJ0uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9y OmJsYWNrIj5BIGNoYW5nZSBsaWtlIHRoYXQgd291bGQgcmVxdWlyZSB0aGF0IHRoaXMgZG9jdW1l bnQgYmUgdGFnZ2VkIHRvIFVwZGF0ZSBSRkM2NDgwL1JGQzY0ODEgKGFuZCB3b3VsZCBvZiBjb3Vy c2UgcmV0dXJuIFJGQzY0ODEgdG8gYmUgTm9ybWF0aXZlKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2si Pk9rLCBJIHVuZGVyc3RhbmQuIEJ1dCBJIHdpbGwgbmVlZCBhIGJpdCBvZiB0aW1lIGZvciB0aGUg dGV4dC4gKGJhYnkgbnVtYmVyIHR3byBoYXMgaGlzIGR1ZSBkYXRlIHRoaXMgVGh1cnNkYXkgc28g YmVhciB3aXRoIG1lKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A78AA861BA514698957DF565DFD05A79ciscocom_-- From nobody Mon Jan 9 08:13:11 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2C3129541; Mon, 9 Jan 2017 08:13:02 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148397838282.24993.12731143796937922660.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2017 08:13:02 -0800 Archived-At: Cc: draft-ietf-sidr-bgpsec-ops@ietf.org, Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, rfc-editor@rfc-editor.org Subject: [sidr] Protocol Action: 'BGPsec Operational Considerations' to Best Current Practice (draft-ietf-sidr-bgpsec-ops-16.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 16:13:03 -0000 The IESG has approved the following document: - 'BGPsec Operational Considerations' (draft-ietf-sidr-bgpsec-ops-16.txt) as Best Current Practice This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ Technical Summary Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. It is expected to evolve as BGPsec is formalized and initially deployed. Working Group Summary This draft went thorugh several revisions, with good discussion from stake-holders in the communities affected. Document Quality The document describes what the WG believes is the best way to implement/deploy BGPsec. As it describes, it is expected to evolve as more experience is gained. Personnel Shepherd: Chris Morrow (morrowc@ops-netman.net) AD: Alvaro Retana (aretana@cisco.com) RFC Editor Note This document should be published alongside draft-ietf-sidr-bgpsec-protocol and draft-ietf-sidr-as-migration so that they have consecutive RFC numbers in the following order: draft-ietf-sidr-bgpsec-protocol draft-ietf-sidr-as-migration draft-ietf-sidr-bgpsec-ops From nobody Mon Jan 9 08:13:59 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 200F1129759; Mon, 9 Jan 2017 08:13:52 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148397843212.24905.623654911034961689.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2017 08:13:52 -0800 Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org, rfc-editor@rfc-editor.org Subject: [sidr] Protocol Action: 'A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests' to Proposed Standard (draft-ietf-sidr-bgpsec-pki-profiles-21.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 16:13:52 -0000 The IESG has approved the following document: - 'A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests' (draft-ietf-sidr-bgpsec-pki-profiles-21.txt) as Proposed Standard This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/ Technical Summary This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. This document also profiles the format of certification requests, and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends the RPKI; therefore, this documents updates the RPKI Resource Certificates Profile (RFC 6487). Working Group Summary The document has received multiple reviews and consisted WG interest. Document Quality This document doesn't specify a protocol per-se, but the contents must be implemented as part of BGPsec. Personnel Shepherd: Chris Morrow - morrowc@ops-netman.net AD: Alvaro Retana - aretana@cisco.com RFC Editor Note This document is part of a group being considered by the IESG that normatively depend on draft-ietf-sidr-bgpsec-protocol; all documents are titled draft-ietf-sidr-bgpsec-*. Please make sure that draft-ietf-sidr-bgpsec-protocol has the lowest RFC number -- no consecutive numbers are needed in this case. From nobody Mon Jan 9 09:39:22 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7E4129443; Mon, 9 Jan 2017 09:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199, 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 F_mBO7N9gpFQ; Mon, 9 Jan 2017 09:39:13 -0800 (PST) Received: from dfw-mailout20.raytheon.com (dfw-mailout20.raytheon.com [199.46.199.221]) (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 A6F12129499; Mon, 9 Jan 2017 09:39:12 -0800 (PST) Received: from ca-mailout10.rtnmail.ray.com (ca-mailout10.rtnmail.ray.com [147.25.146.12]) by dfw-mailout20.ext.ray.com (8.15.0.59/8.15.0.59) with ESMTPS id v09Hd6VE001004 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 9 Jan 2017 17:39:07 GMT Received: from 008-smtp-out.ray.com ([23.103.8.215]) by ca-mailout10.rtnmail.ray.com (8.15.0.59/8.15.0.59) with ESMTPS id v09Hd5dP008756 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT); Mon, 9 Jan 2017 17:39:05 GMT Received: from CY1PR0601MB023.008f.mgd2.msft.net (23.103.8.215) by CY1PR0601MB023.008f.mgd2.msft.net (23.103.8.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.789.16; Mon, 9 Jan 2017 17:39:04 +0000 Received: from CY1PR0601MB023.008f.mgd2.msft.net ([23.103.8.215]) by CY1PR0601MB023.008f.mgd2.msft.net ([23.103.8.215]) with mapi id 15.01.0789.014; Mon, 9 Jan 2017 17:39:04 +0000 From: Steve KENT To: Dan Romascanu , "gen-art@ietf.org" Thread-Topic: Review of draft-ietf-sidr-adverse-actions-03 Thread-Index: AQHSamYTsL7I4vqN5Eu1AlAG3mZhn6EwZ9Qm Date: Mon, 9 Jan 2017 17:39:04 +0000 Message-ID: References: <148395897584.24935.4865204550913882433.idtracker@ietfa.amsl.com> In-Reply-To: <148395897584.24935.4865204550913882433.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [23.103.8.197] Content-Type: multipart/alternative; boundary="_000_e24e2f8f5378421c8b4fc911efa11a6eCY1PR0601MB023008fmgd2m_" MIME-Version: 1.0 X-CC: dromasca@gmail.com, gen-art@ietf.org, sidr@ietf.org, ietf@ietf.org, draft-ietf-sidr-adverse-actions.all@ietf.org X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-09_11:, , signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-09_11:, , signatures=0 X-Original-Sender: steve.kent@raytheon.com X-Original-Recipients: draft-ietf-sidr-adverse-actions.all@ietf.org, ietf@ietf.org, sidr@ietf.org, gen-art@ietf.org, dromasca@gmail.com X-Attachments: X-DMZ-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701090248 X-DMZ-Spam-Reason: mlx Archived-At: Cc: "draft-ietf-sidr-adverse-actions.all@ietf.org" , "ietf@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Review of draft-ietf-sidr-adverse-actions-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 17:39:14 -0000 --_000_e24e2f8f5378421c8b4fc911efa11a6eCY1PR0601MB023008fmgd2m_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dan, Thanks for the review. Adverse actions include cases where the CA or repository manager is not att= acked or did not make an error, as noted in the Introduction: Note that the CA that allocated the affected INRs may be acting in accordan= ce with established policy, and thus the change may be contractually justif= ied, even though viewed as adverse by the INR holder. Thus I believe the title is appropriate. We chose to labels actions with an "A" to distinguish them and to allow num= bering of actions to begin at "1". If we label actions by subsection, the l= abels will become longer, which we felt was awkward. ________________________________ From: Dan Romascanu Sent: Monday, January 9, 2017 5:49:35 AM To: gen-art@ietf.org Cc: sidr@ietf.org; ietf@ietf.org; draft-ietf-sidr-adverse-actions.all@ietf.= org Subject: Review of draft-ietf-sidr-adverse-actions-03 Reviewer: Dan Romascanu Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-sidr-adverse-actions-03 Reviewer: Dan Romascanu Review Date: 2017-01-09 IETF LC End Date: 2017-01-10 IESG Telechat date: 2017-01-19 Summary: Major issues: Minor issues: Nits/editorial comments: 1. The title is slightly misleading, it can be interpreted that the document deals with cases where the CA or Resource Manager initiate the attacks. In reality the document deals with attacks made possible by the fact that the CA or Resource Managers are themselves under attack, or some management mistakes were made at the CA or Resource Manager. I would suggest a change in the title of the document: s/Adverse Actions by a Certification Authority (CA) or Repository Manager/Adverse Actions by means of a Certification Authority (CA) or Repository Manager/ 2. It is not clear why the numbering of the actions in the subsections of section 2 (2.1, 2,2, etc.) are prefixed by A, rather than continuing the indentation under 2.1, 2.2, etc. In other words - why A-1.1 and not 2.1.1, A-1.1.1 and not 2.1.1.1, etc. --_000_e24e2f8f5378421c8b4fc911efa11a6eCY1PR0601MB023008fmgd2m_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dan,


Thanks for the review.


Adverse actions include cases where the CA or repository manager is not = attacked or did not make an error, as noted in the Introduction:

Note that the CA that allocated the affected INRs may be act= ing in accordance with established policy, and thus the change may be contr= actually justified, even though viewed as adverse by the INR holder. <= /b>
Thus I believe the title is appropriate.


We chose to labels actions with an "A" to distinguish them and= to allow numbering of actions to begin at "1". If we label actio= ns by subsection, the labels will become longer, which we felt was awkward.=

From: Dan Romascanu <d= romasca@gmail.com>
Sent: Monday, January 9, 2017 5:49:35 AM
To: gen-art@ietf.org
Cc: sidr@ietf.org; ietf@ietf.org; draft-ietf-sidr-adverse-actions.al= l@ietf.org
Subject: Review of draft-ietf-sidr-adverse-actions-03
 
Reviewer: Dan Romascanu
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.= ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-sidr-adverse-actions-03
Reviewer: Dan Romascanu
Review Date: 2017-01-09
IETF LC End Date: 2017-01-10
IESG Telechat date: 2017-01-19

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

1. The title is slightly misleading, it can be interpreted that the
document deals with cases where the CA or Resource Manager initiate
the attacks. In reality the document deals with attacks made possible
by the fact that the CA or Resource Managers are themselves under
attack, or some management mistakes were made at the CA or Resource
Manager. I would suggest a change in the title of the document:

s/Adverse Actions by a Certification Authority (CA) or Repository
Manager/Adverse Actions by means of a Certification Authority (CA) or
Repository Manager/

2. It is not clear why the numbering of the actions in the subsections
of section 2 (2.1, 2,2, etc.) are prefixed by A, rather than
continuing the indentation under 2.1, 2.2, etc. In other words - why
A-1.1 and not 2.1.1, A-1.1.1 and not 2.1.1.1, etc.



--_000_e24e2f8f5378421c8b4fc911efa11a6eCY1PR0601MB023008fmgd2m_-- From nobody Mon Jan 9 21:43:47 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FA3129F47 for ; Mon, 9 Jan 2017 21:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 Jbdv3GW55GHK for ; Mon, 9 Jan 2017 21:43:41 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 462AF1294CA for ; Mon, 9 Jan 2017 21:43:41 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cQpDc-0005mH-Mr; Tue, 10 Jan 2017 05:43:36 +0000 Date: Tue, 10 Jan 2017 14:43:34 +0900 Message-ID: From: Randy Bush To: Stephen Farrell In-Reply-To: <10822F92-5B04-41FD-9D19-5866D7EEACAE@psg.com> References: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> <3ae7d707-3229-2508-7aeb-2cd617aa97fd@cs.tcd.ie> <6e8e235e-0d51-19ab-2651-c1ef1a05ea73@cs.tcd.ie> <10822F92-5B04-41FD-9D19-5866D7EEACAE@psg.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 05:43:43 -0000 i had to do some ascii porn for rob to deal with a secdir reviewer for draft-ietf-sidr-publication. it may help here. i added the routers for this discussion. +------+ +------+ +------+ | CA | | CA | | CA | +------+ +------+ +------+ | | | Publication Protocol | | | draft-ietf-sidr-publication +-------+ | +--------+ Business Relationship Set Up by | | | draft-ietf-sidr-rpki-oob-setup +----v---v--v-----+ | | | Publication | | Repository | | | +-----------------+ Distribution Protocols | draft-ietf-sidr-delta-protocol +--------------+----------------+ and/or rcynic | | | +-------v-----+ +------v------+ +------v------+ | Relying | | Relying | | Relying | | Party | | Party | | Party | +-+-----+----++ +---+-----+---+ +-+--------+--+ | | | | | | | | | | ++ | | +--+ | | RPKI to Router Protocol (RFC 6810) | | | | | | | | draft-ietf-sidr-rpki-rtr-rfc6810-bis v v v v v v v v / \ / \ / \ / \ / \ / \ / \ / \ |Rtr| |Rtr| |Rtr| |Rtr| |Rtr| |Rtr| |Rtr| |Rtr| \ / \ / \ / \ / \ / \ / \ / \ / V V V V V V V V we're talking about 6810-bis here, the rpki-rtr protocol which carries the router keys and origin roas for bgpsec and origin validation. it is a total database push from the RP cache to the router, not a piecemeal router driven request protocol. so a monkey in the middle receives no clues as to what the router is using. there is no side channel leakage that i can see. i would be happy to be educated otherwise. as 6810[-bis] has stripped the crypto of the rpki validataion chain to the root TA, it no longer has object security; red alert. so the two ops drafts, 7115 for origin validation and draft-ietf-sidr-bgpsec-ops for bgpsec, try to be very explicit about transport protection for these data. draft-ietf-sidr-bgpsec-ops points to rfc 7115 for RP cache advice. As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate RPKI caches close to routers that require these data and services in order to minimize the impact of likely failures in local routing, intermediate devices, long circuits, etc. One should also consider trust boundaries, routing bootstrap reachability, etc. For example, a router should bootstrap from a cache that is reachable with minimal reliance on other infrastructure such as DNS or routing protocols. If a router needs its BGP and/or IGP to converge for the router to reach a cache, once a cache is reachable, the router will then have to reevaluate prefixes already learned via BGP. Such configurations should be avoided if reasonably possible. If insecure transports are used between an operator's cache and their router(s), the Transport Security recommendations in [RFC6810] SHOULD be followed. In particular, operators MUST NOT use insecure transports between their routers and RPKI caches located in other Autonomous Systems. so maybe the bgpsec-protocol document can remove, as opposed to add, text just this once? randy From nobody Tue Jan 10 05:37:34 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E655D129FDE; Tue, 10 Jan 2017 05:37:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148405545294.19766.6199092367877276173.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2017 05:37:32 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-publication-10.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 13:37:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : A Publication Protocol for the Resource Public Key Infrastructure (RPKI) Authors : Samuel Weiler Anuja Sonalker Rob Austein Filename : draft-ietf-sidr-publication-10.txt Pages : 20 Date : 2017-01-10 Abstract: This document defines a protocol for publishing Resource Public Key Infrastructure (RPKI) objects. Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects. Even in cases where a certificate issuer runs their own publication repository, it can be useful to run the certificate engine itself on a different machine from the publication repository. This document defines a protocol which addresses these needs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-publication/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-publication-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-publication-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 10 05:48:38 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E12129C97; Tue, 10 Jan 2017 05:48:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148405611560.19775.3614985001584828181.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2017 05:48:35 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-oob-setup-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 13:48:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : An Out-Of-Band Setup Protocol For RPKI Production Services Author : Rob Austein Filename : draft-ietf-sidr-rpki-oob-setup-06.txt Pages : 21 Date : 2017-01-10 Abstract: This note describes a simple out-of-band protocol to ease setup of the RPKI provisioning and publication protocols between two parties. The protocol is encoded in a small number of XML messages, which can be passed back and forth by any mutually agreeable secure means. This setup protocol is not part of the provisioning or publication protocol, rather, it is intended to simplify configuration of these protocols by setting up relationships and exchanging keying material used to authenticate those relationships. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-oob-setup/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-rpki-oob-setup-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-oob-setup-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 10 05:54:44 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EF7129C99 for ; Tue, 10 Jan 2017 05:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 rCHfZdKxI1e5 for ; Tue, 10 Jan 2017 05:54:41 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFCE1129C98 for ; Tue, 10 Jan 2017 05:54:41 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id EDC3D1398C for ; Tue, 10 Jan 2017 13:54:39 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 34D3E461CD36 for ; Tue, 10 Jan 2017 08:54:37 -0500 (EST) Date: Tue, 10 Jan 2017 08:54:37 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: <148405545294.19766.6199092367877276173.idtracker@ietfa.amsl.com> References: <148405545294.19766.6199092367877276173.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170110135437.34D3E461CD36@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-publication-10.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 13:54:42 -0000 Updated in response to IETF Last Call comments. Text additions here were a bit more extensive than I would normally consider during last call, but SECDIR reviewer correctly pointed out that there were some gaps in the background material which made it difficult for someone who hasn't been following this for years to understand where this protocol fits in the RPKI ecology, so the Introduction got both some new text and a nice piece of ASCII art (the latter kindly contributed by Randy, thanks!). No protocol changes, just somewhat expanded explanation and fixes for a few minor omissions (eg, "hash" attributes specified as hexadecimal in the schema but not in the text, oops). From nobody Tue Jan 10 05:57:03 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6F2129FE9 for ; Tue, 10 Jan 2017 05:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 k19wYt_qtwpI for ; Tue, 10 Jan 2017 05:56:57 -0800 (PST) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C87B129CA8 for ; Tue, 10 Jan 2017 05:56:57 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 3918AB8ED for ; Tue, 10 Jan 2017 13:56:57 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 59093461CD65 for ; Tue, 10 Jan 2017 08:56:55 -0500 (EST) Date: Tue, 10 Jan 2017 08:56:55 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: <148405611560.19775.3614985001584828181.idtracker@ietfa.amsl.com> References: <148405611560.19775.3614985001584828181.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170110135655.59093461CD65@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-oob-setup-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 13:57:02 -0000 Updated in response to IETF Last Call comments. Nits, nothing major. From nobody Tue Jan 10 17:47:17 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08BE0129412; Tue, 10 Jan 2017 17:47:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148409923203.22118.16390688105187023010.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2017 17:47:12 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-origin-validation-signaling-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 01:47:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : BGP Prefix Origin Validation State Extended Community Authors : Pradosh Mohapatra Keyur Patel John Scudder Dave Ward Randy Bush Filename : draft-ietf-sidr-origin-validation-signaling-11.txt Pages : 6 Date : 2017-01-10 Abstract: This document defines a new BGP opaque extended community to carry the origination AS validation state inside an autonomous system. IBGP speakers that receive this validation state can configure local policies allowing it to influence their decision process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signaling/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-origin-validation-signaling-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 11 02:55:33 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36197129B8E for ; Wed, 11 Jan 2017 02:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 OrlCxQ-ToKI7 for ; Wed, 11 Jan 2017 02:55:29 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0109.outbound.protection.outlook.com [104.47.0.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21BB3129B8B for ; Wed, 11 Jan 2017 02:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+EoOL+weskW42RfBnt5dOXP5YbsINspyZP2Mj9hpuF4=; b=STvhqJfMkEd2o6TCZfL39TRPGAVJ9nl9JnH6G7lFmvG/5cPNlNcASfxI04jzqvKj4PPCjfiB+/JMU1ShK489ixRoQW/ThzqFNeLWZ3P+B3BtXXXosA0Gk8o7OTuJKF65ghAQGiSawMNa3/6aNdUY8eU5f+8zgFpG7tFZIE3doCw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.135.210.62) by VI1PR0701MB3008.eurprd07.prod.outlook.com (10.173.72.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.6; Wed, 11 Jan 2017 10:55:26 +0000 Message-ID: <003701d26bf8$fbe95500$4001a8c0@gateway.2wire.net> From: t.petch To: Rob Austein , References: <148405611560.19775.3614985001584828181.idtracker@ietfa.amsl.com> <20170110135655.59093461CD65@minas-ithil.hactrn.net> Date: Wed, 11 Jan 2017 10:53:17 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.135.210.62] X-ClientProxiedBy: DB6P18901CA0003.EURP189.PROD.OUTLOOK.COM (10.169.208.141) To VI1PR0701MB3008.eurprd07.prod.outlook.com (10.173.72.150) X-MS-Office365-Filtering-Correlation-Id: 3bf1d687-a4f7-492b-72e1-08d43a1059bc X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:VI1PR0701MB3008; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 3:bP850A+72jL73ykCoF/zE9YdiJN0Fqhp4PmJya5T6aIg/AvtLEun4bVzOzU0kbjFOE7AKe21JapRM1a589Rc/dqpZ274bWS/pkjlxpiqyVaqvdyW8O0F5G9r/mdTb90bJBzFyz8w/ZHasfwEc8h6dLvAszZ+qbxSYQg6Gr+4Fdfa84R8BCeWWhtVXm/wVxRCq2Fv0ZQ+p9tapqze+LOoXMaUZmzfQ3f/uDc142SbiBIMKMw+Dt+A5sws6QayH7Mjji3Rewkv7d3d24dC010sUw== X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 25:KPtlR8D/jRP+bENJVfc+6SfKD4cK0gr8jfeGuXewgCkUKaM3KHEgffJHWYVccqEV++IkD+laomRsSb6LDOHKbYs95FbFTlDCG78GXCv4Qu7Z+UyRtbrWvfPSnSCOYUOuKGJI1CfdZr/Mv8takCX8ovFIGY3fokibohIrmEKufMBYZhzzGB8xL6nV3HnXP+ghxkrt3TjnJGJcuhx5WQd48cIlYSEAgqlrqwRl8Kn4AiwQhaLi3Gh9h3X+e3lo233zEM3+1jxb9YglkgLXY/A2H8vl+v4h6q6U0SSvGt5MOx1HQ6w5jG/TTEuqMmFygQCDWTDXPurkuVdfuXNVzOU/A+33XBJQR5c6HMCA2u/esHuWp4+o63HFu+TM0FsSTww3XqFtmQJXx5MVt96i/7j+utK5VYW24EaYDhZocKtdE84WQg35Iv/0CSYuYiKoyyYN5xLnMUGJ/2XeChoDctDOaOERX1+S5Xb+/eNEjPa8JUAjadkazTzpqL8cZ0Y4NPcbXiRkGoYtgrso3bZbTXXeTe8UGvgnwIrGJUZiN8e1Q6HJClB6qIrXdIC6S8xERg38epXpPagTGHb23ejHZv+veD3MuTn6IEINjoH4/fEKOmH71bPiLUo3RMeEEsPVj1MPZfS6CH5IGJgK2ueH19NEDwTB7l0LPxlMahpX0Z7MP4W21rAG9u0c/RoRnVlrktd2Duur/ndWXg5jFy19ioEeAuJQR893P8W8gXt0UjqX2Pd5FeZrlvaImUaxW8A3Z/Z1RhYvhAz3DbfGSVVO9xEtXzyWe4v/YB2FLSrRKrhfHVxT9bRvTOhNprZYmoMAtIN2EbkQhIijC2PD9Dp6mp4AuCZwT3Hq64DQOm5VyVYqTV8= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 31:RSFbj0zWbyVj8WfO4wAcLxCDurPEIR03hUz7CgpWchd0IH79cPE0IUbYsv3XA2+9njqdFcjHxqvxvgDkh9rv9SnO6xZcStBSsu9uokL++XHJ56dT4UJ9aJR3WJsmTrHFGJZllrPo3SoZ2LQqQ0GuqFSLLWCNZdObhdt5TLUbLJwChaI+Y4OIKUjtjQLJJ4MDZ1689y4AGNTwYpF7qMRXZCrj+9bsfZo0pdmd8EX+d/l2eJghANJBIBFtAL9foStSWf4s2riDWPEWpnboFC77EQ==; 4:dHwo+iB/MFqHCwJN7tfQGgmn7hFW3FmXKKCI5tlIZMIMJSNlyMgSkH3Q2GnsDcE7+3RLmN4nxz5gRlvk2jcJWgLUDZzO7ip9kNHUS21Fa5S6EpW68gt1m5zsnHs+hD4/Hv8n+OO8tDPNv3YNk+E9MSu9dGWfJ+oQApO6tR+Y0dyQZ1yqjq9nDcYLfLw8vbNNFotd8KT3qv8VIh5Rhboi10gfwNk3PZv9ZAahh0vBluUIN2OJati6dXZYtHXRUQKFCNMfhrwwTZFcwbBPDlKET6isLI0p20EI2hJ+1baMU/kduVFI5DxwGGvj0989PysuInG5wznFFRthZ5svuuiSujix/3Yo8ui3C7/eXmHrd0FAYp9tOcpm9KLjdWp3Ygxv9XEUbm1flstDhgLbYR5D0/gDtLilmt2lSHGF37Hw68M7GJl6xd20YElqscF66dRLRF3uMh61VAVDiyEkBAnpx6PiLG8266IrnCXwSmCTuvGTO8P8jh9N5fgz4In/Q2Fol0oA1maKQmyXsp8zPoTTx+OtkkZia/SfVUQpC8FDVa7BvLBgmd1rKpVU1cFokmGrFJ75MS/C9wksw0Qzcgb3nj02rPYTyHSEiCJOvSeRK7Pax6yEtfIoHZpLH74nKCHn X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(131327999870524); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:VI1PR0701MB3008; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB3008; X-Forefront-PRVS: 01842C458A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(39450400003)(13464003)(189002)(199003)(377454003)(38730400001)(230783001)(229853002)(61296003)(66066001)(33646002)(47776003)(6486002)(105586002)(7736002)(6496003)(1456003)(62236002)(4720700003)(5660300001)(44736005)(76176999)(6666003)(106356001)(116806002)(1556002)(25786008)(92566002)(8676002)(9686003)(14496001)(81166006)(81156014)(6306002)(305945005)(230700001)(68736007)(2906002)(50226002)(107886002)(97736004)(5001770100001)(50466002)(81686999)(101416001)(81816999)(50986999)(6116002)(44716002)(42186005)(86362001)(84392002)(3846002)(189998001)(23756003)(74416001)(7726001)(2101003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3008; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR0701MB3008; 23:I5zqyeMJXPag3Q6bBxRrep0bHEYSrHOCC+GLo?= =?iso-8859-1?Q?8wLqv09q3qaMJ0xZoWJ4ian0wIPBGfK2qXAMpOQcWaUlpDNAFcu0TUjmjo?= =?iso-8859-1?Q?L3f9sEzBYbQi4TWRInppNZWViYXFBtVhvi6e/WHSk8tQnn8PSnD2zLJOLg?= =?iso-8859-1?Q?Zal41gvyTlwSxoSsYw2wfaaBLsaVDtoOhodM6o2ULz4HuSrp9A6/MuLZa0?= =?iso-8859-1?Q?LLA/A1cS/0fb0M0v353TQ+j6/mXFYJtZzmnDkFx7kC4BSfH1SVG3QExSPd?= =?iso-8859-1?Q?WxPzqELzFqmunZveKqym0dSOmXIOCEObdt2Rd18Zznl7ey4AU8X1tnEvVX?= =?iso-8859-1?Q?c9V0yYtcX7t4ffRg54drXITLsX0YHCaQU52QURCmg05xbDwCLO01he6Dsc?= =?iso-8859-1?Q?d+lnaQaxd924D7l01iQlfhHjNKoudW/TjpV12NQIHBwiCTCjbBa3Yp8hs+?= =?iso-8859-1?Q?/jKJyPsAhEdjSCj3nMMGqeO1s8kHIibWDawdFwEwMqqdsqHYHNPJ2xlntB?= =?iso-8859-1?Q?rgdZc/08VbUyNMUVlfpPqKNoXcUggRQ4R8xAngdL5Zbk6aMDiH6vrXwvNL?= =?iso-8859-1?Q?o2bPVljNGphJyYejt8stAHljKUerPw4UWeDofs3lROY20E4Kjc7UBjlOBO?= =?iso-8859-1?Q?mMs3DpI70AMgxQbLmS3/CAngIRi9ynMEBqp91ls5kmhgHz0bQFWgHVeqDS?= =?iso-8859-1?Q?/EwWKMhOPKuqnoh0WqUsuV7o5tpAqDMvCAKxo/EgxLaiiqeCcYW8z37vPE?= =?iso-8859-1?Q?Jl1Zq9yDI/gzIDZGRroMFXH01Hn7xTQKF51Dg4qVyu/ZrEOddjulTqAIYT?= =?iso-8859-1?Q?i7lKtocCFHtn6R2m1qJ7QbTRpyisDxkTSsJywa+d8cU+jlDwEr13uVVQ1z?= =?iso-8859-1?Q?U+RTyL+K7dRyp19jOdrbgM/F4FZW1ITFW3DILL+HtDmGEc1iARN8GJrYkE?= =?iso-8859-1?Q?8wvcOpA3CzNOLtzdQUyK4zA1qFfF9ReVaKhrl58fpn2V/4UrQIXSETnvLs?= =?iso-8859-1?Q?TANLFSsK4SLodu8H7nXHU4ytw9OUZZPLOhpf2jeMcbaLslKL3sTZQb6wtA?= =?iso-8859-1?Q?sUmx81mQTF5K6bU0eOPyqdjAYCzJvOqlP0osCCSyDhlu3SeaiJuEOE8RoT?= =?iso-8859-1?Q?6ZhDcvSKX8Ar+lWs25OidOo1T3vzaqzEyeY5PwHWsffHv9uEltOpfUbWDw?= =?iso-8859-1?Q?RSui6IXkCrR3xbWZYgvItPGvwrDhYWWPBH+e8M9gXZlPSYWoFXhTzJX6Wz?= =?iso-8859-1?Q?JROqx8WsT8rWZNiwtjpPZI+nS4zLR/n1WjgYvMHznjPb1k1HTI9GpAavdc?= =?iso-8859-1?Q?DO7cR+DKJ7A6TSZBBYyeKyWOUiAKplXkONlP0WJhP/x4EgqTePc1v3nzY6?= =?iso-8859-1?Q?Po8trkp7NOUkVXNRgWWhmd26Hv1VMRdrRQpMhWykgi94NwozfoUBwkziXo?= =?iso-8859-1?Q?g49k/QQwUIcVOqDv+sv8PUvAtWy1XELE722debYktUvdQNnofkv4OhPd82?= =?iso-8859-1?Q?sSrxmNbwUCF4DzfdIDnQ9E=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 6:jwjpsdvePLzbkjE1K1DOx6Z1oMMO+RkdPrXdQ2QUyibZpCde9glvP499nRN28C22Q0jycmcLh2MsM/9H53eRUKQUTBJxc2euf+ayM12oDsgPxMB4IWVS9fVeAt9bLbmhUwZVGSqKYNPIO4AJJeFkQ/0tKhPCQGTgysQB35E6sBZ1OA/paKXb8qq4q58pxqXveV4SbSNdGOEO13fiJIfcmO/EGCXM3niY3miOvv2HaWf18tzcZZWQqrDk4R3sb6vD96mLUBs0EqerkdX43doSQonlTDSlCedf8yVaiE/gZOYb/NaMTwquoS/7I+iH0EipyG3wszALSiHQl3UfFCy88YqtLnWPcaFA8Ir9pOI0g0aWsXbIs1EZxZllOeS2XjimshbCGQ4VyOkcxpotHDPZKu33wGBhQnxjZcWDuLSx8XQ=; 5:R6nu4ENW66O20LsjwpRm+uhrlyomU5QuvwfFuN9jpfGZpNPhmPXhxU6yktBNudDfliAbAvSUKfm4vCer62UW5Ez/7mPBxhVYFSb/DJN/n7cb0bxsa3hPpzoo2V5KYZLixJZ3stqfYddjsZORKvm7OnsuaYIKNf+tkYRIR5Li5Tg=; 24:QfvV1PPIW5KXe/HRkbquizpCa1gT4xqy/jaQKpY+Mh8j4PkoIiTogYWamWoGjzOS4pd/xejdhQi2FyDcaIk/YvSDfTNJJ6UZBHvk0ONHkCE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 7:RpE/EJqW5ab8sAqo24hc4ZJrCfbSkHN4nb87KUmB0SIRMcO9IVASmOdS8SI40g2uJFlO1YuPEri0wqXWVi9yLvzFJSy2lsGdm961XCOVefN8veHVo3E3drkEOiC112+Wpyh4xC3PzUSnboJgSYEXE7yh0YLbrZDbwyT5zJYJ7cVEWEfv2iO3m4pw7B/wrG+ukXC1DBy1YkTeGOsKnVP/4oWZwNNBWblNKR+NGTWpzOUqiTmdcV8r9Z/+39nTNsguRGb6TCGB3nR1XV1JPYXfisNoHMJbfmesSthnOeR4BQ/66pM1cAvV/zhcYt1OUkfUJMZNX9qifDtb8YT5X2tMsK8mqnWjhJKvEu8ULC6nqps8on48apBLlfOBNK18w7Dr5CvakJk5x1Ly7qV/g6YxtuQqm1CmEb60CnxPVCUNjQ+aX7X72wFNf/fiH0bqICrlMXfK699FF+XDk6wknTNBrg== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2017 10:55:26.1919 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3008 Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-oob-setup-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 10:55:32 -0000 ---- Original Message ----- From: "Rob Austein" To: Sent: Tuesday, January 10, 2017 1:56 PM > Updated in response to IETF Last Call comments. Nits, nothing major. Ok Two thoughts for the RFC Editor referral: If elements are present, they /suggests/suggest/ Alice, Bob, and Carol each /generates/generate/ and did you see the review of sidr-publication-09 which was emphatic that /RelaxNG/RELAX NG/ * * as you have in the title in the Reference? Tom Petch > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Jan 11 07:25:28 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 513B71294EF; Wed, 11 Jan 2017 07:25:19 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2017 07:25:19 -0800 Archived-At: Cc: draft-ietf-sidr-origin-validation-signaling@ietf.org, sidr@ietf.org, sidr-chairs@ietf.org, The IESG , sandy@tislabs.com, rfc-editor@rfc-editor.org Subject: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 15:25:19 -0000 The IESG has approved the following document: - 'BGP Prefix Origin Validation State Extended Community' (draft-ietf-sidr-origin-validation-signaling-11.txt) as Proposed Standard This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signaling/ Technical Summary This document defines a new BGP opaque extended community to carry the origination AS validation state inside an autonomous system. IBGP speakers that receive this validation state can configure local policies allowing it to influence their decision process. Working Group Summary This document has had consistent interest from the working group. Because it defines a new BGP community, it was reviewed by the idr working group as well. Document Quality The document has been implemented by major router vendors. It is known to be in use in two large IXPs, AMS-IX and DE-CIX. Personnel Document Shepherd: Sandra Murphy Responsible Area Director: Alvaro Retana From nobody Wed Jan 11 08:31:16 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE451129F2B for ; Wed, 11 Jan 2017 08:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 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_PASS=-0.001, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 O-Qwamx8fXDj for ; Wed, 11 Jan 2017 08:31:12 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0090.outbound.protection.outlook.com [23.103.200.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866A0129F2F for ; Wed, 11 Jan 2017 08:31:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ufrup9X4uLW46lbgFj+wtDgE+GBE/L5X6LpexWc4PfI=; b=QDkfX8RkE9w4NLnCznlJW+26sG3q/kSPfWZYfwoL9ySoYf2LZYbc08B5ErNJPoUXD0yC8yTbflZbN8lZyMKmFjSsuyYeUJspe3+AArPGS8IenVWufuVeFQJZlnwA9dqcHa0mLLePfdmnP8U78x5az6cETYhjJim3TJpSbma8nVs= Received: from BL2PR09MB0996.namprd09.prod.outlook.com (10.167.102.15) by BL2PR09MB0994.namprd09.prod.outlook.com (10.167.102.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.7; Wed, 11 Jan 2017 16:31:06 +0000 Received: from BL2PR09MB0996.namprd09.prod.outlook.com ([10.167.102.15]) by BL2PR09MB0996.namprd09.prod.outlook.com ([10.167.102.15]) with mapi id 15.01.0829.017; Wed, 11 Jan 2017 16:31:06 +0000 From: "Borchert, Oliver (Fed)" To: sidr list Thread-Topic: IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs Thread-Index: AQHSbCgbzrHhXkAXSUqZuVZbpiHo6g== Date: Wed, 11 Jan 2017 16:31:06 +0000 Message-ID: <2459DA8D-593F-4B75-9C74-619DDBA907E4@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.140.59] x-microsoft-exchange-diagnostics: 1; BL2PR09MB0994; 7:Y9RayX8DyGGNHzGPmMipmQ7pqS5xKzRGNVZR0a+cJDMIJLCwcsPcPdRcNsRZaA9c1moUm5Ut5whRAt4YjhDB8iTRh0pCgDQbChaFDHf1gN/f4dbffmd4oDwpBHLbqmt2pAbB/xaG/ab+KFw2vAN6KkGrJ8e+8bWZZGp8Q+NIFM4MS7eRkiAiuPICAe+O38URxqvbYotAoQF0EYXS9oCTuo+v2s3qNhDTpSji0UY9fK3X1EAtdBgDkF5sRw7doq7TzhJl5rh7riIiX02zic1fEXHlCrOlmSJ9ezB6DDfbRI5nul1CGCTBJpkmrDkoWmapQxcTGCUg3LMX1qjlVdh6nLbVjY+6rNi5J6LWFZcJ01ZHCEBwgot2Y46uICQ8PeUOTW8TIUuDBj9P2geUVCiB1dbUvinYY/T7KcmOIGkzZ5pvoAmA9q6WrtBN4fj3vJbDtBG8ijnws4H4DeltpQxR+A== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39860400002)(39450400003)(39840400002)(39410400002)(40224003)(30584003)(199003)(189002)(101416001)(66066001)(50986999)(54356999)(99936001)(122556002)(86362001)(5890100001)(575784001)(36756003)(83506001)(83716003)(230783001)(82746002)(4001350100001)(97736004)(107886002)(189998001)(33656002)(105586002)(106116001)(106356001)(6512007)(99286003)(6306002)(38730400001)(6506006)(25786008)(77096006)(6486002)(54906002)(6436002)(8676002)(6916009)(92566002)(54896002)(4001430100002)(8936002)(81156014)(81166006)(3280700002)(2906002)(7736002)(3660700001)(4326007)(3846002)(6116002)(102836003)(110136003)(68736007)(2900100001)(5660300001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR09MB0994; H:BL2PR09MB0996.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 87593b82-9502-4295-52d9-08d43a3f3e0c x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BL2PR09MB0994; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BL2PR09MB0994; BCL:0; PCL:0; RULEID:; SRVR:BL2PR09MB0994; x-forefront-prvs: 01842C458A received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_004_2459DA8D593F4B759C74619DDBA907E4nistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2017 16:31:06.3477 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR09MB0994 Archived-At: Subject: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 16:31:15 -0000 --_004_2459DA8D593F4B759C74619DDBA907E4nistgov_ Content-Type: multipart/alternative; boundary="_000_2459DA8D593F4B759C74619DDBA907E4nistgov_" --_000_2459DA8D593F4B759C74619DDBA907E4nistgov_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBlbWFpbCBjb250YWlucyBzb21lIHRlc3QgdmVjdG9ycyBmb3IgZHJhZnQtaWV0Zi1zaWRy LWJncHNlYy1wa2ktYWxncyB0aGF0IHdlcmUgZ2VuZXJhdGVkIGFzIGEgcmVzdWx0IG9mIElFU0cv YXV0aG9yIGRpc2N1c3Npb25zOyBTdGVwaGVuIHN1Z2dlc3RlZCB0aGF0IHRoZSBkcmFmdCBjb3Vs ZCB1c2Ugc29tZSBleGFtcGxlcyBhbmQgaGXigJlzIHJpZ2h0IHNvIHdl4oCZZCBsaWtlIHRvIGlu Y2x1ZGUgdGhpcyBhcyBhbiBJUHY0IGV4YW1wbGUuICBJbiBjYXNlIHRoZSBleGFtcGxlIGlzIHZp Y3RpbSB0byBzb21lIGNyYXp5IGxpbmUgd3JhcHBpbmcgb3IgZm9yIG5pY2UgZm9ybWF0dGVkIHJl YWRpbmcsIEkgYWxzbyBhdHRhY2hlZCB0aGUgZXhhbXBsZSBhcyB0ZXh0IGZpbGUgdG8gdGhpcyBl bWFpbC4NCg0KVGhhbmtzLA0KT2xpdmVyDQoNCi0tLS1zbmlwLS0tLXNuaXAtLS0tc25pcC0tLS1z bmlwLS0tLQ0KDQpUb3BvbG9neToNCg0KQVMoNjQ0OTYpLS0tLUFTKDY1NTM2KS0tLS1BUyg2NTUz NykNCg0KUHJlZml4IEFubm91bmNlbWVudDogQVMoNjQ0OTYpLCAxOTIuMC4yLjAvMjQNCg0KRm9y IHRoaXMgZXhhbXBsZSB0aGUgRUNEU0EgYWxnb3JpdGhtIHdhcyBwcm92aWRlZCB3aXRoIGEgc3Rh dGljIGsgdG8NCm1ha2UgdGhlIHJlc3VsdCBkZXRlcm1pbmlzdGljLg0KVGhlIGsgdXNlZCBmb3Ig YWxsIHNpZ25hdHVyZSBvcGVyYXRpb25zIHdhcyB0YWtlbiBmcm9tIFJGQyA2OTc5LA0KY2hhcHRl ciBBLjIuNSDigJxTaWduYXR1cmVzIFdpdGggU0hBLTI1NiwgbWVzc2FnZSAnc2FtcGxlJ+KAnS4N Cg0KICBrID0gQTZFM0M1N0REMDFBQkU5MDA4NjUzODM5ODM1NURENEMzQjE3QUE4NzMzODJCMEYy NEQ2MTI5NDkzRDhBQUQ2MA0KDQpLZXlzIG9mIEFTNjQ0OTY6DQo9PT09PT09PT09PT09PT09DQpz a2k6IEFCNEQ5MTBGNTVDQUU3MUEyMTVFRjNDQUZFM0FDQzQ1QjVFRUMxNTQNCg0KcHJpdmF0ZSBr ZXk6DQogIHggPSBEOEFBNERGQkUyNDc4Rjg2RTg4QTc0NTFCRjA3NTU2NTcwOUM1NzVBQzFDMTM2 RDA4MUM1NDAyNTRDQTQ0MEI5DQoNCnB1YmxpYyBrZXk6DQogIFV4ID0gNzM5MUJBQkI5MkEwQ0Iz QkUxMEU1OUIxOUVCRkZCMjE0RTA0QTkxRTBDQkExQjEzOUE3RDM4RDkwRjc3RTU1QQ0KICBVeSA9 IEEwNUI4RTY5NTY3OEUwRkExNjkwNEI1NUQ5RDRGNUMwREZDNTg4OTVFRTUwQkM0Rjc1RDIwNUEy NUJEMzZGRjUNCg0KUm91dGVyIEtleSBDZXJ0aWZpY2F0ZSBleGFtcGxlIHVzaW5nIE9wZW5TU0wg MS4wLjFlLWZpcHMgMTEgRmViIDIwMTMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDZXJ0aWZpY2F0ZToNCiAgICBE YXRhOg0KICAgICAgICBWZXJzaW9uOiAzICgweDIpDQogICAgICAgIFNlcmlhbCBOdW1iZXI6IDMx NDgyMzQ1MTEgKDB4YmJhNjNmMGYpDQogICAgU2lnbmF0dXJlIEFsZ29yaXRobTogZWNkc2Etd2l0 aC1TSEEyNTYNCiAgICAgICAgSXNzdWVyOiBDTj1ST1VURVItMDAwMEZCRjANCiAgICAgICAgVmFs aWRpdHkNCiAgICAgICAgICAgIE5vdCBCZWZvcmU6IEphbiAxMCAxOTo1NTo0NCAyMDE3IEdNVA0K ICAgICAgICAgICAgTm90IEFmdGVyIDogT2N0IDI1IDE5OjU1OjQ0IDIyOTAgR01UDQogICAgICAg IFN1YmplY3Q6IENOPVJPVVRFUi0wMDAwRkJGMA0KICAgICAgICBTdWJqZWN0IFB1YmxpYyBLZXkg SW5mbzoNCiAgICAgICAgICAgIFB1YmxpYyBLZXkgQWxnb3JpdGhtOiBpZC1lY1B1YmxpY0tleQ0K ICAgICAgICAgICAgICAgIFB1YmxpYy1LZXk6ICgyNTYgYml0KQ0KICAgICAgICAgICAgICAgIHB1 YjoNCiAgICAgICAgICAgICAgICAgICAgMDQ6NzM6OTE6YmE6YmI6OTI6YTA6Y2I6M2I6ZTE6MGU6 NTk6YjE6OWU6YmY6DQogICAgICAgICAgICAgICAgICAgIGZiOjIxOjRlOjA0OmE5OjFlOjBjOmJh OjFiOjEzOjlhOjdkOjM4OmQ5OjBmOg0KICAgICAgICAgICAgICAgICAgICA3NzplNTo1YTphMDo1 Yjo4ZTo2OTo1Njo3ODplMDpmYToxNjo5MDo0Yjo1NToNCiAgICAgICAgICAgICAgICAgICAgZDk6 ZDQ6ZjU6YzA6ZGY6YzU6ODg6OTU6ZWU6NTA6YmM6NGY6NzU6ZDI6MDU6DQogICAgICAgICAgICAg ICAgICAgIGEyOjViOmQzOjZmOmY1DQogICAgICAgICAgICAgICAgQVNOMSBPSUQ6IHByaW1lMjU2 djENCiAgICAgICAgWDUwOXYzIGV4dGVuc2lvbnM6DQogICAgICAgICAgICBYNTA5djMgS2V5IFVz YWdlOg0KICAgICAgICAgICAgICAgIERpZ2l0YWwgU2lnbmF0dXJlDQogICAgICAgICAgICBYNTA5 djMgU3ViamVjdCBLZXkgSWRlbnRpZmllcjoNCiAgICAgICAgICAgICAgICBBQjo0RDo5MTowRjo1 NTpDQTpFNzoxQToyMTo1RTpGMzpDQTpGRTozQTpDQzo0NTpCNTpFRTpDMTo1NA0KICAgICAgICAg ICAgWDUwOXYzIEV4dGVuZGVkIEtleSBVc2FnZToNCiAgICAgICAgICAgICAgICAxLjMuNi4xLjUu NS43LjMuMzANCiAgICAgICAgICAgIHNiZ3AtYXV0b25vbW91c1N5c051bTogY3JpdGljYWwNCiAg ICAgICAgICAgICAgICBBdXRvbm9tb3VzIFN5c3RlbSBOdW1iZXJzOg0KICAgICAgICAgICAgICAg ICAgNjQ0OTYNCiAgICAgICAgICAgICAgICBSb3V0aW5nIERvbWFpbiBJZGVudGlmaWVyczoNCiAg ICAgICAgICAgICAgICAgIGluaGVyaXQNCg0KICAgIFNpZ25hdHVyZSBBbGdvcml0aG06IGVjZHNh LXdpdGgtU0hBMjU2DQogICAgICAgICAzMDo0NjowMjoyMTowMDpjYjo0ODoxOTo3YTo2NzpmZDo5 ODphNTowYzplMzphYjowZTo1OToNCiAgICAgICAgIGZkOmZiOjFkOjZmOjZhOjRjOmZjOmY3OmU3 OmQ3Ojc3OjNhOjJjOjMzOjgyOjAyOjU3OmNjOg0KICAgICAgICAgNzA6MDI6MjE6MDA6ZWE6ZjE6 MmM6MDg6MDU6Yjk6ZGY6NDg6OGY6OTQ6OGQ6ZTA6Y2Y6MjM6DQogICAgICAgICBlODo4ZTo3MTo1 NjoxMzo0ZTo0NDpiMjozNTo2Mjo5YjpjZDphMTo5Yzo5ZDowNDowZjpkYw0KLS0tLS1CRUdJTiBD RVJUSUZJQ0FURS0tLS0tDQpNSUlCalRDQ0FUS2dBd0lCQWdJRkFMdW1Qdzh3Q2dZSUtvWkl6ajBF QXdJd0dqRVlNQllHQTFVRUF3d1BVazlWDQpWRVZTTFRBd01EQkdRa1l3TUNBWERURTNNREV4TURF NU5UVTBORm9ZRHpJeU9UQXhNREkxTVRrMU5UUTBXakFhDQpNUmd3RmdZRFZRUUREQTlTVDFWVVJW SXRNREF3TUVaQ1JqQXdXVEFUQmdjcWhrak9QUUlCQmdncWhrak9QUU1CDQpCd05DQUFSemticTdr cURMTytFT1diR2V2L3NoVGdTcEhneTZHeE9hZlRqWkQzZmxXcUJiam1sV2VPRDZGcEJMDQpWZG5V OWNEZnhZaVY3bEM4VDNYU0JhSmIwMi8xbzJNd1lUQUxCZ05WSFE4RUJBTUNCNEF3SFFZRFZSME9C QllFDQpGS3ROa1E5Vnl1Y2FJVjd6eXY0NnpFVzE3c0ZVTUJNR0ExVWRKUVFNTUFvR0NDc0dBUVVG QndNZU1CNEdDQ3NHDQpBUVVGQndFSUFRSC9CQTh3RGFBSE1BVUNBd0Q3OEtFQ0JRQXdDZ1lJS29a SXpqMEVBd0lEU1FBd1JnSWhBTXRJDQpHWHBuL1ppbERPT3JEbG45K3gxdmFrejg5K2ZYZHpvc000 SUNWOHh3QWlFQTZ2RXNDQVc1MzBpUGxJM2d6eVBvDQpqbkZXRTA1RXNqVmltODJobkowRUQ5dz0N Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0NCg0KDQoNCktleXMgb2YgQVMoNjU2MzYpOg0KPT09 PT09PT09PT09PT09PT09DQpza2k6IDQ3RjIzQkYxQUIyRjhBOUQyNjg2NEVCQkQ4REYyNzExQzc0 NDA2RUMNCg0KcHJpdmF0ZSBrZXk6DQogIHggPSA2Q0IyRTkzMUIxMTJGMjQ1NTRCQ0RDQUFGRDk1 NTNBOTUxOUE5QUYzM0MwMjNCNjA4NDZBMjFGQzk1NTgzMTcyDQoNCnB1YmxpYyBrZXk6DQogIFV4 ID0gMjhGQzVGRTlBRkNGNUY0Q0FCM0Y1Rjg1Q0IyMTJGQzFFOUQwRTBEQkVBRUU0MjVCRDJGMEQz MTc1QUEwRTk4OQ0KICBVeSA9IEVBOUI2MDNFMzhGMzVGQjMyOURGNDk1NjQxRjJCQTA0MEYxQzNB QzYxMzgzMDdGMjU3Q0JBNkI4QjU4OEY0MUYNCg0KUm91dGVyIEtleSBDZXJ0aWZpY2F0ZSBleGFt cGxlIHVzaW5nIE9wZW5TU0wgMS4wLjFlLWZpcHMgMTEgRmViIDIwMTMNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpD ZXJ0aWZpY2F0ZToNCiAgICBEYXRhOg0KICAgICAgICBWZXJzaW9uOiAzICgweDIpDQogICAgICAg IFNlcmlhbCBOdW1iZXI6IDE1NzI3MjYyNjggKDB4NWRiZGU1ZmMpDQogICAgU2lnbmF0dXJlIEFs Z29yaXRobTogZWNkc2Etd2l0aC1TSEEyNTYNCiAgICAgICAgSXNzdWVyOiBDTj1ST1VURVItMDAw MTAwMDANCiAgICAgICAgVmFsaWRpdHkNCiAgICAgICAgICAgIE5vdCBCZWZvcmU6IEphbiAxMCAx OTo1NTo1MCAyMDE3IEdNVA0KICAgICAgICAgICAgTm90IEFmdGVyIDogT2N0IDI1IDE5OjU1OjUw IDIyOTAgR01UDQogICAgICAgIFN1YmplY3Q6IENOPVJPVVRFUi0wMDAxMDAwMA0KICAgICAgICBT dWJqZWN0IFB1YmxpYyBLZXkgSW5mbzoNCiAgICAgICAgICAgIFB1YmxpYyBLZXkgQWxnb3JpdGht OiBpZC1lY1B1YmxpY0tleQ0KICAgICAgICAgICAgICAgIFB1YmxpYy1LZXk6ICgyNTYgYml0KQ0K ICAgICAgICAgICAgICAgIHB1YjoNCiAgICAgICAgICAgICAgICAgICAgMDQ6Mjg6ZmM6NWY6ZTk6 YWY6Y2Y6NWY6NGM6YWI6M2Y6NWY6ODU6Y2I6MjE6DQogICAgICAgICAgICAgICAgICAgIDJmOmMx OmU5OmQwOmUwOmRiOmVhOmVlOjQyOjViOmQyOmYwOmQzOjE3OjVhOg0KICAgICAgICAgICAgICAg ICAgICBhMDplOTo4OTplYTo5Yjo2MDozZTozODpmMzo1ZjpiMzoyOTpkZjo0OTo1NjoNCiAgICAg ICAgICAgICAgICAgICAgNDE6ZjI6YmE6MDQ6MGY6MWM6M2E6YzY6MTM6ODM6MDc6ZjI6NTc6Y2I6 YTY6DQogICAgICAgICAgICAgICAgICAgIGI4OmI1Ojg4OmY0OjFmDQogICAgICAgICAgICAgICAg QVNOMSBPSUQ6IHByaW1lMjU2djENCiAgICAgICAgWDUwOXYzIGV4dGVuc2lvbnM6DQogICAgICAg ICAgICBYNTA5djMgS2V5IFVzYWdlOg0KICAgICAgICAgICAgICAgIERpZ2l0YWwgU2lnbmF0dXJl DQogICAgICAgICAgICBYNTA5djMgU3ViamVjdCBLZXkgSWRlbnRpZmllcjoNCiAgICAgICAgICAg ICAgICA0NzpGMjozQjpGMTpBQjoyRjo4QTo5RDoyNjo4Njo0RTpCQjpEODpERjoyNzoxMTpDNzo0 NDowNjpFQw0KICAgICAgICAgICAgWDUwOXYzIEV4dGVuZGVkIEtleSBVc2FnZToNCiAgICAgICAg ICAgICAgICAxLjMuNi4xLjUuNS43LjMuMzANCiAgICAgICAgICAgIHNiZ3AtYXV0b25vbW91c1N5 c051bTogY3JpdGljYWwNCiAgICAgICAgICAgICAgICBBdXRvbm9tb3VzIFN5c3RlbSBOdW1iZXJz Og0KICAgICAgICAgICAgICAgICAgNjU1MzYNCiAgICAgICAgICAgICAgICBSb3V0aW5nIERvbWFp biBJZGVudGlmaWVyczoNCiAgICAgICAgICAgICAgICAgIGluaGVyaXQNCg0KICAgIFNpZ25hdHVy ZSBBbGdvcml0aG06IGVjZHNhLXdpdGgtU0hBMjU2DQogICAgICAgICAzMDo0NjowMjoyMTowMDpi MDozODpiZjo0YTphZTpjOToxZTplMTpjZDpiMToxNzo4NDozMzoNCiAgICAgICAgIGY4OjMyOmQz OmM0OmJhOjQ0OjZhOjFhOjE1OjNiOmMwOmIyOjhkOjYxOjllOjZlOjdmOjFmOg0KICAgICAgICAg MTQ6MDI6MjE6MDA6YzA6OGI6Yjg6Yjg6OWY6YTQ6ZjU6Yjk6NTQ6Njg6OTg6MGU6YmY6OTY6DQog ICAgICAgICBhMDpmYzoyYjo2ZTplYjo0MToyZTplYzoxZDo4MzoyMDo4Yzo3MjoyYzphYzpkZjox Mzo1OA0KLS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tDQpNSUlCakRDQ0FUR2dBd0lCQWdJRVhi M2wvREFLQmdncWhrak9QUVFEQWpBYU1SZ3dGZ1lEVlFRRERBOVNUMVZVDQpSVkl0TURBd01UQXdN REF3SUJjTk1UY3dNVEV3TVRrMU5UVXdXaGdQTWpJNU1ERXdNalV4T1RVMU5UQmFNQm94DQpHREFX QmdOVkJBTU1EMUpQVlZSRlVpMHdNREF4TURBd01EQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlB d0VIDQpBMElBQkNqOFgrbXZ6MTlNcXo5Zmhjc2hMOEhwME9EYjZ1NUNXOUx3MHhkYW9PbUo2cHRn UGpqelg3TXAzMGxXDQpRZks2QkE4Y09zWVRnd2Z5Vjh1bXVMV0k5QitqWXpCaE1Bc0dBMVVkRHdR RUF3SUhnREFkQmdOVkhRNEVGZ1FVDQpSL0k3OGFzdmlwMG1oazY3Mk44bkVjZEVCdXd3RXdZRFZS MGxCQXd3Q2dZSUt3WUJCUVVIQXg0d0hnWUlLd1lCDQpCUVVIQVFnQkFmOEVEekFOb0Fjd0JRSURB UUFBb1FJRkFEQUtCZ2dxaGtqT1BRUURBZ05KQURCR0FpRUFzRGkvDQpTcTdKSHVITnNSZUVNL2d5 MDhTNlJHb2FGVHZBc28xaG5tNS9IeFFDSVFEQWk3aTRuNlQxdVZSb21BNi9scUQ4DQpLMjdyUVM3 c0hZTWdqSElzck44VFdBPT0NCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0NCg0KDQoNCkJHUFNl YyBVcGRhdGUgZnJvbSBBUyg2NTUzNikgdG8gQVMoNjU1MzcpOg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KQmluYXJ5IEZvcm0gb2YgQkdQU2VjIFVwZGF0ZSAo VENQLURVTVApOg0KRkYgRkYgRkYgRkYgRkYgRkYgRkYgRkYgIEZGIEZGIEZGIEZGIEZGIEZGIEZG IEZGDQowMSAwMCAwMiAwMCAwMCAwMCBFOSA0MCAgMDEgMDEgMDIgODAgMDQgMDQgMDAgMDANCjAw IDAwIDgwIDBFIDBEIDAwIDAxIDAxICAwNCBDNiAzMyA2NCA2NCAwMCAxOCBDMA0KMDAgMDIgOTAg MUUgMDAgQ0EgMDAgMEUgIDAxIDAwIDAwIDAxIDAwIDAwIDAxIDAwDQowMCAwMCBGQiBGMCAwMCBC QyAwMSA0NyAgRjIgM0IgRjEgQUIgMkYgOEEgOUQgMjYNCjg2IDRFIEJCIEQ4IERGIDI3IDExIEM3 ICA0NCAwNiBFQyAwMCA0NiAzMCA0NCAwMg0KMjAgNzIgMTQgQkMgOTYgNDcgMTYgMEIgIEJEIDM5 IEZGIDJGIDgwIDUzIDNGIDVEDQpDNiBERCBENyAwRCBERiA4NiBCQiA4MSAgNTYgNjEgRTggMDUg RDUgRDQgRTYgRjINCjdDIDAyIDIwIDJEIERDIDAwIDNDIDY0ICBCRSA3QiAyOSBDOSBFQiBEQiBD OCBBNA0KOTcgRUQgNjYgMjggNUUgRTkgMjIgNzYgIDgzIEU2IEMxIDc4IENFIDhEIEU2IEQzDQo1 OSA1RiA0MSBBQiA0RCA5MSAwRiA1NSAgQ0EgRTcgMUEgMjEgNUUgRjMgQ0EgRkUNCjNBIENDIDQ1 IEI1IEVFIEMxIDU0IDAwICA0NyAzMCA0NSAwMiAyMCA3MiAxNCBCQw0KOTYgNDcgMTYgMEIgQkQg MzkgRkYgMkYgIDgwIDUzIDNGIDVEIEM2IEREIEQ3IDBEDQpERiA4NiBCQiA4MSA1NiA2MSBFOCAw NSAgRDUgRDQgRTYgRjIgN0MgMDIgMjEgMDANCkM2IDE3IDE5IDM0IDA3IDQzIDA2IDNCICA4QSA1 QyBDRCA1NCAxNiAzOSAwQiAzMQ0KMjEgMUQgM0MgNTIgNDggMDcgOTUgODcgIEQwIDEzIDEzIDdC IDQxIENEIDIzIEUyDQoNCg0KU2lnbmF0dXJlIEZyb20gQVMoNjQ0OTYpIHRvIEFTKDY1NTM2KToN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRGlnZXN0OiAgICAyMSAz MyBFNSBDQSBBMCAyNiBCRSAwNyAgIDNEIDlDIDFCIDRFIEZFIEI5IEI5IDc3DQogICAgICAgICAg IDlGIDIwIEY4IEY1IERFIDI5IEZBIDk4ICAgNDAgMDAgOUYgNjANClNpZ25hdHVyZTogMzAgNDUg MDIgMjAgNzIgMTQgQkMgOTYgICA0NyAxNiAwQiBCRCAzOSBGRiAyRiA4MA0KICAgICAgICAgICA1 MyAzRiA1RCBDNiBERCBENyAwRCBERiAgIDg2IEJCIDgxIDU2IDYxIEU4IDA1IEQ1DQogICAgICAg ICAgIEQ0IEU2IEYyIDdDIDAyIDIxIDAwIEM2ICAgMTcgMTkgMzQgMDcgNDMgMDYgM0IgOEENCiAg ICAgICAgICAgNUMgQ0QgNTQgMTYgMzkgMEIgMzEgMjEgICAxRCAzQyA1MiA0OCAwNyA5NSA4NyBE MA0KICAgICAgICAgICAxMyAxMyA3QiA0MSBDRCAyMyBFMg0KDQpTaWduYXR1cmUgRnJvbSBBUyg2 NTUzNikgdG8gQVMoNjU1MzcpOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCkRpZ2VzdDogICAgNDYgNEIgNTcgQ0UgQjEgMkQgMTggQjAgICBGRCAxQSAxQSAzNSA5NCAx NyAzQSA0QQ0KICAgICAgICAgICAwOSA4OCBFNSBGNCBFRCBFRCAyRiAzRCAgIDgzIDA4IDVBIEE4 DQpTaWduYXR1cmU6IDMwIDQ0IDAyIDIwIDcyIDE0IEJDIDk2ICAgNDcgMTYgMEIgQkQgMzkgRkYg MkYgODANCiAgICAgICAgICAgNTMgM0YgNUQgQzYgREQgRDcgMEQgREYgICA4NiBCQiA4MSA1NiA2 MSBFOCAwNSBENQ0KICAgICAgICAgICBENCBFNiBGMiA3QyAwMiAyMCAyRCBEQyAgIDAwIDNDIDY0 IEJFIDdCIDI5IEM5IEVCDQogICAgICAgICAgIERCIEM4IEE0IDk3IEVEIDY2IDI4IDVFICAgRTkg MjIgNzYgODMgRTYgQzEgNzggQ0UNCiAgICAgICAgICAgOEQgRTYgRDMgNTkgNUYgNDENCg0KDQpU aGUgaHVtYW4gcmVhZGFibGUgb3V0cHV0IGlzIHByb2R1Y2VkIHVzaW5nIGJncHNlYy1pbywgYSBi Z3BzZWMNCnRyYWZmaWMgZ2VuZXJhdG9yIHRoYXQgdXNlcyBhIHdpcmVzaGFyayBsaWtlIHByaW50 b3V0Lg0KDQpTZW5kIFVwZGF0ZSBNZXNzYWdlDQorLS1tYXJrZXI6IEZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGDQorLS1sZW5ndGg6IDI1Ng0KKy0tdHlwZTogICAyIChVUERBVEUpDQor LS13aXRoZHJhd25fcm91dGVzX2xlbmd0aDogMA0KKy0tdG90YWxfcGF0aF9hdHRyX2xlbmd0aDog MjMzDQogICArLS1PUklHSU46IElOQ09NUExFVEUgKDQgYnl0ZXMpDQogICB8ICArLS1GbGFnczog MHg0MCAoV2VsbC1Lbm93biwgVHJhbnNpdGl2ZSwgQ29tcGxldGUpDQogICB8ICArLS1UeXBlIENv ZGU6IE9SSUdJTiAoMSkNCiAgIHwgICstLUxlbmd0aDogMSBieXRlDQogICB8ICArLS1PcmlnaW46 IElOQ09NUExFVEUgKDEpDQogICArLS1NVUxUSV9FWElUX0RJU0MgKDcgYnl0ZXMpDQogICB8ICAr LS1GbGFnczogMHg4MCAoT3B0aW9uYWwsIENvbXBsZXRlKQ0KICAgfCAgKy0tVHlwZSBDb2RlOiBN VUxUSV9FWElUX0RJU0MgKDQpDQogICB8ICArLS1MZW5ndGg6IDQgYnl0ZXMNCiAgIHwgICstLWRh dGE6IDAwIDAwIDAwIDAwDQogICArLS1NUF9SRUFDSF9OTFJJICgxNiBieXRlcykNCiAgIHwgICst LUZsYWdzOiAweDgwIChPcHRpb25hbCwgQ29tcGxldGUpDQogICB8ICArLS1UeXBlIENvZGU6IE1Q X1JFQUNIX05MUkkgKDE0KQ0KICAgfCAgKy0tTGVuZ3RoOiAxMyBieXRlcw0KICAgfCAgKy0tZGF0 YTogMDAgMDEgMDEgMDQgQzYgMzMgNjQgNjQgICAwMCAxOCBDMCAwMCAwMg0KICAgKy0tQkdQU0VD IFBhdGggQXR0cmlidXRlICgyMDYgYnl0ZXMpDQogICAgICArLS1GbGFnczogMHg5MCAoT3B0aW9u YWwsIENvbXBsZXRlLCBFeHRlbmRlZCBMZW5ndGgpDQogICAgICArLS1UeXBlIENvZGU6IEJHUFNF QyBQYXRoIEF0dHJpYnV0ZSAoMzApDQogICAgICArLS1MZW5ndGg6IDIwMiBieXRlcw0KICAgICAg Ky0tU2VjdXJlIFBhdGggKDE0IGJ5dGVzKQ0KICAgICAgfCAgKy0tTGVuZ3RoOiAxNCBieXRlcw0K ICAgICAgfCAgKy0tU2VjdXJlIFBhdGggU2VnbWVudDogKDYgYnl0ZXMpDQogICAgICB8ICB8ICAr LS1wQ291bnQ6IDENCiAgICAgIHwgIHwgICstLUZsYWdzOiAwDQogICAgICB8ICB8ICArLS1BUyBu dW1iZXI6IDY1NTM2ICgxLjApDQogICAgICB8ICArLS1TZWN1cmUgUGF0aCBTZWdtZW50OiAoNiBi eXRlcykNCiAgICAgIHwgICAgICstLXBDb3VudDogMQ0KICAgICAgfCAgICAgKy0tRmxhZ3M6IDAN CiAgICAgIHwgICAgICstLUFTIG51bWJlcjogNjQ0OTYgKDAuNjQ0OTYpDQogICAgICArLS1TaWdu YXR1cmUgQmxvY2sgKDE4OCBieXRlcykNCiAgICAgICAgICstLUxlbmd0aDogMTg4IGJ5dGVzDQog ICAgICAgICArLS1BbGdvIElEOiAxDQogICAgICAgICArLS1TaWduYXR1cmUgU2VnbWVudDogKDky IGJ5dGVzKQ0KICAgICAgICAgfCAgKy0tU0tJOiA0N0YyM0JGMUFCMkY4QTlEMjY4NjRFQkJEOERG MjcxMUM3NDQwNkVDDQogICAgICAgICB8ICArLS1MZW5ndGg6IDcwIGJ5dGVzDQogICAgICAgICB8 ICArLS1TaWduYXR1cmU6IDMwIDQ0IDAyIDIwIDcyIDE0IEJDIDk2ICA0NyAxNiAwQiBCRCAzOSBG RiAyRiA4MA0KICAgICAgICAgfCAgICAgICAgICAgICAgICA1MyAzRiA1RCBDNiBERCBENyAwRCBE RiAgODYgQkIgODEgNTYgNjEgRTggMDUgRDUNCiAgICAgICAgIHwgICAgICAgICAgICAgICAgRDQg RTYgRjIgN0MgMDIgMjAgMkQgREMgIDAwIDNDIDY0IEJFIDdCIDI5IEM5IEVCDQogICAgICAgICB8 ICAgICAgICAgICAgICAgIERCIEM4IEE0IDk3IEVEIDY2IDI4IDVFICBFOSAyMiA3NiA4MyBFNiBD MSA3OCBDRQ0KICAgICAgICAgfCAgICAgICAgICAgICAgICA4RCBFNiBEMyA1OSA1RiA0MQ0KICAg ICAgICAgKy0tU2lnbmF0dXJlIFNlZ21lbnQ6ICg5MyBieXRlcykNCiAgICAgICAgICAgICstLVNL STogQUI0RDkxMEY1NUNBRTcxQTIxNUVGM0NBRkUzQUNDNDVCNUVFQzE1NA0KICAgICAgICAgICAg Ky0tTGVuZ3RoOiA3MSBieXRlcw0KICAgICAgICAgICAgKy0tU2lnbmF0dXJlOiAzMCA0NSAwMiAy MCA3MiAxNCBCQyA5NiAgNDcgMTYgMEIgQkQgMzkgRkYgMkYgODANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgNTMgM0YgNUQgQzYgREQgRDcgMEQgREYgIDg2IEJCIDgxIDU2IDYxIEU4IDA1IEQ1 DQogICAgICAgICAgICAgICAgICAgICAgICAgIEQ0IEU2IEYyIDdDIDAyIDIxIDAwIEM2ICAxNyAx OSAzNCAwNyA0MyAwNiAzQiA4QQ0KICAgICAgICAgICAgICAgICAgICAgICAgICA1QyBDRCA1NCAx NiAzOSAwQiAzMSAyMSAgMUQgM0MgNTIgNDggMDcgOTUgODcgRDANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgMTMgMTMgN0IgNDEgQ0QgMjMgRTINCg0KLS0tLXNuaXAtLS0tc25pcC0tLS1zbmlw LS0tLXNuaXAtLS0tDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KT2xpdmVyIEJvcmNoZXJ0LCBDb21wdXRlciBTY2llbnRp c3QNCk5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3kNCihQaG9u ZSkgMzAxLjk3NS40ODU2ICwgKEZheCkgMzAxLjk3NS42MjM4DQo= --_000_2459DA8D593F4B759C74619DDBA907E4nistgov_ Content-Type: text/html; charset="utf-8" Content-ID: <93DD941E217BB84080AB0CE634CCC807@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGlzIGVt YWlsIGNvbnRhaW5zIHNvbWUgdGVzdCB2ZWN0b3JzIGZvciBkcmFmdC1pZXRmLXNpZHItYmdwc2Vj LXBraS1hbGdzIHRoYXQgd2VyZSBnZW5lcmF0ZWQgYXMgYSByZXN1bHQgb2YgSUVTRy9hdXRob3Ig ZGlzY3Vzc2lvbnM7IFN0ZXBoZW4gc3VnZ2VzdGVkIHRoYXQgdGhlIGRyYWZ0IGNvdWxkIHVzZSBz b21lIGV4YW1wbGVzIGFuZCBoZeKAmXMgcmlnaHQNCiBzbyB3ZeKAmWQgbGlrZSB0byBpbmNsdWRl IHRoaXMgYXMgYW4gSVB2NCBleGFtcGxlLiZuYnNwOyZuYnNwO0luIGNhc2UgdGhlIGV4YW1wbGUg aXMgdmljdGltIHRvIHNvbWUgY3JhenkgbGluZSB3cmFwcGluZyBvciBmb3IgbmljZSBmb3JtYXR0 ZWQgcmVhZGluZywgSSBhbHNvIGF0dGFjaGVkIHRoZSBleGFtcGxlIGFzIHRleHQgZmlsZSB0byB0 aGlzIGVtYWlsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhh bmtzLCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5PbGl2ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0tLS1zbmlwLS0tLXNuaXAtLS0tc25pcC0tLS1zbmlwLS0t LTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VG9wb2xvZ3k6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BUyg2NDQ5NiktLS0tQVMo NjU1MzYpLS0tLUFTKDY1NTM3KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+UHJlZml4IEFubm91bmNlbWVudDogQVMoNjQ0OTYpLCAxOTIuMC4yLjAvMjQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZvciB0aGlzIGV4YW1wbGUgdGhl IEVDRFNBIGFsZ29yaXRobSB3YXMgcHJvdmlkZWQgd2l0aCBhIHN0YXRpYyBrIHRvPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPm1ha2UgdGhlIHJlc3VsdCBkZXRlcm1pbmlzdGljLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5UaGUgayB1c2VkIGZvciBhbGwgc2lnbmF0dXJlIG9wZXJhdGlvbnMgd2FzIHRha2VuIGZyb20g UkZDIDY5NzksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPmNoYXB0ZXIgQS4yLjUg4oCcU2lnbmF0dXJlcyBX aXRoIFNIQS0yNTYsIG1lc3NhZ2UgJ3NhbXBsZSfigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsgayA9IEE2RTNDNTdERDAxQUJFOTAwODY1MzgzOTgz NTVERDRDM0IxN0FBODczMzgyQjBGMjRENjEyOTQ5M0Q4QUFENjA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPktleXMgb2YgQVM2NDQ5Njo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5za2k6IEFCNEQ5MTBGNTVDQUU3 MUEyMTVFRjNDQUZFM0FDQzQ1QjVFRUMxNTQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPnByaXZhdGUga2V5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsgeCA9IEQ4 QUE0REZCRTI0NzhGODZFODhBNzQ1MUJGMDc1NTY1NzA5QzU3NUFDMUMxMzZEMDgxQzU0MDI1NENB NDQwQjk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPnB1YmxpYyBr ZXk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwO1V4ID0gNzM5MUJBQkI5MkEwQ0IzQkUx MEU1OUIxOUVCRkZCMjE0RTA0QTkxRTBDQkExQjEzOUE3RDM4RDkwRjc3RTU1QTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDsgVXkgPSBBMDVCOEU2OTU2NzhFMEZBMTY5MDRCNTVEOUQ0RjVDMERGQzU4 ODk1RUU1MEJDNEY3NUQyMDVBMjVCRDM2RkY1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5Sb3V0ZXIgS2V5IENlcnRpZmljYXRlIGV4YW1wbGUgdXNpbmcgT3BlblNT TCAxLjAuMWUtZmlwcyAxMSBGZWIgMjAxMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5DZXJ0aWZpY2F0ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IERhdGE6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBWZXJzaW9uOiAzICgweDIpPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZXJpYWwgTnVtYmVyOiAz MTQ4MjM0NTExICgweGJiYTYzZjBmKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz cDsgU2lnbmF0dXJlIEFsZ29yaXRobTogZWNkc2Etd2l0aC1TSEEyNTY8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElzc3VlcjogQ049 Uk9VVEVSLTAwMDBGQkYwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBWYWxpZGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Tm90IEJlZm9yZTogSmFuIDEwIDE5OjU1OjQ0IDIwMTcgR01UPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBOb3QgQWZ0ZXIgOiBPY3QgMjUgMTk6NTU6NDQgMjI5MCBHTVQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFN1YmplY3Q6 IENOPVJPVVRFUi0wMDAwRkJGMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU3ViamVjdCBQdWJsaWMgS2V5IEluZm86PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBQdWJsaWMgS2V5IEFsZ29yaXRobTogaWQtZWNQdWJsaWNLZXk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFB1Ymxp Yy1LZXk6ICgyNTYgYml0KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgcHViOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDswNDo3Mzo5MTpiYTpiYjo5 MjphMDpjYjozYjplMTowZTo1OTpiMTo5ZTpiZjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZiOjIxOjRl OjA0OmE5OjFlOjBjOmJhOjFiOjEzOjlhOjdkOjM4OmQ5OjBmOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Nzc6ZTU6NWE6YTA6NWI6OGU6Njk6NTY6Nzg6ZTA6ZmE6MTY6OTA6NGI6NTU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBkOTpkNDpmNTpjMDpkZjpjNTo4ODo5NTplZTo1MDpiYzo0Zjo3NTpkMjowNTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGEyOjViOmQzOjZmOmY1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBU04xIE9JRDogcHJpbWUyNTZ2MTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWDUwOXYz IGV4dGVuc2lvbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBYNTA5djMgS2V5IFVzYWdl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtEaWdpdGFsIFNpZ25hdHVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWDUwOXYzIFN1 YmplY3QgS2V5IElkZW50aWZpZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO0FCOjREOjkxOjBGOjU1OkNBOkU3OjFBOjIxOjVFOkYzOkNB OkZFOjNBOkNDOjQ1OkI1OkVFOkMxOjU0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBYNTA5 djMgRXh0ZW5kZWQgS2V5IFVzYWdlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsxLjMuNi4xLjUuNS43LjMuMzA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHNiZ3AtYXV0b25vbW91c1N5c051bTogY3JpdGljYWw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF1dG9ub21vdXMgU3lzdGVt IE51bWJlcnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA2NDQ5NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgUm91dGluZyBEb21haW4gSWRlbnRpZmllcnM6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmhl cml0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsgU2lnbmF0dXJlIEFsZ29yaXRobTogZWNkc2Etd2l0aC1TSEEyNTY8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDMwOjQ2OjAyOjIxOjAwOmNiOjQ4OjE5OjdhOjY3OmZkOjk4OmE1OjBjOmUzOmFiOjBlOjU5Ojxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgZmQ6ZmI6MWQ6NmY6NmE6NGM6ZmM6Zjc6ZTc6ZDc6Nzc6M2E6MmM6MzM6ODI6MDI6 NTc6Y2M6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA3MDowMjoyMTowMDplYTpmMToyYzowODowNTpiOTpkZjo0ODo4Zjo5 NDo4ZDplMDpjZjoyMzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGU4OjhlOjcxOjU2OjEzOjRlOjQ0OmIyOjM1OjYyOjli OmNkOmExOjljOjlkOjA0OjBmOmRjPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0tLS0tQkVHSU4gQ0VSVElG SUNBVEUtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NSUlCalRDQ0FUS2dBd0lCQWdJRkFMdW1Qdzh3 Q2dZSUtvWkl6ajBFQXdJd0dqRVlNQllHQTFVRUF3d1BVazlWPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlZF VlNMVEF3TURCR1FrWXdNQ0FYRFRFM01ERXhNREU1TlRVME5Gb1lEekl5T1RBeE1ESTFNVGsxTlRR MFdqQWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+TVJnd0ZnWURWUVFEREE5U1QxVlVSVkl0TURBd01FWkNS akF3V1RBVEJnY3Foa2pPUFFJQkJnZ3Foa2pPUFFNQjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Cd05DQUFS emticTdrcURMTyYjNDM7RU9XYkdldi9zaFRnU3BIZ3k2R3hPYWZUalpEM2ZsV3FCYmptbFdlT0Q2 RnBCTDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5WZG5VOWNEZnhZaVY3bEM4VDNYU0JhSmIwMi8xbzJNd1lU QUxCZ05WSFE4RUJBTUNCNEF3SFFZRFZSME9CQllFPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZLdE5rUTlW eXVjYUlWN3p5djQ2ekVXMTdzRlVNQk1HQTFVZEpRUU1NQW9HQ0NzR0FRVUZCd01lTUI0R0NDc0c8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+QVFVRkJ3RUlBUUgvQkE4d0RhQUhNQVVDQXdENzhLRUNCUUF3Q2dZ SUtvWkl6ajBFQXdJRFNRQXdSZ0loQU10STxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5HWHBuL1ppbERPT3JE bG45JiM0Mzt4MXZha3o4OSYjNDM7Zlhkem9zTTRJQ1Y4eHdBaUVBNnZFc0NBVzUzMGlQbEkzZ3p5 UG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+am5GV0UwNUVzalZpbTgyaG5KMEVEOXc9PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+S2V5cyBvZiBBUyg2NTYzNik6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPj09PT09PT09 PT09PT09PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5za2k6IDQ3RjIzQkYxQUIyRjhBOUQyNjg2NEVC QkQ4REYyNzExQzc0NDA2RUM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPnByaXZhdGUga2V5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsgeCA9IDZDQjJFOTMxQjEx MkYyNDU1NEJDRENBQUZEOTU1M0E5NTE5QTlBRjMzQzAyM0I2MDg0NkEyMUZDOTU1ODMxNzI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPnB1YmxpYyBrZXk6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwO1V4ID0gMjhGQzVGRTlBRkNGNUY0Q0FCM0Y1Rjg1Q0Iy MTJGQzFFOUQwRTBEQkVBRUU0MjVCRDJGMEQzMTc1QUEwRTk4OTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDsgVXkgPSBFQTlCNjAzRTM4RjM1RkIzMjlERjQ5NTY0MUYyQkEwNDBGMUMzQUM2MTM4MzA3 RjI1N0NCQTZCOEI1ODhGNDFGPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5Sb3V0ZXIgS2V5IENlcnRpZmljYXRlIGV4YW1wbGUgdXNpbmcgT3BlblNTTCAxLjAuMWUt ZmlwcyAxMSBGZWIgMjAxMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5DZXJ0aWZpY2F0ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IERhdGE6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBWZXJzaW9uOiAzICgweDIpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZXJpYWwgTnVtYmVyOiAxNTcyNzI2MjY4 ICgweDVkYmRlNWZjKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgU2lnbmF0 dXJlIEFsZ29yaXRobTogZWNkc2Etd2l0aC1TSEEyNTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElzc3VlcjogQ049Uk9VVEVSLTAw MDEwMDAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBWYWxpZGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTm90IEJlZm9y ZTogSmFuIDEwIDE5OjU1OjUwIDIwMTcgR01UPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBO b3QgQWZ0ZXIgOiBPY3QgMjUgMTk6NTU6NTAgMjI5MCBHTVQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFN1YmplY3Q6IENOPVJPVVRF Ui0wMDAxMDAwMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgU3ViamVjdCBQdWJsaWMgS2V5IEluZm86PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBQdWJsaWMgS2V5IEFsZ29yaXRobTogaWQtZWNQdWJsaWNLZXk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFB1YmxpYy1LZXk6ICgy NTYgYml0KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgcHViOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDswNDoyODpmYzo1ZjplOTphZjpjZjo1Zjo0 YzphYjozZjo1Zjo4NTpjYjoyMTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDJmOmMxOmU5OmQwOmUwOmRi OmVhOmVlOjQyOjViOmQyOmYwOmQzOjE3OjVhOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YTA6ZTk6ODk6 ZWE6OWI6NjA6M2U6Mzg6ZjM6NWY6YjM6Mjk6ZGY6NDk6NTY6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0 MTpmMjpiYTowNDowZjoxYzozYTpjNjoxMzo4MzowNzpmMjo1NzpjYjphNjo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGI4OmI1Ojg4OmY0OjFmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBBU04xIE9JRDogcHJpbWUyNTZ2MTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWDUwOXYzIGV4dGVuc2lv bnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBYNTA5djMgS2V5IFVzYWdlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtEaWdpdGFs IFNpZ25hdHVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWDUwOXYzIFN1YmplY3QgS2V5 IElkZW50aWZpZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzQ3OkYyOjNCOkYxOkFCOjJGOjhBOjlEOjI2Ojg2OjRFOkJCOkQ4OkRGOjI3 OjExOkM3OjQ0OjA2OkVDPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBYNTA5djMgRXh0ZW5k ZWQgS2V5IFVzYWdlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsxLjMuNi4xLjUuNS43LjMuMzA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHNiZ3AtYXV0b25vbW91c1N5c051bTogY3JpdGljYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF1dG9ub21vdXMgU3lzdGVtIE51bWJlcnM6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA2NTUzNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgUm91dGluZyBEb21haW4gSWRlbnRpZmllcnM6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmhlcml0PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsg U2lnbmF0dXJlIEFsZ29yaXRobTogZWNkc2Etd2l0aC1TSEEyNTY8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMwOjQ2OjAy OjIxOjAwOmIwOjM4OmJmOjRhOmFlOmM5OjFlOmUxOmNkOmIxOjE3Ojg0OjMzOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Zjg6MzI6ZDM6YzQ6YmE6NDQ6NmE6MWE6MTU6M2I6YzA6YjI6OGQ6NjE6OWU6NmU6N2Y6MWY6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAxNDowMjoyMTowMDpjMDo4YjpiODpiODo5ZjphNDpmNTpiOTo1NDo2ODo5ODowZTpi Zjo5Njo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGEwOmZjOjJiOjZlOmViOjQxOjJlOmVjOjFkOjgzOjIwOjhjOjcyOjJj OmFjOmRmOjEzOjU4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0tLS0tQkVHSU4gQ0VSVElGSUNBVEUtLS0t LTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5NSUlCakRDQ0FUR2dBd0lCQWdJRVhiM2wvREFLQmdncWhrak9Q UVFEQWpBYU1SZ3dGZ1lEVlFRRERBOVNUMVZVPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJWSXRNREF3TVRB d01EQXdJQmNOTVRjd01URXdNVGsxTlRVd1doZ1BNakk1TURFd01qVXhPVFUxTlRCYU1Cb3g8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+R0RBV0JnTlZCQU1NRDFKUFZWUkZVaTB3TURBeE1EQXdNREJaTUJNR0J5 cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BMElBQkNqOFgmIzQzO212 ejE5TXF6OWZoY3NoTDhIcDBPRGI2dTVDVzlMdzB4ZGFvT21KNnB0Z1BqanpYN01wMzBsVzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5RZks2QkE4Y09zWVRnd2Z5Vjh1bXVMV0k5QiYjNDM7all6QmhNQXNHQTFV ZER3UUVBd0lIZ0RBZEJnTlZIUTRFRmdRVTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SL0k3OGFzdmlwMG1o azY3Mk44bkVjZEVCdXd3RXdZRFZSMGxCQXd3Q2dZSUt3WUJCUVVIQXg0d0hnWUlLd1lCPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPkJRVUhBUWdCQWY4RUR6QU5vQWN3QlFJREFRQUFvUUlGQURBS0JnZ3Foa2pP UFFRREFnTkpBREJHQWlFQXNEaS88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U3E3Skh1SE5zUmVFTS9neTA4 UzZSR29hRlR2QXNvMWhubTUvSHhRQ0lRREFpN2k0bjZUMXVWUm9tQTYvbHFEODxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5LMjdyUVM3c0hZTWdqSElzck44VFdBPT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LS0tLS1F TkQgQ0VSVElGSUNBVEUtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5C R1BTZWMgVXBkYXRlIGZyb20gQVMoNjU1MzYpIHRvIEFTKDY1NTM3KTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5CaW5hcnkgRm9ybSBvZiBCR1BTZWMgVXBkYXRlIChUQ1AtRFVNUCk6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPkZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGJm5ic3A7IEZGIEZGIEZGIEZGIEZGIEZG IEZGIEZGPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjAxIDAwIDAyIDAwIDAwIDAwIEU5IDQwJm5ic3A7IDAx IDAxIDAyIDgwIDA0IDA0IDAwIDAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjAwIDAwIDgwIDBFIDBEIDAw IDAxIDAxJm5ic3A7IDA0IEM2IDMzIDY0IDY0IDAwIDE4IEMwPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjAw IDAyIDkwIDFFIDAwIENBIDAwIDBFJm5ic3A7IDAxIDAwIDAwIDAxIDAwIDAwIDAxIDAwPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjAwIDAwIEZCIEYwIDAwIEJDIDAxIDQ3Jm5ic3A7IEYyIDNCIEYxIEFCIDJG IDhBIDlEIDI2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjg2IDRFIEJCIEQ4IERGIDI3IDExIEM3Jm5ic3A7 IDQ0IDA2IEVDIDAwIDQ2IDMwIDQ0IDAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjIwIDcyIDE0IEJDIDk2 IDQ3IDE2IDBCJm5ic3A7IEJEIDM5IEZGIDJGIDgwIDUzIDNGIDVEPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PkM2IEREIEQ3IDBEIERGIDg2IEJCIDgxJm5ic3A7IDU2IDYxIEU4IDA1IEQ1IEQ0IEU2IEYyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjdDIDAyIDIwIDJEIERDIDAwIDNDIDY0Jm5ic3A7IEJFIDdCIDI5IEM5 IEVCIERCIEM4IEE0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjk3IEVEIDY2IDI4IDVFIEU5IDIyIDc2Jm5i c3A7IDgzIEU2IEMxIDc4IENFIDhEIEU2IEQzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjU5IDVGIDQxIEFC IDREIDkxIDBGIDU1Jm5ic3A7IENBIEU3IDFBIDIxIDVFIEYzIENBIEZFPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjNBIENDIDQ1IEI1IEVFIEMxIDU0IDAwJm5ic3A7IDQ3IDMwIDQ1IDAyIDIwIDcyIDE0IEJD PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjk2IDQ3IDE2IDBCIEJEIDM5IEZGIDJGJm5ic3A7IDgwIDUzIDNG IDVEIEM2IEREIEQ3IDBEPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRGIDg2IEJCIDgxIDU2IDYxIEU4IDA1 Jm5ic3A7IEQ1IEQ0IEU2IEYyIDdDIDAyIDIxIDAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkM2IDE3IDE5 IDM0IDA3IDQzIDA2IDNCJm5ic3A7IDhBIDVDIENEIDU0IDE2IDM5IDBCIDMxPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjIxIDFEIDNDIDUyIDQ4IDA3IDk1IDg3Jm5ic3A7IEQwIDEzIDEzIDdCIDQxIENEIDIz IEUyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+U2lnbmF0dXJlIEZyb20gQVMoNjQ0OTYpIHRvIEFTKDY1NTM2KTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkRpZ2VzdDombmJzcDsmbmJzcDsmbmJzcDsgMjEgMzMgRTUgQ0EgQTAg MjYgQkUgMDcmbmJzcDsmbmJzcDsgM0QgOUMgMUIgNEUgRkUgQjkgQjkgNzc8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7OUYgMjAgRjggRjUgREUgMjkgRkEgOTgmbmJzcDsmbmJzcDsgNDAgMDAg OUYgNjA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2lnbmF0dXJlOiAzMCA0NSAwMiAyMCA3MiAxNCBCQyA5 NiZuYnNwOyZuYnNwOyA0NyAxNiAwQiBCRCAzOSBGRiAyRiA4MDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs1MyAzRiA1RCBDNiBERCBENyAwRCBERiZuYnNwOyZuYnNwOyA4NiBCQiA4MSA1NiA2 MSBFOCAwNSBENTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtENCBFNiBGMiA3QyAwMiAyMSAw MCBDNiZuYnNwOyZuYnNwOyAxNyAxOSAzNCAwNyA0MyAwNiAzQiA4QTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs1QyBDRCA1NCAxNiAzOSAwQiAzMSAyMSZuYnNwOyZuYnNwOyAxRCAzQyA1MiA0 OCAwNyA5NSA4NyBEMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsxMyAxMyA3QiA0MSBDRCAy MyBFMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2lnbmF0dXJl IEZyb20gQVMoNjU1MzYpIHRvIEFTKDY1NTM3KTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RGlnZXN0OiZu YnNwOyZuYnNwOyZuYnNwOyA0NiA0QiA1NyBDRSBCMSAyRCAxOCBCMCZuYnNwOyZuYnNwOyBGRCAx QSAxQSAzNSA5NCAxNyAzQSA0QTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDswOSA4OCBFNSBG NCBFRCBFRCAyRiAzRCZuYnNwOyZuYnNwOyA4MyAwOCA1QSBBODxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5T aWduYXR1cmU6IDMwIDQ0IDAyIDIwIDcyIDE0IEJDIDk2Jm5ic3A7Jm5ic3A7IDQ3IDE2IDBCIEJE IDM5IEZGIDJGIDgwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzUzIDNGIDVEIEM2IEREIEQ3 IDBEIERGJm5ic3A7Jm5ic3A7IDg2IEJCIDgxIDU2IDYxIEU4IDA1IEQ1PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO0Q0IEU2IEYyIDdDIDAyIDIwIDJEIERDJm5ic3A7Jm5ic3A7IDAwIDNDIDY0 IEJFIDdCIDI5IEM5IEVCPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0RCIEM4IEE0IDk3IEVE IDY2IDI4IDVFJm5ic3A7Jm5ic3A7IEU5IDIyIDc2IDgzIEU2IEMxIDc4IENFPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzhEIEU2IEQzIDU5IDVGIDQxPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIGh1bWFuIHJl YWRhYmxlIG91dHB1dCBpcyBwcm9kdWNlZCB1c2luZyBiZ3BzZWMtaW8sIGEgYmdwc2VjPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPnRyYWZmaWMgZ2VuZXJhdG9yIHRoYXQgdXNlcyBhIHdpcmVzaGFyayBsaWtl IHByaW50b3V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2Vu ZCBVcGRhdGUgTWVzc2FnZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mIzQzOy0tbWFya2VyOiBGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mIzQzOy0tbGVuZ3Ro OiAyNTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+JiM0MzstLXR5cGU6Jm5ic3A7Jm5ic3A7IDIgKFVQREFU RSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+JiM0MzstLXdpdGhkcmF3bl9yb3V0ZXNfbGVuZ3RoOiAwPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiYjNDM7LS10b3RhbF9wYXRoX2F0dHJfbGVuZ3RoOiAyMzM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7ICYjNDM7LS1PUklHSU46IElOQ09NUExFVEUgKDQgYnl0 ZXMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1GbGFnczog MHg0MCAoV2VsbC1Lbm93biwgVHJhbnNpdGl2ZSwgQ29tcGxldGUpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1UeXBlIENvZGU6IE9SSUdJTiAoMSk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLUxlbmd0aDogMSBieXRlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1PcmlnaW46IElOQ09N UExFVEUgKDEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyAmIzQzOy0tTVVMVElfRVhJ VF9ESVNDICg3IGJ5dGVzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgfCZuYnNwOyAm IzQzOy0tRmxhZ3M6IDB4ODAgKE9wdGlvbmFsLCBDb21wbGV0ZSk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLVR5cGUgQ29kZTogTVVMVElfRVhJVF9ESVNDICg0 KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tTGVuZ3RoOiA0 IGJ5dGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1kYXRh OiAwMCAwMCAwMCAwMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmIzQzOy0t TVBfUkVBQ0hfTkxSSSAoMTYgYnl0ZXMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyB8 Jm5ic3A7ICYjNDM7LS1GbGFnczogMHg4MCAoT3B0aW9uYWwsIENvbXBsZXRlKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tVHlwZSBDb2RlOiBNUF9SRUFDSF9O TFJJICgxNCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLUxl bmd0aDogMTMgYnl0ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0 MzstLWRhdGE6IDAwIDAxIDAxIDA0IEM2IDMzIDY0IDY0Jm5ic3A7Jm5ic3A7IDAwIDE4IEMwIDAw IDAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LS1CR1BTRUMgUGF0 aCBBdHRyaWJ1dGUgKDIwNiBieXRlcyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1GbGFnczogMHg5MCAoT3B0aW9uYWwsIENvbXBsZXRlLCBF eHRlbmRlZCBMZW5ndGgpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmIzQzOy0tVHlwZSBDb2RlOiBCR1BTRUMgUGF0aCBBdHRyaWJ1dGUgKDMwKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLUxlbmd0 aDogMjAyIGJ5dGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmIzQzOy0tU2VjdXJlIFBhdGggKDE0IGJ5dGVzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tTGVuZ3RoOiAxNCBieXRl czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyAmIzQzOy0tU2VjdXJlIFBhdGggU2VnbWVudDogKDYgYnl0ZXMpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXBD b3VudDogMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1GbGFnczogMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1BUyBudW1iZXI6 IDY1NTM2ICgxLjApPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7ICYjNDM7LS1TZWN1cmUgUGF0aCBTZWdtZW50OiAoNiBieXRlcyk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJiM0MzstLXBDb3VudDogMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tRmxh Z3M6IDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLUFTIG51bWJlcjogNjQ0OTYgKDAuNjQ0OTYp PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0t U2lnbmF0dXJlIEJsb2NrICgxODggYnl0ZXMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tTGVuZ3RoOiAxODgg Ynl0ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1BbGdvIElEOiAxPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tU2lnbmF0 dXJlIFNlZ21lbnQ6ICg5MiBieXRlcyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLVNLSTogNDdG MjNCRjFBQjJGOEE5RDI2ODY0RUJCRDhERjI3MTFDNzQ0MDZFQzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAm IzQzOy0tTGVuZ3RoOiA3MCBieXRlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tU2lnbmF0dXJl OiAzMCA0NCAwMiAyMCA3MiAxNCBCQyA5NiZuYnNwOyA0NyAxNiAwQiBCRCAzOSBGRiAyRiA4MDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzUzIDNGIDVE IEM2IEREIEQ3IDBEIERGJm5ic3A7IDg2IEJCIDgxIDU2IDYxIEU4IDA1IEQ1PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRDQgRTYgRjIgN0MgMDIgMjAg MkQgREMmbmJzcDsgMDAgM0MgNjQgQkUgN0IgMjkgQzkgRUI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEQiBDOCBBNCA5NyBFRCA2NiAyOCA1RSZuYnNw OyBFOSAyMiA3NiA4MyBFNiBDMSA3OCBDRTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDhEIEU2IEQzIDU5IDVGIDQxPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7 LS1TaWduYXR1cmUgU2VnbWVudDogKDkzIGJ5dGVzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJiM0MzstLVNLSTogQUI0RDkxMEY1NUNBRTcxQTIxNUVGM0NBRkUzQUNDNDVCNUVFQzE1NDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLUxlbmd0aDogNzEgYnl0ZXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1TaWduYXR1cmU6IDMwIDQ1IDAyIDIwIDcyIDE0 IEJDIDk2Jm5ic3A7IDQ3IDE2IDBCIEJEIDM5IEZGIDJGIDgwPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzUzIDNGIDVEIEM2IEREIEQ3 IDBEIERGJm5ic3A7IDg2IEJCIDgxIDU2IDYxIEU4IDA1IEQ1PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0Q0IEU2IEYyIDdDIDAyIDIx IDAwIEM2Jm5ic3A7IDE3IDE5IDM0IDA3IDQzIDA2IDNCIDhBPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzVDIENEIDU0IDE2IDM5IDBC IDMxIDIxJm5ic3A7IDFEIDNDIDUyIDQ4IDA3IDk1IDg3IEQwPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzEzIDEzIDdCIDQxIENEIDIz IEUyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tLS0tc25pcC0t LS1zbmlwLS0tLXNuaXAtLS0tc25pcC0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6 YmxhY2siPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ T2xpdmVyIEJvcmNoZXJ0LCBDb21wdXRlciBTY2llbnRpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtjb2xvcjpibGFjayI+TmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBh bmQgVGVjaG5vbG9neTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj ayI+KFBob25lKSAzMDEuOTc1LjQ4NTYgLCAoRmF4KSAzMDEuOTc1LjYyMzg8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2459DA8D593F4B759C74619DDBA907E4nistgov_-- --_004_2459DA8D593F4B759C74619DDBA907E4nistgov_ Content-Type: text/plain; name="draft-ietf-sidr-bgpsec-algs-examples.txt" Content-Description: draft-ietf-sidr-bgpsec-algs-examples.txt Content-Disposition: attachment; filename="draft-ietf-sidr-bgpsec-algs-examples.txt"; size=9910; creation-date="Wed, 11 Jan 2017 16:31:05 GMT"; modification-date="Wed, 11 Jan 2017 16:31:05 GMT" Content-ID: <8F8BD7CC99699C409182FB0606692340@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 77u/VG9wb2xvZ3k6CgpBUyg2NDQ5NiktLS0tQVMoNjU1MzYpLS0tLUFTKDY1NTM3KQoKUHJlZml4 IEFubm91bmNlbWVudDogQVMoNjQ0OTYpLCAxOTIuMC4yLjAvMjQKCkZvciB0aGlzIGV4YW1wbGUg dGhlIEVDRFNBIGFsZ29yaXRobSB3YXMgcHJvdmlkZWQgd2l0aCBhIHN0YXRpYyBrIHRvIAptYWtl IHRoZSByZXN1bHQgZGV0ZXJtaW5pc3RpYy4gClRoZSBrIHVzZWQgZm9yIGFsbCBzaWduYXR1cmUg b3BlcmF0aW9ucyB3YXMgdGFrZW4gZnJvbSBSRkMgNjk3OSwgCmNoYXB0ZXIgQS4yLjUg4oCcU2ln bmF0dXJlcyBXaXRoIFNIQS0yNTYsIG1lc3NhZ2UgJ3NhbXBsZSfigJ0uCgogIGsgPSBBNkUzQzU3 REQwMUFCRTkwMDg2NTM4Mzk4MzU1REQ0QzNCMTdBQTg3MzM4MkIwRjI0RDYxMjk0OTNEOEFBRDYw CgpLZXlzIG9mIEFTNjQ0OTY6Cj09PT09PT09PT09PT09PT0Kc2tpOiBBQjREOTEwRjU1Q0FFNzFB MjE1RUYzQ0FGRTNBQ0M0NUI1RUVDMTU0Cgpwcml2YXRlIGtleToKICB4ID0gRDhBQTRERkJFMjQ3 OEY4NkU4OEE3NDUxQkYwNzU1NjU3MDlDNTc1QUMxQzEzNkQwODFDNTQwMjU0Q0E0NDBCOQoKcHVi bGljIGtleTogCiAgVXggPSA3MzkxQkFCQjkyQTBDQjNCRTEwRTU5QjE5RUJGRkIyMTRFMDRBOTFF MENCQTFCMTM5QTdEMzhEOTBGNzdFNTVBCiAgVXkgPSBBMDVCOEU2OTU2NzhFMEZBMTY5MDRCNTVE OUQ0RjVDMERGQzU4ODk1RUU1MEJDNEY3NUQyMDVBMjVCRDM2RkY1CgpSb3V0ZXIgS2V5IENlcnRp ZmljYXRlIGV4YW1wbGUgdXNpbmcgT3BlblNTTCAxLjAuMWUtZmlwcyAxMSBGZWIgMjAxMwotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQpDZXJ0aWZpY2F0ZToKICAgIERhdGE6CiAgICAgICAgVmVyc2lvbjogMyAoMHgyKQog ICAgICAgIFNlcmlhbCBOdW1iZXI6IDMxNDgyMzQ1MTEgKDB4YmJhNjNmMGYpCiAgICBTaWduYXR1 cmUgQWxnb3JpdGhtOiBlY2RzYS13aXRoLVNIQTI1NgogICAgICAgIElzc3VlcjogQ049Uk9VVEVS LTAwMDBGQkYwCiAgICAgICAgVmFsaWRpdHkKICAgICAgICAgICAgTm90IEJlZm9yZTogSmFuIDEw IDE5OjU1OjQ0IDIwMTcgR01UCiAgICAgICAgICAgIE5vdCBBZnRlciA6IE9jdCAyNSAxOTo1NTo0 NCAyMjkwIEdNVAogICAgICAgIFN1YmplY3Q6IENOPVJPVVRFUi0wMDAwRkJGMAogICAgICAgIFN1 YmplY3QgUHVibGljIEtleSBJbmZvOgogICAgICAgICAgICBQdWJsaWMgS2V5IEFsZ29yaXRobTog aWQtZWNQdWJsaWNLZXkKICAgICAgICAgICAgICAgIFB1YmxpYy1LZXk6ICgyNTYgYml0KQogICAg ICAgICAgICAgICAgcHViOiAKICAgICAgICAgICAgICAgICAgICAwNDo3Mzo5MTpiYTpiYjo5Mjph MDpjYjozYjplMTowZTo1OTpiMTo5ZTpiZjoKICAgICAgICAgICAgICAgICAgICBmYjoyMTo0ZTow NDphOToxZTowYzpiYToxYjoxMzo5YTo3ZDozODpkOTowZjoKICAgICAgICAgICAgICAgICAgICA3 NzplNTo1YTphMDo1Yjo4ZTo2OTo1Njo3ODplMDpmYToxNjo5MDo0Yjo1NToKICAgICAgICAgICAg ICAgICAgICBkOTpkNDpmNTpjMDpkZjpjNTo4ODo5NTplZTo1MDpiYzo0Zjo3NTpkMjowNToKICAg ICAgICAgICAgICAgICAgICBhMjo1YjpkMzo2ZjpmNQogICAgICAgICAgICAgICAgQVNOMSBPSUQ6 IHByaW1lMjU2djEKICAgICAgICBYNTA5djMgZXh0ZW5zaW9uczoKICAgICAgICAgICAgWDUwOXYz IEtleSBVc2FnZTogCiAgICAgICAgICAgICAgICBEaWdpdGFsIFNpZ25hdHVyZQogICAgICAgICAg ICBYNTA5djMgU3ViamVjdCBLZXkgSWRlbnRpZmllcjogCiAgICAgICAgICAgICAgICBBQjo0RDo5 MTowRjo1NTpDQTpFNzoxQToyMTo1RTpGMzpDQTpGRTozQTpDQzo0NTpCNTpFRTpDMTo1NAogICAg ICAgICAgICBYNTA5djMgRXh0ZW5kZWQgS2V5IFVzYWdlOiAKICAgICAgICAgICAgICAgIDEuMy42 LjEuNS41LjcuMy4zMAogICAgICAgICAgICBzYmdwLWF1dG9ub21vdXNTeXNOdW06IGNyaXRpY2Fs CiAgICAgICAgICAgICAgICBBdXRvbm9tb3VzIFN5c3RlbSBOdW1iZXJzOgogICAgICAgICAgICAg ICAgICA2NDQ5NgogICAgICAgICAgICAgICAgUm91dGluZyBEb21haW4gSWRlbnRpZmllcnM6CiAg ICAgICAgICAgICAgICAgIGluaGVyaXQKCiAgICBTaWduYXR1cmUgQWxnb3JpdGhtOiBlY2RzYS13 aXRoLVNIQTI1NgogICAgICAgICAzMDo0NjowMjoyMTowMDpjYjo0ODoxOTo3YTo2NzpmZDo5ODph NTowYzplMzphYjowZTo1OToKICAgICAgICAgZmQ6ZmI6MWQ6NmY6NmE6NGM6ZmM6Zjc6ZTc6ZDc6 Nzc6M2E6MmM6MzM6ODI6MDI6NTc6Y2M6CiAgICAgICAgIDcwOjAyOjIxOjAwOmVhOmYxOjJjOjA4 OjA1OmI5OmRmOjQ4OjhmOjk0OjhkOmUwOmNmOjIzOgogICAgICAgICBlODo4ZTo3MTo1NjoxMzo0 ZTo0NDpiMjozNTo2Mjo5YjpjZDphMTo5Yzo5ZDowNDowZjpkYwotLS0tLUJFR0lOIENFUlRJRklD QVRFLS0tLS0KTUlJQmpUQ0NBVEtnQXdJQkFnSUZBTHVtUHc4d0NnWUlLb1pJemowRUF3SXdHakVZ TUJZR0ExVUVBd3dQVWs5VgpWRVZTTFRBd01EQkdRa1l3TUNBWERURTNNREV4TURFNU5UVTBORm9Z RHpJeU9UQXhNREkxTVRrMU5UUTBXakFhCk1SZ3dGZ1lEVlFRRERBOVNUMVZVUlZJdE1EQXdNRVpD UmpBd1dUQVRCZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUIKQndOQ0FBUnprYnE3a3FETE8rRU9XYkdl di9zaFRnU3BIZ3k2R3hPYWZUalpEM2ZsV3FCYmptbFdlT0Q2RnBCTApWZG5VOWNEZnhZaVY3bEM4 VDNYU0JhSmIwMi8xbzJNd1lUQUxCZ05WSFE4RUJBTUNCNEF3SFFZRFZSME9CQllFCkZLdE5rUTlW eXVjYUlWN3p5djQ2ekVXMTdzRlVNQk1HQTFVZEpRUU1NQW9HQ0NzR0FRVUZCd01lTUI0R0NDc0cK QVFVRkJ3RUlBUUgvQkE4d0RhQUhNQVVDQXdENzhLRUNCUUF3Q2dZSUtvWkl6ajBFQXdJRFNRQXdS Z0loQU10SQpHWHBuL1ppbERPT3JEbG45K3gxdmFrejg5K2ZYZHpvc000SUNWOHh3QWlFQTZ2RXND QVc1MzBpUGxJM2d6eVBvCmpuRldFMDVFc2pWaW04MmhuSjBFRDl3PQotLS0tLUVORCBDRVJUSUZJ Q0FURS0tLS0tCgoKCktleXMgb2YgQVMoNjU2MzYpOgo9PT09PT09PT09PT09PT09PT0Kc2tpOiA0 N0YyM0JGMUFCMkY4QTlEMjY4NjRFQkJEOERGMjcxMUM3NDQwNkVDCgpwcml2YXRlIGtleToKICB4 ID0gNkNCMkU5MzFCMTEyRjI0NTU0QkNEQ0FBRkQ5NTUzQTk1MTlBOUFGMzNDMDIzQjYwODQ2QTIx RkM5NTU4MzE3MgoKcHVibGljIGtleTogCiAgVXggPSAyOEZDNUZFOUFGQ0Y1RjRDQUIzRjVGODVD QjIxMkZDMUU5RDBFMERCRUFFRTQyNUJEMkYwRDMxNzVBQTBFOTg5CiAgVXkgPSBFQTlCNjAzRTM4 RjM1RkIzMjlERjQ5NTY0MUYyQkEwNDBGMUMzQUM2MTM4MzA3RjI1N0NCQTZCOEI1ODhGNDFGCgpS b3V0ZXIgS2V5IENlcnRpZmljYXRlIGV4YW1wbGUgdXNpbmcgT3BlblNTTCAxLjAuMWUtZmlwcyAx MSBGZWIgMjAxMwotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpDZXJ0aWZpY2F0ZToKICAgIERhdGE6CiAgICAgICAgVmVy c2lvbjogMyAoMHgyKQogICAgICAgIFNlcmlhbCBOdW1iZXI6IDE1NzI3MjYyNjggKDB4NWRiZGU1 ZmMpCiAgICBTaWduYXR1cmUgQWxnb3JpdGhtOiBlY2RzYS13aXRoLVNIQTI1NgogICAgICAgIElz c3VlcjogQ049Uk9VVEVSLTAwMDEwMDAwCiAgICAgICAgVmFsaWRpdHkKICAgICAgICAgICAgTm90 IEJlZm9yZTogSmFuIDEwIDE5OjU1OjUwIDIwMTcgR01UCiAgICAgICAgICAgIE5vdCBBZnRlciA6 IE9jdCAyNSAxOTo1NTo1MCAyMjkwIEdNVAogICAgICAgIFN1YmplY3Q6IENOPVJPVVRFUi0wMDAx MDAwMAogICAgICAgIFN1YmplY3QgUHVibGljIEtleSBJbmZvOgogICAgICAgICAgICBQdWJsaWMg S2V5IEFsZ29yaXRobTogaWQtZWNQdWJsaWNLZXkKICAgICAgICAgICAgICAgIFB1YmxpYy1LZXk6 ICgyNTYgYml0KQogICAgICAgICAgICAgICAgcHViOiAKICAgICAgICAgICAgICAgICAgICAwNDoy ODpmYzo1ZjplOTphZjpjZjo1Zjo0YzphYjozZjo1Zjo4NTpjYjoyMToKICAgICAgICAgICAgICAg ICAgICAyZjpjMTplOTpkMDplMDpkYjplYTplZTo0Mjo1YjpkMjpmMDpkMzoxNzo1YToKICAgICAg ICAgICAgICAgICAgICBhMDplOTo4OTplYTo5Yjo2MDozZTozODpmMzo1ZjpiMzoyOTpkZjo0OTo1 NjoKICAgICAgICAgICAgICAgICAgICA0MTpmMjpiYTowNDowZjoxYzozYTpjNjoxMzo4MzowNzpm Mjo1NzpjYjphNjoKICAgICAgICAgICAgICAgICAgICBiODpiNTo4ODpmNDoxZgogICAgICAgICAg ICAgICAgQVNOMSBPSUQ6IHByaW1lMjU2djEKICAgICAgICBYNTA5djMgZXh0ZW5zaW9uczoKICAg ICAgICAgICAgWDUwOXYzIEtleSBVc2FnZTogCiAgICAgICAgICAgICAgICBEaWdpdGFsIFNpZ25h dHVyZQogICAgICAgICAgICBYNTA5djMgU3ViamVjdCBLZXkgSWRlbnRpZmllcjogCiAgICAgICAg ICAgICAgICA0NzpGMjozQjpGMTpBQjoyRjo4QTo5RDoyNjo4Njo0RTpCQjpEODpERjoyNzoxMTpD Nzo0NDowNjpFQwogICAgICAgICAgICBYNTA5djMgRXh0ZW5kZWQgS2V5IFVzYWdlOiAKICAgICAg ICAgICAgICAgIDEuMy42LjEuNS41LjcuMy4zMAogICAgICAgICAgICBzYmdwLWF1dG9ub21vdXNT eXNOdW06IGNyaXRpY2FsCiAgICAgICAgICAgICAgICBBdXRvbm9tb3VzIFN5c3RlbSBOdW1iZXJz OgogICAgICAgICAgICAgICAgICA2NTUzNgogICAgICAgICAgICAgICAgUm91dGluZyBEb21haW4g SWRlbnRpZmllcnM6CiAgICAgICAgICAgICAgICAgIGluaGVyaXQKCiAgICBTaWduYXR1cmUgQWxn b3JpdGhtOiBlY2RzYS13aXRoLVNIQTI1NgogICAgICAgICAzMDo0NjowMjoyMTowMDpiMDozODpi Zjo0YTphZTpjOToxZTplMTpjZDpiMToxNzo4NDozMzoKICAgICAgICAgZjg6MzI6ZDM6YzQ6YmE6 NDQ6NmE6MWE6MTU6M2I6YzA6YjI6OGQ6NjE6OWU6NmU6N2Y6MWY6CiAgICAgICAgIDE0OjAyOjIx OjAwOmMwOjhiOmI4OmI4OjlmOmE0OmY1OmI5OjU0OjY4Ojk4OjBlOmJmOjk2OgogICAgICAgICBh MDpmYzoyYjo2ZTplYjo0MToyZTplYzoxZDo4MzoyMDo4Yzo3MjoyYzphYzpkZjoxMzo1OAotLS0t LUJFR0lOIENFUlRJRklDQVRFLS0tLS0KTUlJQmpEQ0NBVEdnQXdJQkFnSUVYYjNsL0RBS0JnZ3Fo a2pPUFFRREFqQWFNUmd3RmdZRFZRUUREQTlTVDFWVQpSVkl0TURBd01UQXdNREF3SUJjTk1UY3dN VEV3TVRrMU5UVXdXaGdQTWpJNU1ERXdNalV4T1RVMU5UQmFNQm94CkdEQVdCZ05WQkFNTUQxSlBW VlJGVWkwd01EQXhNREF3TURCWk1CTUdCeXFHU000OUFnRUdDQ3FHU000OUF3RUgKQTBJQUJDajhY K212ejE5TXF6OWZoY3NoTDhIcDBPRGI2dTVDVzlMdzB4ZGFvT21KNnB0Z1BqanpYN01wMzBsVwpR Zks2QkE4Y09zWVRnd2Z5Vjh1bXVMV0k5QitqWXpCaE1Bc0dBMVVkRHdRRUF3SUhnREFkQmdOVkhR NEVGZ1FVClIvSTc4YXN2aXAwbWhrNjcyTjhuRWNkRUJ1d3dFd1lEVlIwbEJBd3dDZ1lJS3dZQkJR VUhBeDR3SGdZSUt3WUIKQlFVSEFRZ0JBZjhFRHpBTm9BY3dCUUlEQVFBQW9RSUZBREFLQmdncWhr ak9QUVFEQWdOSkFEQkdBaUVBc0RpLwpTcTdKSHVITnNSZUVNL2d5MDhTNlJHb2FGVHZBc28xaG5t NS9IeFFDSVFEQWk3aTRuNlQxdVZSb21BNi9scUQ4CksyN3JRUzdzSFlNZ2pISXNyTjhUV0E9PQot LS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCgoKCkJHUFNlYyBVcGRhdGUgZnJvbSBBUyg2NTUzNikg dG8gQVMoNjU1MzcpOgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 CkJpbmFyeSBGb3JtIG9mIEJHUFNlYyBVcGRhdGUgKFRDUC1EVU1QKToKRkYgRkYgRkYgRkYgRkYg RkYgRkYgRkYgIEZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGCjAxIDAwIDAyIDAwIDAwIDAwIEU5IDQw ICAwMSAwMSAwMiA4MCAwNCAwNCAwMCAwMAowMCAwMCA4MCAwRSAwRCAwMCAwMSAwMSAgMDQgQzYg MzMgNjQgNjQgMDAgMTggQzAKMDAgMDIgOTAgMUUgMDAgQ0EgMDAgMEUgIDAxIDAwIDAwIDAxIDAw IDAwIDAxIDAwCjAwIDAwIEZCIEYwIDAwIEJDIDAxIDQ3ICBGMiAzQiBGMSBBQiAyRiA4QSA5RCAy Ngo4NiA0RSBCQiBEOCBERiAyNyAxMSBDNyAgNDQgMDYgRUMgMDAgNDYgMzAgNDQgMDIKMjAgNzIg MTQgQkMgOTYgNDcgMTYgMEIgIEJEIDM5IEZGIDJGIDgwIDUzIDNGIDVECkM2IEREIEQ3IDBEIERG IDg2IEJCIDgxICA1NiA2MSBFOCAwNSBENSBENCBFNiBGMgo3QyAwMiAyMCAyRCBEQyAwMCAzQyA2 NCAgQkUgN0IgMjkgQzkgRUIgREIgQzggQTQKOTcgRUQgNjYgMjggNUUgRTkgMjIgNzYgIDgzIEU2 IEMxIDc4IENFIDhEIEU2IEQzCjU5IDVGIDQxIEFCIDREIDkxIDBGIDU1ICBDQSBFNyAxQSAyMSA1 RSBGMyBDQSBGRQozQSBDQyA0NSBCNSBFRSBDMSA1NCAwMCAgNDcgMzAgNDUgMDIgMjAgNzIgMTQg QkMKOTYgNDcgMTYgMEIgQkQgMzkgRkYgMkYgIDgwIDUzIDNGIDVEIEM2IEREIEQ3IDBECkRGIDg2 IEJCIDgxIDU2IDYxIEU4IDA1ICBENSBENCBFNiBGMiA3QyAwMiAyMSAwMApDNiAxNyAxOSAzNCAw NyA0MyAwNiAzQiAgOEEgNUMgQ0QgNTQgMTYgMzkgMEIgMzEKMjEgMUQgM0MgNTIgNDggMDcgOTUg ODcgIEQwIDEzIDEzIDdCIDQxIENEIDIzIEUyCgoKU2lnbmF0dXJlIEZyb20gQVMoNjQ0OTYpIHRv IEFTKDY1NTM2KToKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCkRpZ2Vz dDogICAgMjEgMzMgRTUgQ0EgQTAgMjYgQkUgMDcgICAzRCA5QyAxQiA0RSBGRSBCOSBCOSA3NyAK ICAgICAgICAgICA5RiAyMCBGOCBGNSBERSAyOSBGQSA5OCAgIDQwIDAwIDlGIDYwIApTaWduYXR1 cmU6IDMwIDQ1IDAyIDIwIDcyIDE0IEJDIDk2ICAgNDcgMTYgMEIgQkQgMzkgRkYgMkYgODAgCiAg ICAgICAgICAgNTMgM0YgNUQgQzYgREQgRDcgMEQgREYgICA4NiBCQiA4MSA1NiA2MSBFOCAwNSBE NSAKICAgICAgICAgICBENCBFNiBGMiA3QyAwMiAyMSAwMCBDNiAgIDE3IDE5IDM0IDA3IDQzIDA2 IDNCIDhBIAogICAgICAgICAgIDVDIENEIDU0IDE2IDM5IDBCIDMxIDIxICAgMUQgM0MgNTIgNDgg MDcgOTUgODcgRDAgCiAgICAgICAgICAgMTMgMTMgN0IgNDEgQ0QgMjMgRTIgCgpTaWduYXR1cmUg RnJvbSBBUyg2NTUzNikgdG8gQVMoNjU1MzcpOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQpEaWdlc3Q6ICAgIDQ2IDRCIDU3IENFIEIxIDJEIDE4IEIwICAgRkQgMUEgMUEg MzUgOTQgMTcgM0EgNEEgCiAgICAgICAgICAgMDkgODggRTUgRjQgRUQgRUQgMkYgM0QgICA4MyAw OCA1QSBBOCAKU2lnbmF0dXJlOiAzMCA0NCAwMiAyMCA3MiAxNCBCQyA5NiAgIDQ3IDE2IDBCIEJE IDM5IEZGIDJGIDgwIAogICAgICAgICAgIDUzIDNGIDVEIEM2IEREIEQ3IDBEIERGICAgODYgQkIg ODEgNTYgNjEgRTggMDUgRDUgCiAgICAgICAgICAgRDQgRTYgRjIgN0MgMDIgMjAgMkQgREMgICAw MCAzQyA2NCBCRSA3QiAyOSBDOSBFQiAKICAgICAgICAgICBEQiBDOCBBNCA5NyBFRCA2NiAyOCA1 RSAgIEU5IDIyIDc2IDgzIEU2IEMxIDc4IENFIAogICAgICAgICAgIDhEIEU2IEQzIDU5IDVGIDQx IAoKClRoZSBodW1hbiByZWFkYWJsZSBvdXRwdXQgaXMgcHJvZHVjZWQgdXNpbmcgYmdwc2VjLWlv LCBhIGJncHNlYyAKdHJhZmZpYyBnZW5lcmF0b3IgdGhhdCB1c2VzIGEgd2lyZXNoYXJrIGxpa2Ug cHJpbnRvdXQuCgpTZW5kIFVwZGF0ZSBNZXNzYWdlCistLW1hcmtlcjogRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYKKy0tbGVuZ3RoOiAyNTYKKy0tdHlwZTogICAyIChVUERBVEUpCist LXdpdGhkcmF3bl9yb3V0ZXNfbGVuZ3RoOiAwCistLXRvdGFsX3BhdGhfYXR0cl9sZW5ndGg6IDIz MwogICArLS1PUklHSU46IElOQ09NUExFVEUgKDQgYnl0ZXMpCiAgIHwgICstLUZsYWdzOiAweDQw IChXZWxsLUtub3duLCBUcmFuc2l0aXZlLCBDb21wbGV0ZSkKICAgfCAgKy0tVHlwZSBDb2RlOiBP UklHSU4gKDEpCiAgIHwgICstLUxlbmd0aDogMSBieXRlCiAgIHwgICstLU9yaWdpbjogSU5DT01Q TEVURSAoMSkKICAgKy0tTVVMVElfRVhJVF9ESVNDICg3IGJ5dGVzKQogICB8ICArLS1GbGFnczog MHg4MCAoT3B0aW9uYWwsIENvbXBsZXRlKQogICB8ICArLS1UeXBlIENvZGU6IE1VTFRJX0VYSVRf RElTQyAoNCkKICAgfCAgKy0tTGVuZ3RoOiA0IGJ5dGVzCiAgIHwgICstLWRhdGE6IDAwIDAwIDAw IDAwIAogICArLS1NUF9SRUFDSF9OTFJJICgxNiBieXRlcykKICAgfCAgKy0tRmxhZ3M6IDB4ODAg KE9wdGlvbmFsLCBDb21wbGV0ZSkKICAgfCAgKy0tVHlwZSBDb2RlOiBNUF9SRUFDSF9OTFJJICgx NCkKICAgfCAgKy0tTGVuZ3RoOiAxMyBieXRlcwogICB8ICArLS1kYXRhOiAwMCAwMSAwMSAwNCBD NiAzMyA2NCA2NCAgIDAwIDE4IEMwIDAwIDAyIAogICArLS1CR1BTRUMgUGF0aCBBdHRyaWJ1dGUg KDIwNiBieXRlcykKICAgICAgKy0tRmxhZ3M6IDB4OTAgKE9wdGlvbmFsLCBDb21wbGV0ZSwgRXh0 ZW5kZWQgTGVuZ3RoKQogICAgICArLS1UeXBlIENvZGU6IEJHUFNFQyBQYXRoIEF0dHJpYnV0ZSAo MzApCiAgICAgICstLUxlbmd0aDogMjAyIGJ5dGVzCiAgICAgICstLVNlY3VyZSBQYXRoICgxNCBi eXRlcykKICAgICAgfCAgKy0tTGVuZ3RoOiAxNCBieXRlcwogICAgICB8ICArLS1TZWN1cmUgUGF0 aCBTZWdtZW50OiAoNiBieXRlcykKICAgICAgfCAgfCAgKy0tcENvdW50OiAxCiAgICAgIHwgIHwg ICstLUZsYWdzOiAwCiAgICAgIHwgIHwgICstLUFTIG51bWJlcjogNjU1MzYgKDEuMCkKICAgICAg fCAgKy0tU2VjdXJlIFBhdGggU2VnbWVudDogKDYgYnl0ZXMpCiAgICAgIHwgICAgICstLXBDb3Vu dDogMQogICAgICB8ICAgICArLS1GbGFnczogMAogICAgICB8ICAgICArLS1BUyBudW1iZXI6IDY0 NDk2ICgwLjY0NDk2KQogICAgICArLS1TaWduYXR1cmUgQmxvY2sgKDE4OCBieXRlcykKICAgICAg ICAgKy0tTGVuZ3RoOiAxODggYnl0ZXMKICAgICAgICAgKy0tQWxnbyBJRDogMQogICAgICAgICAr LS1TaWduYXR1cmUgU2VnbWVudDogKDkyIGJ5dGVzKQogICAgICAgICB8ICArLS1TS0k6IDQ3RjIz QkYxQUIyRjhBOUQyNjg2NEVCQkQ4REYyNzExQzc0NDA2RUMKICAgICAgICAgfCAgKy0tTGVuZ3Ro OiA3MCBieXRlcwogICAgICAgICB8ICArLS1TaWduYXR1cmU6IDMwIDQ0IDAyIDIwIDcyIDE0IEJD IDk2ICA0NyAxNiAwQiBCRCAzOSBGRiAyRiA4MCAKICAgICAgICAgfCAgICAgICAgICAgICAgICA1 MyAzRiA1RCBDNiBERCBENyAwRCBERiAgODYgQkIgODEgNTYgNjEgRTggMDUgRDUgCiAgICAgICAg IHwgICAgICAgICAgICAgICAgRDQgRTYgRjIgN0MgMDIgMjAgMkQgREMgIDAwIDNDIDY0IEJFIDdC IDI5IEM5IEVCIAogICAgICAgICB8ICAgICAgICAgICAgICAgIERCIEM4IEE0IDk3IEVEIDY2IDI4 IDVFICBFOSAyMiA3NiA4MyBFNiBDMSA3OCBDRSAKICAgICAgICAgfCAgICAgICAgICAgICAgICA4 RCBFNiBEMyA1OSA1RiA0MSAKICAgICAgICAgKy0tU2lnbmF0dXJlIFNlZ21lbnQ6ICg5MyBieXRl cykKICAgICAgICAgICAgKy0tU0tJOiBBQjREOTEwRjU1Q0FFNzFBMjE1RUYzQ0FGRTNBQ0M0NUI1 RUVDMTU0CiAgICAgICAgICAgICstLUxlbmd0aDogNzEgYnl0ZXMKICAgICAgICAgICAgKy0tU2ln bmF0dXJlOiAzMCA0NSAwMiAyMCA3MiAxNCBCQyA5NiAgNDcgMTYgMEIgQkQgMzkgRkYgMkYgODAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgNTMgM0YgNUQgQzYgREQgRDcgMEQgREYgIDg2IEJC IDgxIDU2IDYxIEU4IDA1IEQ1IAogICAgICAgICAgICAgICAgICAgICAgICAgIEQ0IEU2IEYyIDdD IDAyIDIxIDAwIEM2ICAxNyAxOSAzNCAwNyA0MyAwNiAzQiA4QSAKICAgICAgICAgICAgICAgICAg ICAgICAgICA1QyBDRCA1NCAxNiAzOSAwQiAzMSAyMSAgMUQgM0MgNTIgNDggMDcgOTUgODcgRDAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgMTMgMTMgN0IgNDEgQ0QgMjMgRTIgCg== --_004_2459DA8D593F4B759C74619DDBA907E4nistgov_-- From nobody Wed Jan 11 08:54:16 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C460C1295D9; Wed, 11 Jan 2017 08:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.756 X-Spam-Level: X-Spam-Status: No, score=-3.756 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 PTYXwI-xJ2La; Wed, 11 Jan 2017 08:54:11 -0800 (PST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (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 BC556129416; Wed, 11 Jan 2017 08:54:11 -0800 (PST) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 1FE166004F; Wed, 11 Jan 2017 16:54:11 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx4-us3.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 81CFF60055; Wed, 11 Jan 2017 16:54:10 +0000 (UTC) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03lp0021.outbound.protection.outlook.com [216.32.181.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx4-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 16DAC80057; Wed, 11 Jan 2017 16:54:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AmthXFSY3SVRPi8BTUcfc+sGANV4M+RiYcf8Ju66rFE=; b=hknuwLmsJAPR2TL0X6I5klcYWCN2ukSMgFzH3ie9gyaGLzBss5H5eeA6BZ/ByRXxH0Uy6ZPUIjib1/t2nOi+zIMYQAcVjK3gMlRTvFJZ7qzuY12wmiiylkqfXxC+8yi96dpElcYBLTx1Fcu49CvmpzGJ/LDmiMNUOqbmGqVtgjw= Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0263.namprd18.prod.outlook.com (10.163.72.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Wed, 11 Jan 2017 16:54:02 +0000 Received: from BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) by BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) with mapi id 15.01.0829.017; Wed, 11 Jan 2017 16:54:02 +0000 From: Keyur Patel To: "Alvaro Retana (aretana)" , "Sriram, Kotikalapudi (Fed)" Thread-Topic: draft-ietf-sidr-bgpsec-protocol Thread-Index: AQHSZthkNfH8MXPYLkOmxwl9coeqv6EoZskAgAKH0dSAASfLgIAG7GoA Date: Wed, 11 Jan 2017 16:54:02 +0000 Message-ID: <67DBF30E-B262-4568-87FB-96EEF9FB87A9@arrcus.com> References: <6C8E073D-F1AB-4588-8DFF-FAA0A2465273@cisco.com> In-Reply-To: <6C8E073D-F1AB-4588-8DFF-FAA0A2465273@cisco.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=keyur@arrcus.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:646:8980:4f18:f1bf:786f:d301:2422] x-ms-office365-filtering-correlation-id: 06c1a9d1-98fc-40ac-593b-08d43a42721c x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR18MB0263; x-microsoft-exchange-diagnostics: 1; BY2PR18MB0263; 7:3qY0eR89RS5LzH4UlfjzqGbNhZy8dmidRYg2FLHqbWm7zr7BgQbQZSbtlTnmo+x8q0+G7Y8icKGFFAQcPxX0uxgns0n6Q30sTxb4IArPrbzF97Dt56HP1X2Ni8V4rAJaxlEXODlyVj1MN57XWRklj/OSVksdEsh7dAV9Z2N//uvTTU7QbG8uEJ9Ceq/Vp6aCevegyLjz29wvZz/kaJmmbNVZrBoFqFno4DYVJZCsInGFIpPYzDykTq87w812c2wt0DDIKyw1ZcuF0gcsPYG4Z9jG/fQRdU6D6jqjgSnq0nwEoIaU36PfwG7BEfky4H6Xgrj7+6JsD8iLkVKL7BuG+l/nDg//re1VfYBPZg9GwW8gRreeE/Lu2bOHg86cy6hZqWrrETzWuVu9i6GOGp7o7Lm0M7kt5DAJsxyp4Ay8lR5Gbc7sSVOIrMj7luYM0I5k3dSILdJdN8WN2lYQtQmIpw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(95692535739014)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(2016111802025)(6072148)(6043046); SRVR:BY2PR18MB0263; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0263; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39410400002)(39450400003)(39830400002)(377454003)(199003)(24454002)(189002)(2900100001)(4326007)(102836003)(54906002)(189998001)(6116002)(230783001)(99286003)(54896002)(8656002)(6306002)(6436002)(77096006)(38730400001)(86362001)(101416001)(122556002)(6486002)(25786008)(7736002)(2906002)(6506006)(229853002)(6512007)(5001770100001)(97736004)(92566002)(33656002)(54356999)(50986999)(76176999)(3280700002)(93886004)(81166006)(8676002)(8936002)(36756003)(82746002)(81156014)(3660700001)(106116001)(5660300001)(2950100002)(83716003)(68736007)(105586002)(5890100001)(106356001)(9326002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0263; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_67DBF30EB262456887FB96EEF9FB87A9arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2017 16:54:02.0743 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0263 X-MDID: 1484153651-7XMbExrkiipW Archived-At: Cc: "sidr-chairs@ietf.org" , "mlepinski@ncf.edu" , sidr Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 16:54:15 -0000 --_000_67DBF30EB262456887FB96EEF9FB87A9arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWx2YXJvLA0KDQpDb21tZW50cyBpbmxpbmVkICNLZXl1cg0KDQpGcm9tOiAiQWx2YXJvIFJl dGFuYSAoYXJldGFuYSkiIDxhcmV0YW5hQGNpc2NvLmNvbT4NCkRhdGU6IEZyaWRheSwgSmFudWFy eSA2LCAyMDE3IGF0IDM6MTAgUE0NClRvOiAiU3JpcmFtLCBLb3Rpa2FsYXB1ZGkgKEZlZCkiIDxr b3Rpa2FsYXB1ZGkuc3JpcmFtQG5pc3QuZ292PiwgS2V5dXIgUGF0ZWwgPGtleXVyQGFycmN1cy5j b20+DQpDYzogInNpZHItY2hhaXJzQGlldGYub3JnIiA8c2lkci1jaGFpcnNAaWV0Zi5vcmc+LCBz aWRyIDxzaWRyQGlldGYub3JnPiwgIm1sZXBpbnNraUBuY2YuZWR1IiA8bWxlcGluc2tpQG5jZi5l ZHU+DQpTdWJqZWN0OiBSZTogZHJhZnQtaWV0Zi1zaWRyLWJncHNlYy1wcm90b2NvbA0KDQoNCk9u IDEvNi8xNywgMTI6NDAgQU0sICJTcmlyYW0sIEtvdGlrYWxhcHVkaSAoRmVkKSIgPGtvdGlrYWxh cHVkaS5zcmlyYW1AbmlzdC5nb3Y+IHdyb3RlOg0KDQoNCg0KW0N1dCB0aGUgZGlzdHJpYnV0aW9u IGxpc3QgYSBsaXR0bGUuXQ0KDQoNCg0KU3JpcmFtOg0KDQoNCg0KSGkhICBIYXBweSBOZXcgWWVh ciENCg0KDQoNCkkgaGF2ZSBzb21lIGNvbW1lbnRzIG9uIHRoaXMsIHBsZWFzZSBzZWUgYmVsb3cu DQoNCg0KDQpUaGFua3MhDQoNCg0KDQpBbHZhcm8uDQoNCg0KDQoNCg0K4oCmDQoNCnwgfCAxKSAg U2VjdGlvbiA0LjEg4oCcVGhlIEJHUHNlYyBQYXRoIGF0dHJpYnV0ZSBhbmQgdGhlIEFTX1BBVEgg YXR0cmlidXRlIGFyZSBtdXR1YWxseQ0KDQp8IHwgZXhjbHVzaXZlLiBUaGF0IGlzLCBhbnkgdXBk YXRlIG1lc3NhZ2UgY29udGFpbmluZyB0aGUgQkdQc2VjIFBhdGggYXR0cmlidXRlIE1VU1QgTk9U DQoNCnwgfCBjb250YWluIHRoZSBBU19QQVRIIGF0dHJpYnV0ZeKAnS4gIEZvciBhbnkgcmVzdGFy dGluZyBzcGVha2VycyBpbiBhIEdSIG1vZGUsIHdoZXJlIHRoZSBiZ3ANCg0KfCB8IGNhcGFiaWxp dHkgaXMgbm90IGV4Y2hhbmdlZCwgdGhlIGV4aXN0aW5nIHN0YWxlIHJvdXRlcyB3b27igJl0IGhh dmUgYW4gQVNfUEFUSCBhdHRyaWJ1dGUuIFdlDQoNCnwgfCBjb3VsZCBhZGQgc29tZSBjbGFyaWZ5 aW5nIHRoYXQgaGVscHMgdG8gaW5kaWNhdGUgdGhhdCBzdWNoIHJvdXRlcyBzaG91bGQgYmUgY29u c2lkZXJlZA0KDQp8IHwgdmFsaWQgaW4gc3RhbGUgbW9kZSAodGlsbCB0aGV5IGdldCByZWZyZXNo ZWQpPw0KDQp8DQoNCnwgW1NyaXJhbV0gIEFzIHlvdSBoYXZlIGNsYXJpZmllZCBmb3IgbWUgb24g dGhlIHBob25lLCB3aGF0IHlvdSBhcmUgc2F5aW5nIGhlcmUgaXMgdGhhdCB0aGUNCg0KfCB0d28g QkdQc2VjIHBlZXJzIGxvc3QgdGhlIEJHUHNlYyBzZXNzaW9uIGFuZCBub3cgcmVzdGFydGluZyBp biBHUiBtb2RlLCBidXQgdGhleSBoYXZlIG5vdA0KDQp8IGV4Y2hhbmdlZCBCR1BzZWMgY2FwYWJp bGl0eSB0aGlzIHRpbWUuIEhlbmNlLCB0aGV5IGFyZSBub3cgc2ltcGxlIEJHUCAobm9uLUJHUHNl YykgcGVlcnMNCg0KfCBpbiBHUiBtb2RlLiBSRkM0MjcxIGNvbnNpZGVycyB1cGRhdGUgbWVzc2Fn ZSByZWNlaXZlZCB3aXRob3V0IGEgd2VsbC1rbm93biBBU19QQVRIDQoNCnwgYXR0cmlidXRlIGFz IGFuIGVycm9yLCBhbmQgdW5mb3J0dW5hdGVseSBpbiB0aGlzIGNhc2UgdGhlIGNhY2hlZCBCR1Bz ZWMgdXBkYXRlcyBkbyBub3QgaGF2ZQ0KDQp8IEFTX1BBVEggKGFsYmVpdCB0aGV5IGhhdmUgQkdQ c2VjX1BhdGgpLiBTbyB5b3UgYXJlIHNheWluZyAidGhlIHJvdXRlciBzaG91bGQgbm90IHBhbmlj Ig0KDQp8IGFuZCBpbnN0ZWFkIHNpbXBseSB0cmVhdCBlYWNoIGNhY2hlZCB1cGRhdGUgYXMgTk9U LUlOLUVSUk9SIGV2ZW4gdGhvdWdoIGl0IGlzIG1pc3NpbmcNCg0KfCBBU19QQVRIIGF0dHJpYnV0 ZS4gVGhpcyB3YXkgdGhlIEdSIGNhbiB3b3JrIHByb3Blcmx5LiBPZiBjb3Vyc2UsIHNob3J0bHkg dGhlIHVwZGF0ZXMgd2lsbA0KDQp8IGhhdmUgQVNfUEFUSCAoYW5kIG5vdCBjb25zaWRlcmVkIGlu IGVycm9yKSB3aGVuIHRoZXkgZ2V0IHJlZnJlc2hlZCAob3ZlciB0aGUgbmV3IHNpbXBsZQ0KDQp8 IEJHUCBzZXNzaW9uKS4gUGVyIHlvdXIgc3VnZ2VzdGlvbiwgSSB3aWxsIGluY2x1ZGUgbmV3IHRl eHQgaW4gU2VjdGlvbiA3IHRvIGRlc2NyaWJlIHRoaXMNCg0KfCByZXF1aXJlZCBiZWhhdmlvciBm b3IgdGhlIEdSIG1vZGUuDQoNCg0KDQpJIGRvbuKAmXQgaGF2ZSBhbiBvYmplY3Rpb24gZm9yIHRo aXMgYmVoYXZpb3IsIGJ1dCBJIHRoaW5rIHdlIHNob3VsZCBtYWtlIHRoZSBXRyAoYW5kIGlkciEp IGF3YXJlIG9mIHRoZSBjaGFuZ2UgYW5kIGdldCB0aGVpciBjb21tZW50cyAoaWYgYW55KSBiZWZv cmUgSSBhcHByb3ZlIHRoZSBwdWJsaWNhdGlvbi4NCg0KDQoNCiNLZXl1cjogQWNrLiBUaG91Z2gg SSB3YXMgb25seSByZXF1ZXN0aW5nIHNvbWUgdGV4dCBjbGFyaWZpY2F0aW9uIHNvIHRoYXQgaXQg aXMgdmVyeSBjbGVhciB0byB0aGUgaW1wbGVtZW50ZXJzLg0KDQoNCg0KUmVnYXJkcywNCg0KS2V5 dXINCg0KDQoNCg0KDQrigKYNCg0KfCB8IDMpICBTZWN0aW9uIDUgYW5kIFNlY3Rpb24gNS4yLCAx c3QgcGFyYWdyYXBoOiBSRkM0MjcxIGNvbnNpZGVycyB1cGRhdGUgbWVzc2FnZSByZWNlaXZlZA0K DQp8IHwgd2l0aG91dCBhIHdlbGwta25vd24gQVNfUEFUSCBhdHRyaWJ1dGUgYXMgYW4gZXJyb3Iu ICBXZSBuZWVkIHNvbWUgdGV4dCB0byBjbGFyaWZ5IHRoZQ0KDQp8IHwgKGVycm9yIGhhbmRsaW5n IGlmIGFueSkgYmVoYXZpb3Igd2hlbiBhbiB1cGRhdGUgbWVzc2FnZSBpcyByZWNlaXZlZCB3aXRo b3V0IGEgYmdwc2VjIGFuZA0KDQp8IHwgYW4gYXNwYXRoIGF0dHJpYnV0ZS4gVGhlIGN1cnJlbnQg ZHJhZnQgdGV4dCBzZWVtcyB1bmNsZWFyIGFib3V0IGdlbmVyYXRpb24gb2YgYmdwc2VjDQoNCnwg fCBhdHRyaWJ1dGUgYXMgd2VsbCAoaW4gYSBpYmdwIHNjZW5hcmlvKS4gSXMgaXQgYSByZXF1aXJl bWVudCB0byBnZW5lcmF0ZSBhbiBlbXB0eSBiZ3BzZWMNCg0KfCB8IGF0dHJpYnV0ZT8NCg0KfA0K DQp8IFtTcmlyYW1dICBBcyB5b3UgaGF2ZSBjbGFyaWZpZWQgZm9yIG1lIG92ZXIgdGhlIHBob25l LCBSRkMgNDI3MSAocGFnZSAyNikgc2F5cyB0aGUNCg0KfCBmb2xsb3dpbmcgOg0KDQp8DQoNCnwg ICJXaGVuIGEgQkdQIHNwZWFrZXIgb3JpZ2luYXRlcyBhIHJvdXRlIHRoZW46DQoNCnwgICBiKSB0 aGUgb3JpZ2luYXRpbmcgc3BlYWtlciBpbmNsdWRlcyBhbiBlbXB0eSBBU19QQVRIIGF0dHJpYnV0 ZSBpbg0KDQp8ICAgICAgICBhbGwgVVBEQVRFIG1lc3NhZ2VzIHNlbnQgdG8gaW50ZXJuYWwgcGVl cnMuICAoQW4gZW1wdHkgQVNfUEFUSA0KDQp8ICAgICAgICAgYXR0cmlidXRlIGlzIG9uZSB3aG9z ZSBsZW5ndGggZmllbGQgY29udGFpbnMgdGhlIHZhbHVlIHplcm8pLiINCg0KfA0KDQp8DQoNCnwg W1NyaXJhbV0gIFNvIHdoYXQgbmVlZHMgdG8gYmUgc2FpZCBpbiB0aGUgQkdQc2VjIGRvY3VtZW50 IGlzIHRoZSBmb2xsb3dpbmc6ICBUaGUNCg0KfCBCR1BzZWNfUGF0aCBhdHRyaWJ1dGUgaXMgbm90 IGF0dGFjaGVkIGluIHVwZGF0ZXMgb3JpZ2luYXRlZCBpbnNpZGUgYW4gQVMgYW5kIHByb3BhZ2F0 ZWQgdG8NCg0KfCBCR1BzZWMgY2FwYWJsZSBpbnRlcm5hbCBwZWVycy4gSG93ZXZlciwgd2hlbiBh IHJvdXRlIGlzIG9yaWdpbmF0ZWQgaW5zaWRlIGFuIEFTIGFuZA0KDQp8IHByb3BhZ2F0ZWQgdG8g bm9uLUJHUHNlYyBpbnRlcm5hbCBwZWVycywgYW4gZW1wdHkgQVNfUEFUSCBhdHRyaWJ1dGUgaXMg aW5jbHVkZWQgaW4gdGhlDQoNCnwgdXBkYXRlIChzZWUgW1JGQyA0MjcxXSwgcGFnZSAyNikuDQoN Cg0KDQpUaGUgUm91dGUgU2VsZWN0aW9uIFNlY3Rpb24gKDkuMS4yKSBpbiBSRkM0MjcxIGlzIG5v dCBleHBsaWNpdCBhYm91dCBwZXJmb3JtaW5nIGxvb3AgZGV0ZWN0aW9uIG9ubHkgb24gZUJHUCBz ZXNzaW9ucyDigJMgdGhlIGNyaXRlcmlhIGlzIGdlbmVyaWMgdG8gYW55IHJvdXRlLCBzbyB0aGVy ZSBpcyBhIHBvc3NpYmlsaXR5IHRoYXQgYSBCR1BzZWMtY2FwYWJsZSByb3V0ZXIgbWF5IHdhbnQg dG8gcGVyZm9ybSBsb29wIGRldGVjdGlvbiBvbiBhbiBpQkdQLXJlY2VpdmVkIFVwZGF0ZS4gIEdp dmVuIHRoaXMgdGV4dCBmcm9tIFNlY3Rpb24gNSBpbiB0aGUgQkdQc2VjIHNwZWM6DQoNCg0KDQog ICBXaGVuZXZlciB0aGUgdXNlIG9mIEFTIHBhdGggaW5mb3JtYXRpb24gaXMgY2FsbGVkIGZvcg0K DQogICAoZS5nLiwgbG9vcCBkZXRlY3Rpb24sIG9yIHVzZSBvZiBBUyBwYXRoIGxlbmd0aCBpbiBi ZXN0IHBhdGgNCg0KICAgc2VsZWN0aW9uKSB0aGUgZXh0ZXJuYWxseSB2aXNpYmxlIGJlaGF2aW9y IG9mIHRoZSBpbXBsZW1lbnRhdGlvbg0KDQogICBzaGFsbCBiZSB0aGUgc2FtZSBhcyBpZiB0aGUg aW1wbGVtZW50YXRpb24gaGFkIHJ1biB0aGUgYWxnb3JpdGhtIGluDQoNCiAgIFNlY3Rpb24gNC40 IGFuZCB1c2VkIHRoZSByZXN1bHRpbmcgQVNfUEFUSCBhdHRyaWJ1dGUgYXMgaXQgd291bGQgZm9y DQoNCiAgIGEgbm9uLUJHUHNlYyB1cGRhdGUgbWVzc2FnZS4NCg0KDQoNCuKApmhvdyBzaG91bGQg YW4gaUJHUCBzcGVha2VyIHBlcmZvcm0gbG9vcCBkZXRlY3Rpb24gaWYgdGhlcmXigJlzIG5vIEJH UHNlY19QYXRoIGF0dHJpYnV0ZT8gIEluIG90aGVyIHdvcmRzLCB0aGVyZSBpcyBubyBkZWZpbmVk IG1lY2hhbmlzbSB0byBydW4gdGhlIGFsZ29yaXRobSBpbiA0LjQgd2l0aG91dCBpdC4NCg0KDQoN CknigJltIG5vdCBzdWdnZXN0aW5nIHRoYXQgeW91IGluY2x1ZGUgYW4gZW1wdHkgYXR0cmlidXRl LCBidXQgdGhhdCB5b3UgaW5kaWNhdGUgaW4gNC40IHRoYXQgbm8gQkdQc2VjX1BhdGggYXR0cmli dXRlIGlzIGVxdWl2YWxlbnQgdG8gYW4gZW1wdHkgQVNfUEFUSC4NCg0KDQoNClRoYW5rcyENCg0K DQoNCkFsdmFyby4NCg== --_000_67DBF30EB262456887FB96EEF9FB87A9arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <45BFEBDDEA66A246899ACFD5097E7834@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxp YnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5 bGU6bm9ybWFsO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFu Lm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToi IjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+SGkgQWx2YXJvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PkNvbW1lbnRzIGlubGluZWQgI0tleXVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+JnF1b3Q7QWx2YXJvIFJldGFuYSAoYXJldGFuYSkm cXVvdDsgJmx0O2FyZXRhbmFAY2lzY28uY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXks IEphbnVhcnkgNiwgMjAxNyBhdCAzOjEwIFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtTcmlyYW0s IEtvdGlrYWxhcHVkaSAoRmVkKSZxdW90OyAmbHQ7a290aWthbGFwdWRpLnNyaXJhbUBuaXN0Lmdv diZndDssIEtleXVyIFBhdGVsICZsdDtrZXl1ckBhcnJjdXMuY29tJmd0Ozxicj4NCjxiPkNjOiA8 L2I+JnF1b3Q7c2lkci1jaGFpcnNAaWV0Zi5vcmcmcXVvdDsgJmx0O3NpZHItY2hhaXJzQGlldGYu b3JnJmd0Oywgc2lkciAmbHQ7c2lkckBpZXRmLm9yZyZndDssICZxdW90O21sZXBpbnNraUBuY2Yu ZWR1JnF1b3Q7ICZsdDttbGVwaW5za2lAbmNmLmVkdSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ UmU6IGRyYWZ0LWlldGYtc2lkci1iZ3BzZWMtcHJvdG9jb2w8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+T24gMS82LzE3LCAxMjo0MCBBTSwg JnF1b3Q7U3JpcmFtLCBLb3Rpa2FsYXB1ZGkgKEZlZCkmcXVvdDsgJmx0O2tvdGlrYWxhcHVkaS5z cmlyYW1AbmlzdC5nb3YmZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5b Q3V0IHRoZSBkaXN0cmlidXRpb24gbGlzdCBhIGxpdHRsZS5dPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPlNyaXJhbTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SGkhJm5ic3A7 IEhhcHB5IE5ldyBZZWFyITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIGhhdmUgc29t ZSBjb21tZW50cyBvbiB0aGlzLCBwbGVhc2Ugc2VlIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5UaGFua3MhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFsdmFyby48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij7igKY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPnwgfCAxKSZuYnNwOyZuYnNwO1NlY3Rpb24gNC4xIOKAnFRoZSBCR1BzZWMgUGF0aCBh dHRyaWJ1dGUgYW5kIHRoZSBBU19QQVRIIGF0dHJpYnV0ZSBhcmUgbXV0dWFsbHkNCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCB8IGV4Y2x1c2l2ZS4gVGhhdCBpcywg YW55IHVwZGF0ZSBtZXNzYWdlIGNvbnRhaW5pbmcgdGhlIEJHUHNlYyBQYXRoIGF0dHJpYnV0ZSBN VVNUIE5PVA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IHwgY29u dGFpbiB0aGUgQVNfUEFUSCBhdHRyaWJ1dGXigJ0uJm5ic3A7Jm5ic3A7Rm9yIGFueSByZXN0YXJ0 aW5nIHNwZWFrZXJzIGluIGEgR1IgbW9kZSwgd2hlcmUgdGhlIGJncA0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IHwgY2FwYWJpbGl0eSBpcyBub3QgZXhjaGFuZ2Vk LCB0aGUgZXhpc3Rpbmcgc3RhbGUgcm91dGVzIHdvbuKAmXQgaGF2ZSBhbiBBU19QQVRIIGF0dHJp YnV0ZS4gV2UNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCB8IGNv dWxkIGFkZCBzb21lIGNsYXJpZnlpbmcgdGhhdCBoZWxwcyB0byBpbmRpY2F0ZSB0aGF0IHN1Y2gg cm91dGVzIHNob3VsZCBiZSBjb25zaWRlcmVkDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPnwgfCB2YWxpZCBpbiBzdGFsZSBtb2RlICh0aWxsIHRoZXkgZ2V0IHJlZnJl c2hlZCk/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IFtTcmlyYW1dJm5ic3A7Jm5ic3A7QXMg eW91IGhhdmUgY2xhcmlmaWVkIGZvciBtZSBvbiB0aGUgcGhvbmUsIHdoYXQgeW91IGFyZSBzYXlp bmcgaGVyZSBpcyB0aGF0IHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij58IHR3byBCR1BzZWMgcGVlcnMgbG9zdCB0aGUgQkdQc2VjIHNlc3Npb24gYW5kIG5vdyBy ZXN0YXJ0aW5nIGluIEdSIG1vZGUsIGJ1dCB0aGV5IGhhdmUgbm90DQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwgZXhjaGFuZ2VkIEJHUHNlYyBjYXBhYmlsaXR5IHRo aXMgdGltZS4gSGVuY2UsIHRoZXkgYXJlIG5vdyBzaW1wbGUgQkdQIChub24tQkdQc2VjKSBwZWVy cw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IGluIEdSIG1vZGUu IFJGQzQyNzEgY29uc2lkZXJzIHVwZGF0ZSBtZXNzYWdlIHJlY2VpdmVkIHdpdGhvdXQgYSB3ZWxs LWtub3duIEFTX1BBVEgNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ fCBhdHRyaWJ1dGUgYXMgYW4gZXJyb3IsIGFuZCB1bmZvcnR1bmF0ZWx5IGluIHRoaXMgY2FzZSB0 aGUgY2FjaGVkIEJHUHNlYyB1cGRhdGVzIGRvIG5vdCBoYXZlDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPnwgQVNfUEFUSCAoYWxiZWl0IHRoZXkgaGF2ZSBCR1BzZWNf UGF0aCkuIFNvIHlvdSBhcmUgc2F5aW5nICZxdW90O3RoZSByb3V0ZXIgc2hvdWxkIG5vdCBwYW5p YyZxdW90Ow0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IGFuZCBp bnN0ZWFkIHNpbXBseSB0cmVhdCBlYWNoIGNhY2hlZCB1cGRhdGUgYXMgTk9ULUlOLUVSUk9SIGV2 ZW4gdGhvdWdoIGl0IGlzIG1pc3NpbmcNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+fCBBU19QQVRIIGF0dHJpYnV0ZS4gVGhpcyB3YXkgdGhlIEdSIGNhbiB3b3JrIHBy b3Blcmx5LiBPZiBjb3Vyc2UsIHNob3J0bHkgdGhlIHVwZGF0ZXMgd2lsbA0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IGhhdmUgQVNfUEFUSCAoYW5kIG5vdCBjb25z aWRlcmVkIGluIGVycm9yKSB3aGVuIHRoZXkgZ2V0IHJlZnJlc2hlZCAob3ZlciB0aGUgbmV3IHNp bXBsZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IEJHUCBzZXNz aW9uKS4gUGVyIHlvdXIgc3VnZ2VzdGlvbiwgSSB3aWxsIGluY2x1ZGUgbmV3IHRleHQgaW4gU2Vj dGlvbiA3IHRvIGRlc2NyaWJlIHRoaXMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+fCByZXF1aXJlZCBiZWhhdmlvciBmb3IgdGhlIEdSIG1vZGUuJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5JIGRvbuKAmXQgaGF2ZSBhbiBvYmplY3Rpb24gZm9yIHRoaXMgYmVoYXZpb3Is IGJ1dCBJIHRoaW5rIHdlIHNob3VsZCBtYWtlIHRoZSBXRyAoYW5kIGlkciEpIGF3YXJlIG9mIHRo ZSBjaGFuZ2UgYW5kIGdldCB0aGVpciBjb21tZW50cyAoaWYgYW55KSBiZWZvcmUgSSBhcHByb3Zl IHRoZSBwdWJsaWNhdGlvbi48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiNLZXl1cjogQWNrLiBUaG91Z2gg SSB3YXMgb25seSByZXF1ZXN0aW5nIHNvbWUgdGV4dCBjbGFyaWZpY2F0aW9uIHNvIHRoYXQgaXQg aXMgdmVyeSBjbGVhciB0byB0aGUgaW1wbGVtZW50ZXJzLg0KPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5S ZWdhcmRzLDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPktleXVyPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+4oCmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IHwgMykm bmJzcDsmbmJzcDtTZWN0aW9uIDUgYW5kIFNlY3Rpb24gNS4yLCAxc3QgcGFyYWdyYXBoOiBSRkM0 MjcxIGNvbnNpZGVycyB1cGRhdGUgbWVzc2FnZSByZWNlaXZlZA0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IHwgd2l0aG91dCBhIHdlbGwta25vd24gQVNfUEFUSCBh dHRyaWJ1dGUgYXMgYW4gZXJyb3IuJm5ic3A7Jm5ic3A7V2UgbmVlZCBzb21lIHRleHQgdG8gY2xh cmlmeSB0aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCB8IChl cnJvciBoYW5kbGluZyBpZiBhbnkpIGJlaGF2aW9yIHdoZW4gYW4gdXBkYXRlIG1lc3NhZ2UgaXMg cmVjZWl2ZWQgd2l0aG91dCBhIGJncHNlYyBhbmQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+fCB8IGFuIGFzcGF0aCBhdHRyaWJ1dGUuIFRoZSBjdXJyZW50IGRyYWZ0 IHRleHQgc2VlbXMgdW5jbGVhciBhYm91dCBnZW5lcmF0aW9uIG9mIGJncHNlYw0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IHwgYXR0cmlidXRlIGFzIHdlbGwgKGlu IGEgaWJncCBzY2VuYXJpbykuIElzIGl0IGEgcmVxdWlyZW1lbnQgdG8gZ2VuZXJhdGUgYW4gZW1w dHkgYmdwc2VjDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwgfCBh dHRyaWJ1dGU/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58IFtTcmlyYW1dJm5ic3A7Jm5ic3A7 QXMgeW91IGhhdmUgY2xhcmlmaWVkIGZvciBtZSBvdmVyIHRoZSBwaG9uZSwgUkZDIDQyNzEgKHBh Z2UgMjYpIHNheXMgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PnwgZm9sbG93aW5nIDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwmbmJzcDsgJnF1b3Q7V2hl biBhIEJHUCBzcGVha2VyIG9yaWdpbmF0ZXMgYSByb3V0ZSB0aGVuOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCZuYnNwOyZuYnNwOyBiKSB0aGUgb3JpZ2luYXRpbmcg c3BlYWtlciBpbmNsdWRlcyBhbiBlbXB0eSBBU19QQVRIIGF0dHJpYnV0ZSBpbjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBhbGwgVVBEQVRFIG1lc3NhZ2VzIHNlbnQgdG8gaW50ZXJuYWwgcGVl cnMuJm5ic3A7Jm5ic3A7KEFuIGVtcHR5IEFTX1BBVEg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgYXR0cmlidXRlIGlzIG9uZSB3aG9zZSBsZW5ndGggZmllbGQgY29udGFpbnMgdGhl IHZhbHVlIHplcm8pLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+fDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCBbU3JpcmFtXSZuYnNwOyZuYnNwO1NvIHdo YXQgbmVlZHMgdG8gYmUgc2FpZCBpbiB0aGUgQkdQc2VjIGRvY3VtZW50IGlzIHRoZSBmb2xsb3dp bmc6Jm5ic3A7Jm5ic3A7VGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPnwgQkdQc2VjX1BhdGggYXR0cmlidXRlIGlzIG5vdCBhdHRhY2hlZCBpbiB1cGRhdGVzIG9y aWdpbmF0ZWQgaW5zaWRlIGFuIEFTIGFuZCBwcm9wYWdhdGVkIHRvDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnwgQkdQc2VjIGNhcGFibGUgaW50ZXJuYWwgcGVlcnMu IEhvd2V2ZXIsIHdoZW4gYSByb3V0ZSBpcyBvcmlnaW5hdGVkIGluc2lkZSBhbiBBUyBhbmQNCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fCBwcm9wYWdhdGVkIHRvIG5v bi1CR1BzZWMgaW50ZXJuYWwgcGVlcnMsIGFuIGVtcHR5IEFTX1BBVEggYXR0cmlidXRlIGlzIGlu Y2x1ZGVkIGluIHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58 IHVwZGF0ZSAoc2VlIFtSRkMgNDI3MV0sIHBhZ2UgMjYpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5UaGUgUm91dGUgU2VsZWN0aW9uIFNlY3Rpb24gKDkuMS4yKSBpbiBSRkM0MjcxIGlz IG5vdCBleHBsaWNpdCBhYm91dCBwZXJmb3JtaW5nIGxvb3AgZGV0ZWN0aW9uIG9ubHkgb24gZUJH UCBzZXNzaW9ucyDigJMgdGhlIGNyaXRlcmlhIGlzIGdlbmVyaWMgdG8gYW55IHJvdXRlLCBzbyB0 aGVyZSBpcyBhIHBvc3NpYmlsaXR5IHRoYXQgYSBCR1BzZWMtY2FwYWJsZSByb3V0ZXIgbWF5IHdh bnQgdG8gcGVyZm9ybSBsb29wDQogZGV0ZWN0aW9uIG9uIGFuIGlCR1AtcmVjZWl2ZWQgVXBkYXRl LiZuYnNwOyBHaXZlbiB0aGlzIHRleHQgZnJvbSBTZWN0aW9uIDUgaW4gdGhlIEJHUHNlYyBzcGVj OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgV2hlbmV2ZXIgdGhl IHVzZSBvZiBBUyBwYXRoIGluZm9ybWF0aW9uIGlzIGNhbGxlZCBmb3I8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyAoZS5nLiwgbG9vcCBkZXRlY3Rp b24sIG9yIHVzZSBvZiBBUyBwYXRoIGxlbmd0aCBpbiBiZXN0IHBhdGg8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBzZWxlY3Rpb24pIHRoZSBleHRl cm5hbGx5IHZpc2libGUgYmVoYXZpb3Igb2YgdGhlIGltcGxlbWVudGF0aW9uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgc2hhbGwgYmUgdGhlIHNh bWUgYXMgaWYgdGhlIGltcGxlbWVudGF0aW9uIGhhZCBydW4gdGhlIGFsZ29yaXRobSBpbjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFNlY3Rpb24g NC40IGFuZCB1c2VkIHRoZSByZXN1bHRpbmcgQVNfUEFUSCBhdHRyaWJ1dGUgYXMgaXQgd291bGQg Zm9yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg YSBub24tQkdQc2VjIHVwZGF0ZSBtZXNzYWdlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij7igKZob3cgc2hvdWxkIGFuIGlCR1Agc3BlYWtlciBwZXJmb3JtIGxvb3AgZGV0ZWN0aW9uIGlm IHRoZXJl4oCZcyBubyBCR1BzZWNfUGF0aCBhdHRyaWJ1dGU/Jm5ic3A7IEluIG90aGVyIHdvcmRz LCB0aGVyZSBpcyBubyBkZWZpbmVkIG1lY2hhbmlzbSB0byBydW4gdGhlIGFsZ29yaXRobSBpbiA0 LjQgd2l0aG91dCBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SeKAmW0gbm90IHN1 Z2dlc3RpbmcgdGhhdCB5b3UgaW5jbHVkZSBhbiBlbXB0eSBhdHRyaWJ1dGUsIGJ1dCB0aGF0IHlv dSBpbmRpY2F0ZSBpbiA0LjQgdGhhdCBubyBCR1BzZWNfUGF0aCBhdHRyaWJ1dGUgaXMgZXF1aXZh bGVudCB0byBhbiBlbXB0eSBBU19QQVRILjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5U aGFua3MhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFsdmFyby48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_67DBF30EB262456887FB96EEF9FB87A9arrcuscom_-- From nobody Wed Jan 11 09:44:56 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0201129437; Wed, 11 Jan 2017 09:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 IotrLpauzum5; Wed, 11 Jan 2017 09:44:48 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0100.outbound.protection.outlook.com [23.103.201.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D387112940F; Wed, 11 Jan 2017 09:44:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wAAAS1bTRYTQCFpC8Z9E0S9LIuZtcWMBaNinXxmqUmM=; b=TEbhVeJ2/QuMf2ALZD5ojvnYq9fXJKi8ZcW142zcw5YTwqTo8O+gFtn7PExhd0FliEhaEioixbtDVbXvYbej8C00KQQFGHe0a4kdg6ZsCrJjr9PeCFTQf0yPEJRbUU+0HCEZtyjJHmRW/OZ4ZlwiOX+f2s75MhlfHPLOvfF9u/s= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0448.namprd09.prod.outlook.com (10.161.252.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Wed, 11 Jan 2017 17:44:47 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0817.020; Wed, 11 Jan 2017 17:44:47 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Alissa Cooper , The IESG Thread-Topic: Alissa Cooper's No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) Thread-Index: AQHSZqaIB6iFlg6ubkuehDw278a786EzlGHg Date: Wed, 11 Jan 2017 17:44:46 +0000 Message-ID: References: <148354685349.12965.6263489032913962215.idtracker@ietfa.amsl.com> In-Reply-To: <148354685349.12965.6263489032913962215.idtracker@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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.122] x-ms-office365-filtering-correlation-id: 00e8ca12-baeb-433f-ed88-08d43a498908 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0448; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0448; 7:bIpfHTRm9UTipW4anzN1JfrOhzXseKEzP2M+ZCN74ty0EnsIRWlacsigm89Z+ym3eAml0cxtjSb5aTy207pMQrqEeUGksqXZkesYJQTPvhAv7a10eDIe6OQ/+CQmqNAY4mcLdP7FQUjeICvtUUvp3CHBJjlcn1CZWr8j8yLwf/qPeXS2JPHfMBVZR4t+NHfEc5EY9PQuvFpzHotiw4jp57NfG6fwkpTpicv56aybgf6vCsZ5+SWCASTLOjW8LF8Av43Xd9wdc+17J8ACC8leMq9RXbWs4u6H0IwIgXotM+IIz9Lwoxt2ehickUKN3Uv4J6xnSWkuzMFshSiSjyUZlMe66KFI6R42Uh+lvE3mdXWcUgnwjn66Yl3xGZjJcAwVWcUQT5aVYBnnOnC26YN4TvRCOxGNgnNAUL+3TMoo9QxgmrteLl+scF5uPhv1UHhsQYtbk6xsnJLj2cRs+gjsbA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:DM2PR09MB0448; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0448; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39860400002)(39840400002)(39410400002)(39850400002)(377454003)(199003)(189002)(81156014)(2906002)(86362001)(3846002)(6116002)(102836003)(81166006)(7736002)(105586002)(305945005)(74316002)(5001770100001)(2900100001)(4326007)(345774005)(7696004)(9686003)(92566002)(54906002)(6306002)(5660300001)(2950100002)(97736004)(8676002)(66066001)(230783001)(54356999)(55016002)(99286003)(3280700002)(38730400001)(33656002)(106116001)(77096006)(50986999)(76176999)(101416001)(229853002)(8936002)(106356001)(189998001)(68736007)(6436002)(25786008)(6506006)(122556002)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0448; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2017 17:44:46.9327 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0448 Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , "sidr-chairs@ietf.org" , Matthias Waehlisch , "sidr@ietf.org" Subject: Re: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 17:44:51 -0000 SGkgQWxpc3NhLA0KDQpTb3JyeSBmb3IgdGhlIGRlbGF5IGluIHJlc3BvbmRpbmcuDQpUaGFuayB5 b3UgZm9yIHlvdXIgY29tbWVudHMuIE15IHJlc3BvbnNlcyBpbmxpbmUgYmVsb3cuDQpJIGhhdmUg YWxyZWFkeSBtYWRlIHRoZSBjaGFuZ2VzIChhcyBub3RlZCBiZWxvdykgDQppbiBteSBlZGl0b3Ig Y29weSBvZiB0aGUgZHJhZnQgdmVyc2lvbi0yMi4NCg0KPkZyb206IEFsaXNzYSBDb29wZXIgW21h aWx0bzphbGlzc2FAY29vcGVydy5pbl0gDQo+U2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDA0LCAy MDE3IDExOjIxIEFNDQrigKYNCj4gLSBGaWcgMjogU2hvdWxkbid0IHRoZSBzaWduYXR1cmVzIGlu IFNpZyBCbG9jayAyIGhhdmUgDQo+ZGlmZmVyZW50IGlkZW50aWZpZXJzIChlLmcuLCBYMiwgWTIp IHRoYW4gdGhvc2UgaW4gU2lnIEJsb2NrIDE/DQoNCkdvb2QgY2F0Y2guIEZpeGVkLg0KDQo+IC0g U2VjIDYuMTogIihsaWtlbHkgYSBzbWFsbCBudW1iZXIgb2YgeWVhcnMpIiAtLSBnaXZlbiBob3cg aGFyZCANCj50aGVzZSB0aGluZ3MgYXJlIHRvIHByZWRpY3QsIGlzIGl0IHdpc2UgdG8gaW5jbHVk ZSB0aGlzIHRleHQgaGVyZT8NCg0KSSBoYXZlIHJlbW92ZWQgdGhlIHBocmFzZSBpbiB0aGUgcGFy ZW50aGVzZXMuDQoNCj4gLSBJIHdhcyBzdXJwcmlzZWQgbm90IHRvIHNlZSBhbiBleGFtcGxlIG1l c3NhZ2Ugb3IgdHdvIGluIHRoaXMgZG9jdW1lbnQuDQoNClNlYW4gaXMgd29ya2luZyB0b2dldGhl ciB3aXRoIE9saXZlciBhbmQgbWUgb24gcHJvdmlkaW5nIA0KZXhhbXBsZSBtZXNzYWdlcyBpbiB0 aGUgZHJhZnQtaWV0Zi1zaWRyLWJncHNlYy1hbGdzLg0KU3RlcGhlbiBhbmQgU2VhbiBhZ3JlZWQg dGhhdCB3b3VsZCBiZSBhIGJldHRlciBwbGFjZSBhbmQgaXQgaXMgaGFwcGVuaW5nOg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaWRyL2N1cnJlbnQvbXNnMDgyODguaHRt bCANCg0KUmVnYXJkcywNClNyaXJhbQ0K From nobody Wed Jan 11 12:17:35 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A653E12954D; Wed, 11 Jan 2017 12:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 rDeSVPJ3izNu; Wed, 11 Jan 2017 12:17:31 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0107.outbound.protection.outlook.com [23.103.200.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F2F128B38; Wed, 11 Jan 2017 12:17:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3W7zK2MsXWZLFbXGbUwPkZtp0VSFBY2sHl6uiYBQX64=; b=jzLijZlI0fruCzWtU76FYqIRp0uKENyWUpsGWd3R6a1pilpQ4DUDS2WVrAPc6irHalFGQKZqKXiS2SGyHo8XDsHt6t7sD5GNbhc4DF9/dVdpQvnIy7LgKWjeC8q4YCV1AiKmat4JI6Xu7d0s/Xhl9099Kwl+JqBk9CAOEVAMV5Q= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0447.namprd09.prod.outlook.com (10.161.252.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Wed, 11 Jan 2017 20:17:29 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0817.020; Wed, 11 Jan 2017 20:17:29 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Alexey Melnikov , sidr wg list , Suresh Krishnan Thread-Topic: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) Thread-Index: AQHSZnD5Ie/2p3jeMkeIgv1icHTisKEpp0IAgAoaqKA= Date: Wed, 11 Jan 2017 20:17:29 +0000 Message-ID: References: <148352385243.12916.15407627777806532255.idtracker@ietfa.amsl.com> <64ABB874-A355-4F91-93D6-6671CB6A354C@sn3rd.com> <309117C0-FA5E-412A-B19B-F2C86B2DA02B@fastmail.fm> In-Reply-To: <309117C0-FA5E-412A-B19B-F2C86B2DA02B@fastmail.fm> 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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.122] x-ms-office365-filtering-correlation-id: c2c20687-99a4-4754-97ab-08d43a5ede4f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0447; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0447; 7:B2RBlAScr4AGzxnmh5RB6M0iPNms2B5UFxLMYY2MTNrzVGssPRmgIsQy2LcQbefITwtOi26EqZq9GiGrAM7Qf+tDS4G2AP9qYde1uc7dwuBJ+DuRN6YRYodyoTEAZPOVujPpqznEkECbxAZWLSbENac6ryRgeVeJNhj1r/W3pB8N/Ju03VvxAIsD/QtwRQ8PlkubyHcD1ciFleED/oJ/QzyrhqkFzFKsxjMw08vmmYtDy+U2abzRP0sf4nG507+14GRMwAvY/Pw81sC2d0QicyV85s9FYxJaj8MvObdTqG2Rmubhx46D52xAXLR5NJdTGzslke/T0EXgy8beB7mqLhOp1zMlmrYFeClqeivwjwL4E+AagTcLxV7DGZhf7na8uHHLrrHEQf0dX+7uwi/Yu+95jQxpNDiuhluoF0o8BFfyuRiAjqq8UtgL3hCyuPevSFrfUas7WGyc7cL0ojFdcg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:DM2PR09MB0447; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0447; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39850400002)(39840400002)(39860400002)(39410400002)(189002)(51444003)(377454003)(24454002)(51914003)(199003)(54906002)(5001770100001)(74316002)(189998001)(97736004)(106356001)(106116001)(7696004)(8936002)(7736002)(5660300001)(92566002)(66066001)(2900100001)(6306002)(9686003)(25786008)(101416001)(76176999)(6436002)(6506006)(54356999)(50986999)(105586002)(305945005)(2950100002)(38730400001)(3846002)(230783001)(81156014)(8666007)(6116002)(93886004)(81166006)(3280700002)(102836003)(99286003)(55016002)(229853002)(2906002)(4326007)(86362001)(3660700001)(33656002)(122556002)(77096006)(8676002)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0447; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2017 20:17:29.4425 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0447 Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , "m.waehlisch@fu-berlin.de" , sidr chairs , The IESG Subject: Re: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:17:33 -0000 Hi Alexey, My comment in line below. >From: Alexey Melnikov [mailto:aamelnikov@fastmail.fm]=20 >Sent: Thursday, January 05, 2017 4:57 AM) >=20 > > On 5 Jan 2017, at 03:19, Suresh Krishnan = wrote: > >=20 > >> On 01/04/2017 09:38 AM, Sean Turner wrote: > >>=20 > >>>> On Jan 4, 2017, at 05:09, Randy Bush wrote: > >>>>=20 > >>>> +1 to the comment from Suresh about order. I though that something=20 > >>>> +like > >>>> what he proposed will minimize memcopies and possibly use of memory= =20 > >>>> why hashing. So I am also curious to know answer to his question. > >>>=20 > >>> a vendor engineer actually implementing requested the change to the=20 > >>> current syntax for ease of generating/parsing. > >>>=20 > >>> randy > >>=20 > >> I believe this is that thread that resulted in the final organization: > >>=20 > >> https://mailarchive.ietf.org/arch/msg/sidr/8B_e4CNxQCUKeZ_AUzsdnn2f5M > >> U > >=20 > > Thanks for the pointer Sean. Very interesting. >=20 > Indeed! I wish a few words about design could be added to the draft. >=20 The design explanation would be a bit long as you can see from=20 Oliver's (implementer's) post. There is a BGPsec design discussion document (to be published as an independent submission RFC): https://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-11 =20 I think that would be better place to include this design rationale as well= . Sriram =20 From nobody Wed Jan 11 14:25:35 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C011295B2; Wed, 11 Jan 2017 14:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=h5Qk4nKl; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Xc6amLoQ 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 jYMIo2GUK7Nz; Wed, 11 Jan 2017 14:25:29 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0217D1295A5; Wed, 11 Jan 2017 14:25:29 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 47EED20B44; Wed, 11 Jan 2017 17:25:28 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 11 Jan 2017 17:25:28 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=SUVhYeb1192TPOC g3gy/am0iesY=; b=h5Qk4nKlQZGVwGxUo0WBqoYxFBoNlSRdL28Tw0gEfi62zme qqWipcxdyuY5eBMHxqwgCGw+zgcBFdBqafLFl03su+kRl0jV/pslYQ/7wMeDm+C5 4YOpPX/Uoo0vg5OxdxCYDjcbrQCXA3BlsBsLOXJgkQtoAvrbMaOxmwtgdBUc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=SUVhYeb1192TPOCg3gy/am0iesY=; b=Xc6amLoQb7N0/XpaNXyj GCoyKbmsOGbx3lriWEF82V/4bFZ+NV4EwbowEX7YT+z1UDz9YflCEr/AowhN39YW pBNvxnPJBFXeO8+CM1i8xmKDdWwKNVAsCCw8o+0sBN0bsCatKZ7z9iP5h0FrKCom RnmAsm4wOk0QxGhiGeeBtHo= X-ME-Sender: X-Sasl-enc: +KZbR0DaEtGKIvxAwXIGidyeRlx1r+IAbQV8n8Y2TXtb 1484173527 Received: from [10.238.179.8] (unknown [185.69.145.100]) by mail.messagingengine.com (Postfix) with ESMTPA id DD4F82471E; Wed, 11 Jan 2017 17:25:27 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Wed, 11 Jan 2017 22:34:48 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148352385243.12916.15407627777806532255.idtracker@ietfa.amsl.com> <64ABB874-A355-4F91-93D6-6671CB6A354C@sn3rd.com> <309117C0-FA5E-412A-B19B-F2C86B2DA02B@fastmail.fm> To: "Sriram, Kotikalapudi (Fed)" Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , "m.waehlisch@fu-berlin.de" , Suresh Krishnan , sidr chairs , The IESG , sidr wg list Subject: Re: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 22:25:31 -0000 Hi Sriram, > On 11 Jan 2017, at 20:17, Sriram, Kotikalapudi (Fed) wrote: >=20 > Hi Alexey, >=20 > My comment in line below. >=20 >> From: Alexey Melnikov [mailto:aamelnikov@fastmail.fm]=20 >> Sent: Thursday, January 05, 2017 4:57 AM) >>=20 >>>> On 5 Jan 2017, at 03:19, Suresh Krishnan = wrote: >>>>=20 >>>> On 01/04/2017 09:38 AM, Sean Turner wrote: >>>>=20 >>>>>> On Jan 4, 2017, at 05:09, Randy Bush wrote: >>>>>>=20 >>>>>> +1 to the comment from Suresh about order. I though that something=20= >>>>>> +like >>>>>> what he proposed will minimize memcopies and possibly use of memory=20= >>>>>> why hashing. So I am also curious to know answer to his question. >>>>>=20 >>>>> a vendor engineer actually implementing requested the change to the=20= >>>>> current syntax for ease of generating/parsing. >>>>>=20 >>>>> randy >>>>=20 >>>> I believe this is that thread that resulted in the final organization: >>>>=20 >>>> https://mailarchive.ietf.org/arch/msg/sidr/8B_e4CNxQCUKeZ_AUzsdnn2f5M >>>> U >>>=20 >>> Thanks for the pointer Sean. Very interesting. >>=20 >> Indeed! I wish a few words about design could be added to the draft. >=20 > The design explanation would be a bit long as you can see from=20 > Oliver's (implementer's) post. > There is a BGPsec design discussion document (to be published > as an independent submission RFC): >=20 > https://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-11 =20 >=20 > I think that would be better place to include this design rationale as wel= l. Works for me. From nobody Wed Jan 11 17:49:44 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975E9129455 for ; Wed, 11 Jan 2017 17:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 zWFz26swdWZJ for ; Wed, 11 Jan 2017 17:49:41 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 E2472129428 for ; Wed, 11 Jan 2017 17:49:40 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id l7so5478848qtd.1 for ; Wed, 11 Jan 2017 17:49:40 -0800 (PST) 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=ihGYVK8gK7e1vK61ys0q09WZeGeIUAH+aeUDYJbmfow=; b=ECpp2X0j7M8slQNeLoo7WE8dxJohnuCHGuZxCKLmSgrmRNdaxizY39rO4Re0iDd3fk 45EfeNfEO+T1UuPtqfcz/6f0YN+SxP2ug5gb94bs2ot38H0WQCwOPOjYn59HheWzFgaT odyfUPi5xqdLpNj1Qqcw0CC1YJcQRdcI78JEk= 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=ihGYVK8gK7e1vK61ys0q09WZeGeIUAH+aeUDYJbmfow=; b=KKvbdsDhPzZyvjNJX1OXeDFDsZ9yT3k/iVrhT7Iug4DSzsnSNc1bTNWsXCx8CXTmvj l+2DPNohdtTfXkvd3+yo6EGTSIAk4oh5mt2fG4vXe1qiaYbtiX3/wtoZNSp/LqkivoOA FoBemr7rXuUCGVawXTb9XoC8puG+THLIh5bZUMrRCJxWFj8EHl9VSS2TFZZl1dKJ6tk7 wsqBC8xd/g+Rth7lVCGhtlSnsoNd+R9Ec3bBoc/ypQnXDe8n2Vv/DwGdMvNK5Mp8umA/ rDxKD7QPpJSLR7p5qyyBO/ch9Ymns70Rxyao7si4PJ4FFXEkTboq6xbWFcRbiMHwnAek bVBg== X-Gm-Message-State: AIkVDXJvKvwSHY8rab2RFT0KC5d9WxMaA49StnrvGvud5gOWaCjEVjF8o7pk68+NbBcFWg== X-Received: by 10.200.45.111 with SMTP id o44mr11580824qta.138.1484185780084; Wed, 11 Jan 2017 17:49:40 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id q3sm5491555qtc.34.2017.01.11.17.49.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 11 Jan 2017 17:49:39 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Wed, 11 Jan 2017 20:49:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7BC9C2B5-E639-4C25-8D1C-BC36322557C4@sn3rd.com> References: <148354685349.12965.6263489032913962215.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , "Sriram, Kotikalapudi \(Fed\)" , "sidr-chairs@ietf.org" , The IESG , "sidr@ietf.org" , Matthias Waehlisch Subject: Re: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 01:49:42 -0000 > On Jan 11, 2017, at 12:44, Sriram, Kotikalapudi (Fed) = wrote: >=20 >> - I was surprised not to see an example message or two in this = document. >=20 > Sean is working together with Oliver and me on providing=20 > example messages in the draft-ietf-sidr-bgpsec-algs. > Stephen and Sean agreed that would be a better place and it is = happening: > https://www.ietf.org/mail-archive/web/sidr/current/msg08288.html=20 Oliver has just posted the v4 examples: https://mailarchive.ietf.org/arch/msg/sidr/eJdWwuwTHT6DVS-MPbMQh8z6iH8 Probably worth adding an explicit pointer to the examples once we get = them agreed by the WG. spt= From nobody Wed Jan 11 19:54:33 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5B2126FDC; Wed, 11 Jan 2017 19:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.356 X-Spam-Level: X-Spam-Status: No, score=-5.356 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.156, 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 LIpxSp8FQRrp; Wed, 11 Jan 2017 19:54:27 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 045DC129406; Wed, 11 Jan 2017 19:54:26 -0800 (PST) X-AuditID: c618062d-ab7ff70000007359-5c-587704679007 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by (Symantec Mail Security) with SMTP id 6B.63.29529.76407785; Thu, 12 Jan 2017 05:22:01 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0319.002; Wed, 11 Jan 2017 22:54:23 -0500 From: Suresh Krishnan To: Alexey Melnikov Thread-Topic: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) Thread-Index: AQHSZnEEWevxNHLRlky3ZRLPIAgPH6Ep+xQAgAobUoCAACZeAIAAWS8A Date: Thu, 12 Jan 2017 03:53:59 +0000 Message-ID: <8C8177C2-1ED6-4BB8-BD5A-F15C8B0559D5@ericsson.com> References: <148352385243.12916.15407627777806532255.idtracker@ietfa.amsl.com> <64ABB874-A355-4F91-93D6-6671CB6A354C@sn3rd.com> <309117C0-FA5E-412A-B19B-F2C86B2DA02B@fastmail.fm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_8C8177C21ED64BB8BD5AF15C8B0559D5ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsUyuXSPt24mS3mEwclzUhb73x9isvgw5Re7 xYw/E5ktJu+5w2rRv/o+q8WVVY3MFt/nX2C1WDbpPKMDh8fOUwfYPPbOb2P3WLLkJ5PHtZN/ WT0OHmQMYI3isklJzcksSy3St0vgyvg95yhbwVb7im/vtrA3ME4272Lk5JAQMJF42fKRqYuR i0NIYD2jxKH5axghnOWMEsdeLGYBqWIDqtqw8zMTiC0ioCNx7PBLsA5mgWNMEp2LbjCCJIQF EiUO3Z8FVZQk8XTZOVYI201i9utlYDUsAqoSrZ1NYDavgL1Ec0sL1OpFzBJfF31nBklwAiUW NW9kB7EZBcQkvp9aAzaUWUBc4taT+UwQdwtILNlznhnCFpV4+fgfK4StJPHx93x2iPpkiWUT f7FALBOUODnzCcsERpFZSEbNQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceQ/VaS6ye3Yai ZgEjxypGjtLigpzcdCODTYzAmD0mwaa7g/H+dM9DjAIcjEo8vAUeZRFCrIllxZW5hxglOJiV RHiP/QYK8aYkVlalFuXHF5XmpBYfYpTmYFES541bfT9cSCA9sSQ1OzW1ILUIJsvEwSnVwDjt 2+1cNcOOyWlHpZqmOXfM7Fr33usm17yNwf8Pcb6+cFK9tG/Bj6yzb2LyZkSd5ZhwpjYlycvA V6ut4Iz/9F+3hY59i88oWsyn+CmcqUpE7s7Jqekqu0SfuR7piVGTabCQuxwWx3O+/PwnFkXJ xQse7d3N8L7V4Psi4T1mhyr5ctsctzs+qlFiKc5INNRiLipOBAB0Ojp21QIAAA== Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , "m.waehlisch@fu-berlin.de" , Kotikalapudi Sriram , sidr chairs , The IESG , sidr wg list Subject: Re: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 03:54:29 -0000 --_000_8C8177C21ED64BB8BD5AF15C8B0559D5ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jan 11, 2017, at 5:34 PM, Alexey Melnikov > wrote: Hi Sriram, On 11 Jan 2017, at 20:17, Sriram, Kotikalapudi (Fed) > wrote: Hi Alexey, My comment in line below. From: Alexey Melnikov [mailto:aamelnikov@fastmail.fm] Sent: Thursday, January 05, 2017 4:57 AM) On 5 Jan 2017, at 03:19, Suresh Krishnan > wrote: On 01/04/2017 09:38 AM, Sean Turner wrote: On Jan 4, 2017, at 05:09, Randy Bush > = wrote: +1 to the comment from Suresh about order. I though that something +like what he proposed will minimize memcopies and possibly use of memory why hashing. So I am also curious to know answer to his question. a vendor engineer actually implementing requested the change to the current syntax for ease of generating/parsing. randy I believe this is that thread that resulted in the final organization: https://mailarchive.ietf.org/arch/msg/sidr/8B_e4CNxQCUKeZ_AUzsdnn2f5M U Thanks for the pointer Sean. Very interesting. Indeed! I wish a few words about design could be added to the draft. The design explanation would be a bit long as you can see from Oliver's (implementer's) post. There is a BGPsec design discussion document (to be published as an independent submission RFC): https://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-11 I think that would be better place to include this design rationale as well= . Works for me. FWIW, Works for me as well. Regards Suresh --_000_8C8177C21ED64BB8BD5AF15C8B0559D5ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <045464FA45258B499BCB432C9BB890B0@ericsson.com> Content-Transfer-Encoding: quoted-printable
On Jan 11, 2017, at 5:34 PM, Alexey Melnikov <aamelnikov@fastmail.fm> w= rote:

Hi Sriram,

On 11 Jan 2017, at 20:17, Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov&g= t; wrote:

Hi Alexey,

My comment in line below.

From: Alexey Melnikov [mailto:aamelnikov@fastmail.fm] 
Sent: Thursday, January 05, 2017 4:57 AM)

On 5 Jan 2017, at 03:19, Suresh Krishn= an <suresh.kr= ishnan@ericsson.com> wrote:

On 01/04/2017 09:38 AM, Sean Turner wrote:

On Jan 4, 2017, at 05:09, Randy Bush &= lt;randy@psg.com> wrote:=

+1 to the comment from Suresh about order. I though that something 
+like
what he proposed will minimize memcopies and possibly use of memory 
why hashing. So I am also curious to know answer to his question.

a vendor engineer actually implementing requested the change to the 
current syntax for ease of generating/parsing.

randy

I believe this is that thread that resulted in the final organization:

https://mailarchive.ietf.org/arch/msg/sidr/8B_e4CNxQCUKeZ= _AUzsdnn2f5M
U

Thanks for the pointer Sean. Very interesting.

Indeed! I wish a few words about design could be added to the draft.

The design explanation would be a bit long as you can see from 
Oliver's (implementer's) post.
There is a BGPsec design discussion document (to be published
as an independent submission RFC):

https://tools.ietf.org/html/draft-sriram-bgpsec-design-choice= s-11  

I think that would be better place to include this design rationale as well= .

Works for me.

FWIW, Works for me as well.

Regards
Suresh

--_000_8C8177C21ED64BB8BD5AF15C8B0559D5ericssoncom_-- From nobody Wed Jan 11 20:17:15 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451AC129412; Wed, 11 Jan 2017 20:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 qGULk1UR2Yts; Wed, 11 Jan 2017 20:17:10 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0093.outbound.protection.outlook.com [23.103.201.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D824B12941E; Wed, 11 Jan 2017 20:17:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Rce9/xPsEIUe2HaZqGleg8DB23x9RYb+ehGG+tjjClI=; b=hEIzyuFUUlnTdMLPlnNItuHG9jvuQ9JVj91SE5xWtWRDjX3qiYqQQ55OQDQMPgbT8XotaTWamRX0eVj89qL5Py9nodmblRL0kgp5jHzfonWbR+wLBXJKrQ4EZKS8D6qGEA9KU9XlCotyMiWHa/1Zp12ODlCNP3Sjo1TvJH6xULA= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0445.namprd09.prod.outlook.com (10.161.252.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Thu, 12 Jan 2017 04:17:07 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0817.020; Thu, 12 Jan 2017 04:17:07 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Suresh Krishnan , Alexey Melnikov Thread-Topic: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) Thread-Index: AQHSZnD5Ie/2p3jeMkeIgv1icHTisKEpp0IAgAoaqKCAACcIAIAAWS6AgAAEFYQ= Date: Thu, 12 Jan 2017 04:17:07 +0000 Message-ID: References: <148352385243.12916.15407627777806532255.idtracker@ietfa.amsl.com> <64ABB874-A355-4F91-93D6-6671CB6A354C@sn3rd.com> <309117C0-FA5E-412A-B19B-F2C86B2DA02B@fastmail.fm> , <8C8177C2-1ED6-4BB8-BD5A-F15C8B0559D5@ericsson.com> In-Reply-To: <8C8177C2-1ED6-4BB8-BD5A-F15C8B0559D5@ericsson.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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.219.101] x-ms-office365-filtering-correlation-id: 9316876e-21fa-4bb5-8570-08d43aa1df10 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0445; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0445; 7:P+W3vc2Yg3gJ9fnu0ea02+NS8hBC3VuaJm2M5TgLaiaXo9v6xwaay5NfKOeOHMOxII5bg9PYF7gZMHyyNTReMBy8FSTkOSMP/q1nybSmbs81AAD5ypOGrZtO+CjLaY/fzJ1PbXV0IXWaVr23RW9Da5hSR3X/JdgB+7MWCLoCNJes/LmcTGCdBmyxn6PKTxYwH2DD88Wv6Ob/RDGtSKn16ZvNSu3DuHWQRXuUljGeoVRa1l0L7p3RUIotaHxxPrGtQb9emFOdu5Tlx5TwZYBRvI3dS+Ajn3I/7ir5D78pP7J9BH32TS2GeJ2lXvzRTdPz6ALLEltOV1E6f/4rdP7OFWZAzbQyBvzmoMAKsDbMdUJN302AQLz/PUTD4CWtEhWNOUOaBE5YKDJ8pTrv5H94dRXJaLGnMbt9cxUdXetSlnY/VHkWEuujK4wtMsBcJWgRTWilukORkp9pM1CXqSJXgg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(65766998875637)(1591387915157); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:DM2PR09MB0445; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0445; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39840400002)(39850400002)(39450400003)(39860400002)(189002)(51914003)(24454002)(51444003)(199003)(377454003)(54906002)(229853002)(86362001)(106116001)(77096006)(7696004)(6306002)(99286003)(101416001)(74316002)(2906002)(106356001)(2950100002)(105586002)(54356999)(3846002)(92566002)(55016002)(9686003)(6506006)(6436002)(6116002)(102836003)(25786008)(2900100001)(38730400001)(4326007)(5660300001)(345774005)(97736004)(68736007)(3280700002)(50986999)(76176999)(3660700001)(189998001)(33656002)(7736002)(122556002)(81156014)(230783001)(8936002)(81166006)(3900700001)(93886004)(5001770100001)(8676002)(8666007)(305945005)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0445; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2017 04:17:07.1149 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0445 Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , sidr chairs , The IESG , sidr wg list , "m.waehlisch@fu-berlin.de" Subject: Re: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 04:17:13 -0000 Hi Suresh, Thank you for this suggestion as well: >* Section 2.1 >The IANA registry at >http://www.iana.org/assignments/address-family-numbers/address-family-numb= ers.xhtml >may be a better reference for AFIs than RFC4760. It has been incorporated in my editor copy of version 22 (to be uploaded in= a couple of days). Sriram=20 ________________________________________ From: Suresh Krishnan Sent: Wednesday, January 11, 2017 10:53 PM To: Alexey Melnikov Cc: Sriram, Kotikalapudi (Fed); sidr wg list; Sean Turner; sidr chairs; dra= ft-ietf-sidr-bgpsec-protocol@ietf.org; The IESG; m.waehlisch@fu-berlin.de Subject: Re: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protoco= l-21: (with COMMENT) On Jan 11, 2017, at 5:34 PM, Alexey Melnikov > wrote: Hi Sriram, On 11 Jan 2017, at 20:17, Sriram, Kotikalapudi (Fed) > wrote: Hi Alexey, My comment in line below. From: Alexey Melnikov [mailto:aamelnikov@fastmail.fm] Sent: Thursday, January 05, 2017 4:57 AM) On 5 Jan 2017, at 03:19, Suresh Krishnan > wrote: On 01/04/2017 09:38 AM, Sean Turner wrote: On Jan 4, 2017, at 05:09, Randy Bush > = wrote: +1 to the comment from Suresh about order. I though that something +like what he proposed will minimize memcopies and possibly use of memory why hashing. So I am also curious to know answer to his question. a vendor engineer actually implementing requested the change to the current syntax for ease of generating/parsing. randy I believe this is that thread that resulted in the final organization: https://mailarchive.ietf.org/arch/msg/sidr/8B_e4CNxQCUKeZ_AUzsdnn2f5M U Thanks for the pointer Sean. Very interesting. Indeed! I wish a few words about design could be added to the draft. The design explanation would be a bit long as you can see from Oliver's (implementer's) post. There is a BGPsec design discussion document (to be published as an independent submission RFC): https://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-11 I think that would be better place to include this design rationale as well= . Works for me. FWIW, Works for me as well. Regards Suresh From nobody Thu Jan 12 05:47:27 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E6F12963F for ; Thu, 12 Jan 2017 05:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 kfE2cW-c8QOq for ; Thu, 12 Jan 2017 05:47:25 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 A9435129633 for ; Thu, 12 Jan 2017 05:47:25 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cRfis-0005SK-Rr; Thu, 12 Jan 2017 13:47:23 +0000 Date: Thu, 12 Jan 2017 22:47:20 +0900 Message-ID: From: Randy Bush To: Oliver Borchert In-Reply-To: <2459DA8D-593F-4B75-9C74-619DDBA907E4@nist.gov> References: <2459DA8D-593F-4B75-9C74-619DDBA907E4@nist.gov> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr list Subject: Re: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 13:47:27 -0000 > Validity > Not Before: Jan 10 19:55:44 2017 GMT > Not After : Oct 25 19:55:44 2290 GMT ok, i blew it and gave no guidance in bgpsec-ops. i guess this doc would be as good a place as any. of course that leaves open what lifetime to recommend. we're not gonna do oscp, but rather withdraw from the rpki. so to keep from making too much bgp noise, let me toss out O(year) to start the discussion. i am still staring at the bgpsec message randy From nobody Thu Jan 12 07:08:37 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124511296FF for ; Thu, 12 Jan 2017 07:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 cf885RP0xNYK for ; Thu, 12 Jan 2017 07:08:33 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0102.outbound.protection.outlook.com [23.103.200.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A0F12943C for ; Thu, 12 Jan 2017 07:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/uj1JEAlBj/lhWBwetcu2dwDcTNY8vfBuA+QwjqWypw=; b=xw7n/WzZ5a7YH2/BfKZn+QCp5fOV4ZGTucB5TwTe4srCJGXTSrAHa5L+F+6naA894+KT0xfgGNIKWuSm7U4GamUw3XHc+6ik75N0nbiOtQKLAP5bhyu/rKsM7R3LhCr2QafuG3TzOCitUI6rfUgBbH9RemY6iBblmm/1DgOMVtQ= Received: from SN1PR09MB1007.namprd09.prod.outlook.com (10.166.69.13) by SN1PR09MB1005.namprd09.prod.outlook.com (10.166.69.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Thu, 12 Jan 2017 15:08:31 +0000 Received: from SN1PR09MB1007.namprd09.prod.outlook.com ([10.166.69.13]) by SN1PR09MB1007.namprd09.prod.outlook.com ([10.166.69.13]) with mapi id 15.01.0845.014; Thu, 12 Jan 2017 15:08:31 +0000 From: "Borchert, Oliver (Fed)" To: Randy Bush Thread-Topic: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs Thread-Index: AQHSbCgbzrHhXkAXSUqZuVZbpiHo6qE03HkA///C4QA= Date: Thu, 12 Jan 2017 15:08:31 +0000 Message-ID: References: <2459DA8D-593F-4B75-9C74-619DDBA907E4@nist.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.140.59] x-ms-office365-filtering-correlation-id: 7e3ac87a-6ef7-4272-1314-08d43afcdf59 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN1PR09MB1005; x-microsoft-exchange-diagnostics: 1; SN1PR09MB1005; 7:zvRBE4f1XIX3wHVI7bqnJv9W8a4cKocGJQSQPMCHHhUZYFIL6g9Gh50NdpL5r8uruAZF+pK7xJ+Yx9Uc1QtbnsMp+5QKSMd3GoQvKXSjoFgrowgGwZwsrfEi51mOQ8uCuUG8sZJ6taolTHMZjpIuL4WPVeF3kDrm+DpxGvBK5kAhB722BO9NXyZrdtsSuezwcy1gocmw/bH+SyH0+G9NGIO3GiVntljSfTPiumzHnuUrwGxQfnH4LutXGd2lE1AKSnEtsB6breRqVa1gF5ttNy5z8cbYToNZEwNwiAEhazJxGhTym/hLrYsVmrQmiX/KZWxuK1uh43t2xnW2gea4ucjddn0iaaYbKNsH9fn6yIbGwADjDR4TPHscdXbzoVuU+3fh+vC/9nIKtl0UCcVvtS5UclAyA5T1g86TmstwAFVZy8IhWeGpTvQY8FsSyelPIm1TfkuZdQPzbbpa+XIlyg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:SN1PR09MB1005; BCL:0; PCL:0; RULEID:; SRVR:SN1PR09MB1005; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(39450400003)(39860400002)(39840400002)(39410400002)(39850400002)(189002)(199003)(377454003)(24454002)(92566002)(106116001)(3280700002)(105586002)(68736007)(106356001)(2906002)(2950100002)(7736002)(6916009)(305945005)(4001350100001)(2900100001)(36756003)(3660700001)(4326007)(110136003)(97736004)(86362001)(33656002)(189998001)(5660300001)(229853002)(38730400001)(6486002)(102836003)(77096006)(6506006)(101416001)(83506001)(81156014)(230783001)(6436002)(3846002)(6512007)(82746002)(6116002)(122556002)(8676002)(76176999)(66066001)(81166006)(25786008)(54356999)(83716003)(99286003)(8936002)(50986999)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR09MB1005; H:SN1PR09MB1007.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <353B5C21E014524B82458391F9D4A81B@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2017 15:08:31.6726 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR09MB1005 Archived-At: Cc: sidr list Subject: Re: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 15:08:36 -0000 SGkgUmFuZHksDQoNClRoZSBpbnRlbnRpb24gZnJvbSBteSBzaWRlIHRvIGhhdmUgdGhlIOKAnDIw MCsgeWVhcnPigJ0gd2FzIGJhc2VkIG9uIG15IHByaXZhdGUgZGlzbGlrZSB0byBzZWUgYW4gZXhh bXBsZSBvbmUgY291bGQgYWN0dWFsbHkgdXNlIGluIFggeWVhcnMgd2hlcmUgWCA+IG5vdygpIGFu ZCB0aGUgY2VydGlmaWNhdGUgd291bGQgYmUgZXhwaXJlZC4gDQpTYWlkIHRoYXQsIHRoaXMgaXMg bXkgcGVyc29uYWwgcHJlZmVyZW5jZSBidXQgSSBnZXQgeW91ciBwb2ludC4gVGhpcyBtb3N0IGxp a2VseSB3b3VsZCBzZXQgYSBiYWQgZXhhbXBsZSBmb3Igb3RoZXJzIHRoYXQgbWlnaHQgc3RhcnQg aXNzdWluZyBjZXJ0aWZpY2F0ZXMgd2l0aCDigJxpbmZpbml0ZeKAnSBsaWZlIHNwYW5zLiANCg0K SW4gdGhpcyByZWdhcmRzIHdoYXQgYWJvdXQgYSBWYWxpZGl0eSBvZiAzNjUgZGF5cyB3aXRoaW4g dGhlIGV4YW1wbGUuIFRoaXMgc2VlbXMgZmVhc2libGUgdG8gbWUuDQoNCk9saXZlcg0KDQpPbiAx LzEyLzE3LCA4OjQ3IEFNLCAiUmFuZHkgQnVzaCIgPHJhbmR5QHBzZy5jb20+IHdyb3RlOg0KDQog ICAgPiAgICAgICAgIFZhbGlkaXR5DQogICAgPiAgICAgICAgICAgICBOb3QgQmVmb3JlOiBKYW4g MTAgMTk6NTU6NDQgMjAxNyBHTVQNCiAgICA+ICAgICAgICAgICAgIE5vdCBBZnRlciA6IE9jdCAy NSAxOTo1NTo0NCAyMjkwIEdNVA0KICAgIA0KICAgIG9rLCBpIGJsZXcgaXQgYW5kIGdhdmUgbm8g Z3VpZGFuY2UgaW4gYmdwc2VjLW9wcy4gIGkgZ3Vlc3MgdGhpcyBkb2MNCiAgICB3b3VsZCBiZSBh cyBnb29kIGEgcGxhY2UgYXMgYW55Lg0KICAgIA0KICAgIG9mIGNvdXJzZSB0aGF0IGxlYXZlcyBv cGVuIHdoYXQgbGlmZXRpbWUgdG8gcmVjb21tZW5kLiAgd2UncmUgbm90IGdvbm5hDQogICAgZG8g b3NjcCwgYnV0IHJhdGhlciB3aXRoZHJhdyBmcm9tIHRoZSBycGtpLiAgc28gdG8ga2VlcCBmcm9t IG1ha2luZyB0b28NCiAgICBtdWNoIGJncCBub2lzZSwgbGV0IG1lIHRvc3Mgb3V0IE8oeWVhcikg dG8gc3RhcnQgdGhlIGRpc2N1c3Npb24uDQogICAgDQogICAgaSBhbSBzdGlsbCBzdGFyaW5nIGF0 IHRoZSBiZ3BzZWMgbWVzc2FnZQ0KICAgIA0KICAgIHJhbmR5DQogICAgDQoNCg== From nobody Thu Jan 12 07:25:54 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6790129878 for ; Thu, 12 Jan 2017 07:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 atignBGpuAIM for ; Thu, 12 Jan 2017 07:25:49 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0103.outbound.protection.outlook.com [23.103.201.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538D0129473 for ; Thu, 12 Jan 2017 07:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=394pXkmzuiZD1t0xia383xDs6RF2saeAg55LDMji2bw=; b=HCU6ustOS4JQVFRszpz9Kauce2ovnbcI1mJIxPyk3RU3t0ryLqJk/J2KIThi4tI5OkmlyG4qfTIqEKTFWVSt1eiNLOu51M0v3MouQhkwTGNk92pcDgKdKjPsfeXOan7V8cdmLY8vETFx8qYdsc2ESMgYNolBLaOd5X53bd+wejI= Received: from SN1PR09MB1007.namprd09.prod.outlook.com (10.166.69.13) by SN1PR09MB1008.namprd09.prod.outlook.com (10.166.69.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Thu, 12 Jan 2017 15:25:47 +0000 Received: from SN1PR09MB1007.namprd09.prod.outlook.com ([10.166.69.13]) by SN1PR09MB1007.namprd09.prod.outlook.com ([10.166.69.13]) with mapi id 15.01.0845.014; Thu, 12 Jan 2017 15:25:47 +0000 From: "Borchert, Oliver (Fed)" To: Randy Bush Thread-Topic: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs Thread-Index: AQHSbCgbzrHhXkAXSUqZuVZbpiHo6qE03HkA///C4QCAAATTAA== Date: Thu, 12 Jan 2017 15:25:47 +0000 Message-ID: <2A4B219C-E98C-410E-A809-AF3CD6A960DD@nist.gov> References: <2459DA8D-593F-4B75-9C74-619DDBA907E4@nist.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.140.59] x-ms-office365-filtering-correlation-id: a5dcde0d-5d74-4572-19e6-08d43aff4882 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN1PR09MB1008; x-microsoft-exchange-diagnostics: 1; SN1PR09MB1008; 7:TcozWBM4fnHGOIK1HTwSk9KQ4y/kJff2O1YJgh5s4IhOYXVRVX33BxcMOlepswZtsOrSMqE0slpu0oyuQHIIgtjIzySGBHYn4oHLwZBqGzSUEtYYN3Q1fLPD7G9/R3Gu2P/zMerMpQzMWbiIhUwzaR8T+hoK8/DOX1scIzeqmoJfq7UcQcD+0ZwkA51kd0IrJVf7TI3TQQDAW2GY4AU+zJLp8WvBcL3njElIFA+FVLnGO8vcycIxsEVgy+2CW3vUqG/7s8QeL/75U4vcIBOldye/eloky37ohSl9/W8Ur6SrGLdXfh9x0hEZnKwhnJWJjxjhIvGcs0dszWOhsxky38wcOrEvOud7vJ583MG6HuW7rh1O0VdjZQDbmjkXngb64QNzgtWVgibObADBWIkOAZUoixZ0HXhic0w2XlPP+gXvW1wFY77XpOXkuJfaETCydCgjRAiAxGUIfGmjT176Ew== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123558021)(20161123562025)(6072148); SRVR:SN1PR09MB1008; BCL:0; PCL:0; RULEID:; SRVR:SN1PR09MB1008; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39860400002)(39450400003)(39840400002)(189002)(377454003)(24454002)(199003)(3660700001)(101416001)(106356001)(6436002)(229853002)(38730400001)(99286003)(6506006)(106116001)(4001350100001)(77096006)(25786008)(97736004)(86362001)(6486002)(5890100001)(189998001)(50986999)(99936001)(76176999)(54356999)(36756003)(2900100001)(102836003)(2906002)(6512007)(4326007)(81156014)(6306002)(305945005)(105586002)(8676002)(81166006)(3280700002)(6116002)(66066001)(7736002)(68736007)(122556002)(8936002)(5660300001)(230783001)(2950100002)(6916009)(3846002)(92566002)(83506001)(82746002)(83716003)(33656002)(110136003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR09MB1008; H:SN1PR09MB1007.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_2A4B219CE98C410EA809AF3CD6A960DDnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2017 15:25:47.1408 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR09MB1008 Archived-At: Cc: sidr list Subject: Re: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 15:25:53 -0000 --_002_2A4B219CE98C410EA809AF3CD6A960DDnistgov_ Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 SSB3ZW50IGFoZWFkIGFuZCB1cGRhdGVkIHRoZSBsaWZlIHNwYW4gb2YgdGhlIGNlcnRpZmljYXRl cyBpbiB0aGUgZXhhbXBsZS4NCmF0dGFjaGVkIHBsZWFzZSBmaW5kIHRoZSB1cGRhdGVkIHZlcnNp b24gd2l0aCBhIGNlcnRpZmljYXRlIHZhbGlkaXR5IG9mIDM2NSBkYXlzDQoNCk9saXZlcg0KDQoN Ck9uIDEvMTIvMTcsIDEwOjA4IEFNLCAic2lkciBvbiBiZWhhbGYgb2YgQm9yY2hlcnQsIE9saXZl ciAoRmVkKSIgPHNpZHItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygb2xpdmVyLmJvcmNo ZXJ0QG5pc3QuZ292PiB3cm90ZToNCg0KICAgIEhpIFJhbmR5LA0KICAgIA0KICAgIFRoZSBpbnRl bnRpb24gZnJvbSBteSBzaWRlIHRvIGhhdmUgdGhlIOKAnDIwMCsgeWVhcnPigJ0gd2FzIGJhc2Vk IG9uIG15IHByaXZhdGUgZGlzbGlrZSB0byBzZWUgYW4gZXhhbXBsZSBvbmUgY291bGQgYWN0dWFs bHkgdXNlIGluIFggeWVhcnMgd2hlcmUgWCA+IG5vdygpIGFuZCB0aGUgY2VydGlmaWNhdGUgd291 bGQgYmUgZXhwaXJlZC4gDQogICAgU2FpZCB0aGF0LCB0aGlzIGlzIG15IHBlcnNvbmFsIHByZWZl cmVuY2UgYnV0IEkgZ2V0IHlvdXIgcG9pbnQuIFRoaXMgbW9zdCBsaWtlbHkgd291bGQgc2V0IGEg YmFkIGV4YW1wbGUgZm9yIG90aGVycyB0aGF0IG1pZ2h0IHN0YXJ0IGlzc3VpbmcgY2VydGlmaWNh dGVzIHdpdGgg4oCcaW5maW5pdGXigJ0gbGlmZSBzcGFucy4gDQogICAgDQogICAgSW4gdGhpcyBy ZWdhcmRzIHdoYXQgYWJvdXQgYSBWYWxpZGl0eSBvZiAzNjUgZGF5cyB3aXRoaW4gdGhlIGV4YW1w bGUuIFRoaXMgc2VlbXMgZmVhc2libGUgdG8gbWUuDQogICAgDQogICAgT2xpdmVyDQogICAgDQog ICAgT24gMS8xMi8xNywgODo0NyBBTSwgIlJhbmR5IEJ1c2giIDxyYW5keUBwc2cuY29tPiB3cm90 ZToNCiAgICANCiAgICAgICAgPiAgICAgICAgIFZhbGlkaXR5DQogICAgICAgID4gICAgICAgICAg ICAgTm90IEJlZm9yZTogSmFuIDEwIDE5OjU1OjQ0IDIwMTcgR01UDQogICAgICAgID4gICAgICAg ICAgICAgTm90IEFmdGVyIDogT2N0IDI1IDE5OjU1OjQ0IDIyOTAgR01UDQogICAgICAgIA0KICAg ICAgICBvaywgaSBibGV3IGl0IGFuZCBnYXZlIG5vIGd1aWRhbmNlIGluIGJncHNlYy1vcHMuICBp IGd1ZXNzIHRoaXMgZG9jDQogICAgICAgIHdvdWxkIGJlIGFzIGdvb2QgYSBwbGFjZSBhcyBhbnku DQogICAgICAgIA0KICAgICAgICBvZiBjb3Vyc2UgdGhhdCBsZWF2ZXMgb3BlbiB3aGF0IGxpZmV0 aW1lIHRvIHJlY29tbWVuZC4gIHdlJ3JlIG5vdCBnb25uYQ0KICAgICAgICBkbyBvc2NwLCBidXQg cmF0aGVyIHdpdGhkcmF3IGZyb20gdGhlIHJwa2kuICBzbyB0byBrZWVwIGZyb20gbWFraW5nIHRv bw0KICAgICAgICBtdWNoIGJncCBub2lzZSwgbGV0IG1lIHRvc3Mgb3V0IE8oeWVhcikgdG8gc3Rh cnQgdGhlIGRpc2N1c3Npb24uDQogICAgICAgIA0KICAgICAgICBpIGFtIHN0aWxsIHN0YXJpbmcg YXQgdGhlIGJncHNlYyBtZXNzYWdlDQogICAgICAgIA0KICAgICAgICByYW5keQ0KICAgICAgICAN CiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KICAgIHNpZHIgbWFpbGluZyBsaXN0DQogICAgc2lkckBpZXRmLm9yZw0KICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkcg0KICAgIA0KDQo= --_002_2A4B219CE98C410EA809AF3CD6A960DDnistgov_ Content-Type: text/plain; name="draft-ietf-sidr-bgpsec-algs-examples_v2.txt" Content-Description: draft-ietf-sidr-bgpsec-algs-examples_v2.txt Content-Disposition: attachment; filename="draft-ietf-sidr-bgpsec-algs-examples_v2.txt"; size=9895; creation-date="Thu, 12 Jan 2017 15:25:46 GMT"; modification-date="Thu, 12 Jan 2017 15:25:46 GMT" Content-ID: Content-Transfer-Encoding: base64 77u/VG9wb2xvZ3k6CgpBUyg2NDQ5NiktLS0tQVMoNjU1MzYpLS0tLUFTKDY1NTM3KQoKUHJlZml4 IEFubm91bmNlbWVudDogQVMoNjQ0OTYpLCAxOTIuMC4yLjAvMjQKCkZvciB0aGlzIGV4YW1wbGUg dGhlIEVDRFNBIGFsZ29yaXRobSB3YXMgcHJvdmlkZWQgd2l0aCBhIHN0YXRpYyBrIHRvIAptYWtl IHRoZSByZXN1bHQgZGV0ZXJtaW5pc3RpYy4gClRoZSBrIHVzZWQgZm9yIGFsbCBzaWduYXR1cmUg b3BlcmF0aW9ucyB3YXMgdGFrZW4gZnJvbSBSRkMgNjk3OSwgCmNoYXB0ZXIgQS4yLjUg4oCcU2ln bmF0dXJlcyBXaXRoIFNIQS0yNTYsIG1lc3NhZ2UgJ3NhbXBsZSfigJ0uCgogIGsgPSBBNkUzQzU3 REQwMUFCRTkwMDg2NTM4Mzk4MzU1REQ0QzNCMTdBQTg3MzM4MkIwRjI0RDYxMjk0OTNEOEFBRDYw CgpLZXlzIG9mIEFTNjQ0OTY6Cj09PT09PT09PT09PT09PT0Kc2tpOiBBQjREOTEwRjU1Q0FFNzFB MjE1RUYzQ0FGRTNBQ0M0NUI1RUVDMTU0Cgpwcml2YXRlIGtleToKICB4ID0gRDhBQTRERkJFMjQ3 OEY4NkU4OEE3NDUxQkYwNzU1NjU3MDlDNTc1QUMxQzEzNkQwODFDNTQwMjU0Q0E0NDBCOQoKcHVi bGljIGtleTogCiAgVXggPSA3MzkxQkFCQjkyQTBDQjNCRTEwRTU5QjE5RUJGRkIyMTRFMDRBOTFF MENCQTFCMTM5QTdEMzhEOTBGNzdFNTVBCiAgVXkgPSBBMDVCOEU2OTU2NzhFMEZBMTY5MDRCNTVE OUQ0RjVDMERGQzU4ODk1RUU1MEJDNEY3NUQyMDVBMjVCRDM2RkY1CgpSb3V0ZXIgS2V5IENlcnRp ZmljYXRlIGV4YW1wbGUgdXNpbmcgT3BlblNTTCAxLjAuMWUtZmlwcyAxMSBGZWIgMjAxMwotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQpDZXJ0aWZpY2F0ZToKICAgIERhdGE6CiAgICAgICAgVmVyc2lvbjogMyAoMHgyKQog ICAgICAgIFNlcmlhbCBOdW1iZXI6IDMyNTU1MzgzODMgKDB4YzIwYjkyY2YpCiAgICBTaWduYXR1 cmUgQWxnb3JpdGhtOiBlY2RzYS13aXRoLVNIQTI1NgogICAgICAgIElzc3VlcjogQ049Uk9VVEVS LTAwMDBGQkYwCiAgICAgICAgVmFsaWRpdHkKICAgICAgICAgICAgTm90IEJlZm9yZTogSmFuIDEy IDE1OjE3OjEyIDIwMTcgR01UCiAgICAgICAgICAgIE5vdCBBZnRlciA6IEphbiAxMiAxNToxNzox MiAyMDE4IEdNVAogICAgICAgIFN1YmplY3Q6IENOPVJPVVRFUi0wMDAwRkJGMAogICAgICAgIFN1 YmplY3QgUHVibGljIEtleSBJbmZvOgogICAgICAgICAgICBQdWJsaWMgS2V5IEFsZ29yaXRobTog aWQtZWNQdWJsaWNLZXkKICAgICAgICAgICAgICAgIFB1YmxpYy1LZXk6ICgyNTYgYml0KQogICAg ICAgICAgICAgICAgcHViOiAKICAgICAgICAgICAgICAgICAgICAwNDo3Mzo5MTpiYTpiYjo5Mjph MDpjYjozYjplMTowZTo1OTpiMTo5ZTpiZjoKICAgICAgICAgICAgICAgICAgICBmYjoyMTo0ZTow NDphOToxZTowYzpiYToxYjoxMzo5YTo3ZDozODpkOTowZjoKICAgICAgICAgICAgICAgICAgICA3 NzplNTo1YTphMDo1Yjo4ZTo2OTo1Njo3ODplMDpmYToxNjo5MDo0Yjo1NToKICAgICAgICAgICAg ICAgICAgICBkOTpkNDpmNTpjMDpkZjpjNTo4ODo5NTplZTo1MDpiYzo0Zjo3NTpkMjowNToKICAg ICAgICAgICAgICAgICAgICBhMjo1YjpkMzo2ZjpmNQogICAgICAgICAgICAgICAgQVNOMSBPSUQ6 IHByaW1lMjU2djEKICAgICAgICBYNTA5djMgZXh0ZW5zaW9uczoKICAgICAgICAgICAgWDUwOXYz IEtleSBVc2FnZTogCiAgICAgICAgICAgICAgICBEaWdpdGFsIFNpZ25hdHVyZQogICAgICAgICAg ICBYNTA5djMgU3ViamVjdCBLZXkgSWRlbnRpZmllcjogCiAgICAgICAgICAgICAgICBBQjo0RDo5 MTowRjo1NTpDQTpFNzoxQToyMTo1RTpGMzpDQTpGRTozQTpDQzo0NTpCNTpFRTpDMTo1NAogICAg ICAgICAgICBYNTA5djMgRXh0ZW5kZWQgS2V5IFVzYWdlOiAKICAgICAgICAgICAgICAgIDEuMy42 LjEuNS41LjcuMy4zMAogICAgICAgICAgICBzYmdwLWF1dG9ub21vdXNTeXNOdW06IGNyaXRpY2Fs CiAgICAgICAgICAgICAgICBBdXRvbm9tb3VzIFN5c3RlbSBOdW1iZXJzOgogICAgICAgICAgICAg ICAgICA2NDQ5NgogICAgICAgICAgICAgICAgUm91dGluZyBEb21haW4gSWRlbnRpZmllcnM6CiAg ICAgICAgICAgICAgICAgIGluaGVyaXQKCiAgICBTaWduYXR1cmUgQWxnb3JpdGhtOiBlY2RzYS13 aXRoLVNIQTI1NgogICAgICAgICAzMDo0NDowMjoyMDo2Yzo5NDpiYjozMjoyMjozYzpjNzphZTpl ODplMzpmZDpkNTo3NTpjMjoKICAgICAgICAgNzQ6Mjc6ZmE6YmU6YzM6YWQ6YmE6ZGQ6M2U6NGE6 MzQ6YTM6YzQ6Yjc6ODk6NjU6MzA6NjQ6CiAgICAgICAgIDAyOjIwOjJkOjgyOjE3OmY0OjExOjk3 OjkyOmRmOmZjOjkyOmJlOmJlOmM2OjUzOmJiOjQ0OgogICAgICAgICAyZDozNjo4MzpkNjowYzo5 NToyOTo0Nzo4MDo4NTpiYzo4NDozMjo5MjpmNzoyMgotLS0tLUJFR0lOIENFUlRJRklDQVRFLS0t LS0KTUlJQmlUQ0NBVENnQXdJQkFnSUZBTUlMa3M4d0NnWUlLb1pJemowRUF3SXdHakVZTUJZR0Ex VUVBd3dQVWs5VgpWRVZTTFRBd01EQkdRa1l3TUI0WERURTNNREV4TWpFMU1UY3hNbG9YRFRFNE1E RXhNakUxTVRjeE1sb3dHakVZCk1CWUdBMVVFQXd3UFVrOVZWRVZTTFRBd01EQkdRa1l3TUZrd0V3 WUhLb1pJemowQ0FRWUlLb1pJemowREFRY0QKUWdBRWM1RzZ1NUtneXp2aERsbXhuci83SVU0RXFS NE11aHNUbW4wNDJROTM1VnFnVzQ1cFZuamcraGFRUzFYWgoxUFhBMzhXSWxlNVF2RTkxMGdXaVc5 TnY5YU5qTUdFd0N3WURWUjBQQkFRREFnZUFNQjBHQTFVZERnUVdCQlNyClRaRVBWY3JuR2lGZTg4 citPc3hGdGU3QlZEQVRCZ05WSFNVRUREQUtCZ2dyQmdFRkJRY0RIakFlQmdnckJnRUYKQlFjQkNB RUIvd1FQTUEyZ0J6QUZBZ01BKy9DaEFnVUFNQW9HQ0NxR1NNNDlCQU1DQTBjQU1FUUNJR3lVdXpJ aQpQTWV1Nk9QOTFYWENkQ2Y2dnNPdHV0MCtTalNqeExlSlpUQmtBaUF0Z2hmMEVaZVMzL3lTdnI3 R1U3dEVMVGFECjFneVZLVWVBaGJ5RU1wTDNJZz09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K CgoKS2V5cyBvZiBBUyg2NTYzNik6Cj09PT09PT09PT09PT09PT09PQpza2k6IDQ3RjIzQkYxQUIy RjhBOUQyNjg2NEVCQkQ4REYyNzExQzc0NDA2RUMKCnByaXZhdGUga2V5OgogIHggPSA2Q0IyRTkz MUIxMTJGMjQ1NTRCQ0RDQUFGRDk1NTNBOTUxOUE5QUYzM0MwMjNCNjA4NDZBMjFGQzk1NTgzMTcy CgpwdWJsaWMga2V5OiAKICBVeCA9IDI4RkM1RkU5QUZDRjVGNENBQjNGNUY4NUNCMjEyRkMxRTlE MEUwREJFQUVFNDI1QkQyRjBEMzE3NUFBMEU5ODkKICBVeSA9IEVBOUI2MDNFMzhGMzVGQjMyOURG NDk1NjQxRjJCQTA0MEYxQzNBQzYxMzgzMDdGMjU3Q0JBNkI4QjU4OEY0MUYKClJvdXRlciBLZXkg Q2VydGlmaWNhdGUgZXhhbXBsZSB1c2luZyBPcGVuU1NMIDEuMC4xZS1maXBzIDExIEZlYiAyMDEz Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCkNlcnRpZmljYXRlOgogICAgRGF0YToKICAgICAgICBWZXJzaW9uOiAzICgw eDIpCiAgICAgICAgU2VyaWFsIE51bWJlcjogMzQzNzQ2ODE0MiAoMHhjY2UzOTllZSkKICAgIFNp Z25hdHVyZSBBbGdvcml0aG06IGVjZHNhLXdpdGgtU0hBMjU2CiAgICAgICAgSXNzdWVyOiBDTj1S T1VURVItMDAwMTAwMDAKICAgICAgICBWYWxpZGl0eQogICAgICAgICAgICBOb3QgQmVmb3JlOiBK YW4gMTIgMTU6MTc6MzQgMjAxNyBHTVQKICAgICAgICAgICAgTm90IEFmdGVyIDogSmFuIDEyIDE1 OjE3OjM0IDIwMTggR01UCiAgICAgICAgU3ViamVjdDogQ049Uk9VVEVSLTAwMDEwMDAwCiAgICAg ICAgU3ViamVjdCBQdWJsaWMgS2V5IEluZm86CiAgICAgICAgICAgIFB1YmxpYyBLZXkgQWxnb3Jp dGhtOiBpZC1lY1B1YmxpY0tleQogICAgICAgICAgICAgICAgUHVibGljLUtleTogKDI1NiBiaXQp CiAgICAgICAgICAgICAgICBwdWI6IAogICAgICAgICAgICAgICAgICAgIDA0OjI4OmZjOjVmOmU5 OmFmOmNmOjVmOjRjOmFiOjNmOjVmOjg1OmNiOjIxOgogICAgICAgICAgICAgICAgICAgIDJmOmMx OmU5OmQwOmUwOmRiOmVhOmVlOjQyOjViOmQyOmYwOmQzOjE3OjVhOgogICAgICAgICAgICAgICAg ICAgIGEwOmU5Ojg5OmVhOjliOjYwOjNlOjM4OmYzOjVmOmIzOjI5OmRmOjQ5OjU2OgogICAgICAg ICAgICAgICAgICAgIDQxOmYyOmJhOjA0OjBmOjFjOjNhOmM2OjEzOjgzOjA3OmYyOjU3OmNiOmE2 OgogICAgICAgICAgICAgICAgICAgIGI4OmI1Ojg4OmY0OjFmCiAgICAgICAgICAgICAgICBBU04x IE9JRDogcHJpbWUyNTZ2MQogICAgICAgIFg1MDl2MyBleHRlbnNpb25zOgogICAgICAgICAgICBY NTA5djMgS2V5IFVzYWdlOiAKICAgICAgICAgICAgICAgIERpZ2l0YWwgU2lnbmF0dXJlCiAgICAg ICAgICAgIFg1MDl2MyBTdWJqZWN0IEtleSBJZGVudGlmaWVyOiAKICAgICAgICAgICAgICAgIDQ3 OkYyOjNCOkYxOkFCOjJGOjhBOjlEOjI2Ojg2OjRFOkJCOkQ4OkRGOjI3OjExOkM3OjQ0OjA2OkVD CiAgICAgICAgICAgIFg1MDl2MyBFeHRlbmRlZCBLZXkgVXNhZ2U6IAogICAgICAgICAgICAgICAg MS4zLjYuMS41LjUuNy4zLjMwCiAgICAgICAgICAgIHNiZ3AtYXV0b25vbW91c1N5c051bTogY3Jp dGljYWwKICAgICAgICAgICAgICAgIEF1dG9ub21vdXMgU3lzdGVtIE51bWJlcnM6CiAgICAgICAg ICAgICAgICAgIDY1NTM2CiAgICAgICAgICAgICAgICBSb3V0aW5nIERvbWFpbiBJZGVudGlmaWVy czoKICAgICAgICAgICAgICAgICAgaW5oZXJpdAoKICAgIFNpZ25hdHVyZSBBbGdvcml0aG06IGVj ZHNhLXdpdGgtU0hBMjU2CiAgICAgICAgIDMwOjQ2OjAyOjIxOjAwOmI1OjhhOmU2OmJhOjI2OjIy OjUwOjA1OjI1OjZlOjczOjgzOmZhOgogICAgICAgICBmMDo4NToyOTo2MjozMzpjZjo5YjphMjpj MDo3NzplMzo4NzplODo2NTpiMjo5ZjpiYToyZToKICAgICAgICAgMmU6MDI6MjE6MDA6ZTk6NDM6 ZmM6MmQ6OWI6YmI6NjY6ZjM6MDE6NGQ6ZDM6NDM6Mjg6YTg6CiAgICAgICAgIGVhOjBmOjIxOjky OjViOmRlOmM2OmRiOmI2OjcwOjQ0OmY5OmI5OmE0OjQ4OjkyOmY4OjA4Ci0tLS0tQkVHSU4gQ0VS VElGSUNBVEUtLS0tLQpNSUlCaXpDQ0FUQ2dBd0lCQWdJRkFNemptZTR3Q2dZSUtvWkl6ajBFQXdJ d0dqRVlNQllHQTFVRUF3d1BVazlWClZFVlNMVEF3TURFd01EQXdNQjRYRFRFM01ERXhNakUxTVRj ek5Gb1hEVEU0TURFeE1qRTFNVGN6TkZvd0dqRVkKTUJZR0ExVUVBd3dQVWs5VlZFVlNMVEF3TURF d01EQXdNRmt3RXdZSEtvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRApRZ0FFS1B4ZjZhL1BYMHlyUDEr Rnl5RXZ3ZW5RNE52cTdrSmIwdkRURjFxZzZZbnFtMkErT1BOZnN5bmZTVlpCCjhyb0VEeHc2eGhP REIvSlh5NmE0dFlqMEg2TmpNR0V3Q3dZRFZSMFBCQVFEQWdlQU1CMEdBMVVkRGdRV0JCUkgKOGp2 eHF5K0tuU2FHVHJ2WTN5Y1J4MFFHN0RBVEJnTlZIU1VFRERBS0JnZ3JCZ0VGQlFjREhqQWVCZ2dy QmdFRgpCUWNCQ0FFQi93UVBNQTJnQnpBRkFnTUJBQUNoQWdVQU1Bb0dDQ3FHU000OUJBTUNBMGtB TUVZQ0lRQzFpdWE2CkppSlFCU1Z1YzRQNjhJVXBZalBQbTZMQWQrT0g2R1d5bjdvdUxnSWhBT2xE L0MyYnUyYnpBVTNUUXlpbzZnOGgKa2x2ZXh0dTJjRVQ1dWFSSWt2Z0kKLS0tLS1FTkQgQ0VSVElG SUNBVEUtLS0tLQoKCkJHUFNlYyBVcGRhdGUgZnJvbSBBUyg2NTUzNikgdG8gQVMoNjU1MzcpOgo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CkJpbmFyeSBGb3JtIG9m IEJHUFNlYyBVcGRhdGUgKFRDUC1EVU1QKToKRkYgRkYgRkYgRkYgRkYgRkYgRkYgRkYgIEZGIEZG IEZGIEZGIEZGIEZGIEZGIEZGCjAxIDAwIDAyIDAwIDAwIDAwIEU5IDQwICAwMSAwMSAwMiA4MCAw NCAwNCAwMCAwMAowMCAwMCA4MCAwRSAwRCAwMCAwMSAwMSAgMDQgQzYgMzMgNjQgNjQgMDAgMTgg QzAKMDAgMDIgOTAgMUUgMDAgQ0EgMDAgMEUgIDAxIDAwIDAwIDAxIDAwIDAwIDAxIDAwCjAwIDAw IEZCIEYwIDAwIEJDIDAxIDQ3ICBGMiAzQiBGMSBBQiAyRiA4QSA5RCAyNgo4NiA0RSBCQiBEOCBE RiAyNyAxMSBDNyAgNDQgMDYgRUMgMDAgNDYgMzAgNDQgMDIKMjAgNzIgMTQgQkMgOTYgNDcgMTYg MEIgIEJEIDM5IEZGIDJGIDgwIDUzIDNGIDVECkM2IEREIEQ3IDBEIERGIDg2IEJCIDgxICA1NiA2 MSBFOCAwNSBENSBENCBFNiBGMgo3QyAwMiAyMCAyRCBEQyAwMCAzQyA2NCAgQkUgN0IgMjkgQzkg RUIgREIgQzggQTQKOTcgRUQgNjYgMjggNUUgRTkgMjIgNzYgIDgzIEU2IEMxIDc4IENFIDhEIEU2 IEQzCjU5IDVGIDQxIEFCIDREIDkxIDBGIDU1ICBDQSBFNyAxQSAyMSA1RSBGMyBDQSBGRQozQSBD QyA0NSBCNSBFRSBDMSA1NCAwMCAgNDcgMzAgNDUgMDIgMjAgNzIgMTQgQkMKOTYgNDcgMTYgMEIg QkQgMzkgRkYgMkYgIDgwIDUzIDNGIDVEIEM2IEREIEQ3IDBECkRGIDg2IEJCIDgxIDU2IDYxIEU4 IDA1ICBENSBENCBFNiBGMiA3QyAwMiAyMSAwMApDNiAxNyAxOSAzNCAwNyA0MyAwNiAzQiAgOEEg NUMgQ0QgNTQgMTYgMzkgMEIgMzEKMjEgMUQgM0MgNTIgNDggMDcgOTUgODcgIEQwIDEzIDEzIDdC IDQxIENEIDIzIEUyCgoKU2lnbmF0dXJlIEZyb20gQVMoNjQ0OTYpIHRvIEFTKDY1NTM2KToKLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCkRpZ2VzdDogICAgMjEgMzMgRTUg Q0EgQTAgMjYgQkUgMDcgICAzRCA5QyAxQiA0RSBGRSBCOSBCOSA3NyAKICAgICAgICAgICA5RiAy MCBGOCBGNSBERSAyOSBGQSA5OCAgIDQwIDAwIDlGIDYwIApTaWduYXR1cmU6IDMwIDQ1IDAyIDIw IDcyIDE0IEJDIDk2ICAgNDcgMTYgMEIgQkQgMzkgRkYgMkYgODAgCiAgICAgICAgICAgNTMgM0Yg NUQgQzYgREQgRDcgMEQgREYgICA4NiBCQiA4MSA1NiA2MSBFOCAwNSBENSAKICAgICAgICAgICBE NCBFNiBGMiA3QyAwMiAyMSAwMCBDNiAgIDE3IDE5IDM0IDA3IDQzIDA2IDNCIDhBIAogICAgICAg ICAgIDVDIENEIDU0IDE2IDM5IDBCIDMxIDIxICAgMUQgM0MgNTIgNDggMDcgOTUgODcgRDAgCiAg ICAgICAgICAgMTMgMTMgN0IgNDEgQ0QgMjMgRTIgCgpTaWduYXR1cmUgRnJvbSBBUyg2NTUzNikg dG8gQVMoNjU1MzcpOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpEaWdl c3Q6ICAgIDQ2IDRCIDU3IENFIEIxIDJEIDE4IEIwICAgRkQgMUEgMUEgMzUgOTQgMTcgM0EgNEEg CiAgICAgICAgICAgMDkgODggRTUgRjQgRUQgRUQgMkYgM0QgICA4MyAwOCA1QSBBOCAKU2lnbmF0 dXJlOiAzMCA0NCAwMiAyMCA3MiAxNCBCQyA5NiAgIDQ3IDE2IDBCIEJEIDM5IEZGIDJGIDgwIAog ICAgICAgICAgIDUzIDNGIDVEIEM2IEREIEQ3IDBEIERGICAgODYgQkIgODEgNTYgNjEgRTggMDUg RDUgCiAgICAgICAgICAgRDQgRTYgRjIgN0MgMDIgMjAgMkQgREMgICAwMCAzQyA2NCBCRSA3QiAy OSBDOSBFQiAKICAgICAgICAgICBEQiBDOCBBNCA5NyBFRCA2NiAyOCA1RSAgIEU5IDIyIDc2IDgz IEU2IEMxIDc4IENFIAogICAgICAgICAgIDhEIEU2IEQzIDU5IDVGIDQxIAoKClRoZSBodW1hbiBy ZWFkYWJsZSBvdXRwdXQgaXMgcHJvZHVjZWQgdXNpbmcgYmdwc2VjLWlvLCBhIGJncHNlYyAKdHJh ZmZpYyBnZW5lcmF0b3IgdGhhdCB1c2VzIGEgd2lyZXNoYXJrIGxpa2UgcHJpbnRvdXQuCgpTZW5k IFVwZGF0ZSBNZXNzYWdlCistLW1hcmtlcjogRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYKKy0tbGVuZ3RoOiAyNTYKKy0tdHlwZTogICAyIChVUERBVEUpCistLXdpdGhkcmF3bl9yb3V0 ZXNfbGVuZ3RoOiAwCistLXRvdGFsX3BhdGhfYXR0cl9sZW5ndGg6IDIzMwogICArLS1PUklHSU46 IElOQ09NUExFVEUgKDQgYnl0ZXMpCiAgIHwgICstLUZsYWdzOiAweDQwIChXZWxsLUtub3duLCBU cmFuc2l0aXZlLCBDb21wbGV0ZSkKICAgfCAgKy0tVHlwZSBDb2RlOiBPUklHSU4gKDEpCiAgIHwg ICstLUxlbmd0aDogMSBieXRlCiAgIHwgICstLU9yaWdpbjogSU5DT01QTEVURSAoMSkKICAgKy0t TVVMVElfRVhJVF9ESVNDICg3IGJ5dGVzKQogICB8ICArLS1GbGFnczogMHg4MCAoT3B0aW9uYWws IENvbXBsZXRlKQogICB8ICArLS1UeXBlIENvZGU6IE1VTFRJX0VYSVRfRElTQyAoNCkKICAgfCAg Ky0tTGVuZ3RoOiA0IGJ5dGVzCiAgIHwgICstLWRhdGE6IDAwIDAwIDAwIDAwIAogICArLS1NUF9S RUFDSF9OTFJJICgxNiBieXRlcykKICAgfCAgKy0tRmxhZ3M6IDB4ODAgKE9wdGlvbmFsLCBDb21w bGV0ZSkKICAgfCAgKy0tVHlwZSBDb2RlOiBNUF9SRUFDSF9OTFJJICgxNCkKICAgfCAgKy0tTGVu Z3RoOiAxMyBieXRlcwogICB8ICArLS1kYXRhOiAwMCAwMSAwMSAwNCBDNiAzMyA2NCA2NCAgIDAw IDE4IEMwIDAwIDAyIAogICArLS1CR1BTRUMgUGF0aCBBdHRyaWJ1dGUgKDIwNiBieXRlcykKICAg ICAgKy0tRmxhZ3M6IDB4OTAgKE9wdGlvbmFsLCBDb21wbGV0ZSwgRXh0ZW5kZWQgTGVuZ3RoKQog ICAgICArLS1UeXBlIENvZGU6IEJHUFNFQyBQYXRoIEF0dHJpYnV0ZSAoMzApCiAgICAgICstLUxl bmd0aDogMjAyIGJ5dGVzCiAgICAgICstLVNlY3VyZSBQYXRoICgxNCBieXRlcykKICAgICAgfCAg Ky0tTGVuZ3RoOiAxNCBieXRlcwogICAgICB8ICArLS1TZWN1cmUgUGF0aCBTZWdtZW50OiAoNiBi eXRlcykKICAgICAgfCAgfCAgKy0tcENvdW50OiAxCiAgICAgIHwgIHwgICstLUZsYWdzOiAwCiAg ICAgIHwgIHwgICstLUFTIG51bWJlcjogNjU1MzYgKDEuMCkKICAgICAgfCAgKy0tU2VjdXJlIFBh dGggU2VnbWVudDogKDYgYnl0ZXMpCiAgICAgIHwgICAgICstLXBDb3VudDogMQogICAgICB8ICAg ICArLS1GbGFnczogMAogICAgICB8ICAgICArLS1BUyBudW1iZXI6IDY0NDk2ICgwLjY0NDk2KQog ICAgICArLS1TaWduYXR1cmUgQmxvY2sgKDE4OCBieXRlcykKICAgICAgICAgKy0tTGVuZ3RoOiAx ODggYnl0ZXMKICAgICAgICAgKy0tQWxnbyBJRDogMQogICAgICAgICArLS1TaWduYXR1cmUgU2Vn bWVudDogKDkyIGJ5dGVzKQogICAgICAgICB8ICArLS1TS0k6IDQ3RjIzQkYxQUIyRjhBOUQyNjg2 NEVCQkQ4REYyNzExQzc0NDA2RUMKICAgICAgICAgfCAgKy0tTGVuZ3RoOiA3MCBieXRlcwogICAg ICAgICB8ICArLS1TaWduYXR1cmU6IDMwIDQ0IDAyIDIwIDcyIDE0IEJDIDk2ICA0NyAxNiAwQiBC RCAzOSBGRiAyRiA4MCAKICAgICAgICAgfCAgICAgICAgICAgICAgICA1MyAzRiA1RCBDNiBERCBE NyAwRCBERiAgODYgQkIgODEgNTYgNjEgRTggMDUgRDUgCiAgICAgICAgIHwgICAgICAgICAgICAg ICAgRDQgRTYgRjIgN0MgMDIgMjAgMkQgREMgIDAwIDNDIDY0IEJFIDdCIDI5IEM5IEVCIAogICAg ICAgICB8ICAgICAgICAgICAgICAgIERCIEM4IEE0IDk3IEVEIDY2IDI4IDVFICBFOSAyMiA3NiA4 MyBFNiBDMSA3OCBDRSAKICAgICAgICAgfCAgICAgICAgICAgICAgICA4RCBFNiBEMyA1OSA1RiA0 MSAKICAgICAgICAgKy0tU2lnbmF0dXJlIFNlZ21lbnQ6ICg5MyBieXRlcykKICAgICAgICAgICAg Ky0tU0tJOiBBQjREOTEwRjU1Q0FFNzFBMjE1RUYzQ0FGRTNBQ0M0NUI1RUVDMTU0CiAgICAgICAg ICAgICstLUxlbmd0aDogNzEgYnl0ZXMKICAgICAgICAgICAgKy0tU2lnbmF0dXJlOiAzMCA0NSAw MiAyMCA3MiAxNCBCQyA5NiAgNDcgMTYgMEIgQkQgMzkgRkYgMkYgODAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgNTMgM0YgNUQgQzYgREQgRDcgMEQgREYgIDg2IEJCIDgxIDU2IDYxIEU4IDA1 IEQ1IAogICAgICAgICAgICAgICAgICAgICAgICAgIEQ0IEU2IEYyIDdDIDAyIDIxIDAwIEM2ICAx NyAxOSAzNCAwNyA0MyAwNiAzQiA4QSAKICAgICAgICAgICAgICAgICAgICAgICAgICA1QyBDRCA1 NCAxNiAzOSAwQiAzMSAyMSAgMUQgM0MgNTIgNDggMDcgOTUgODcgRDAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgMTMgMTMgN0IgNDEgQ0QgMjMgRTIgCg== --_002_2A4B219CE98C410EA809AF3CD6A960DDnistgov_-- From nobody Thu Jan 12 14:33:15 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3CF129546 for ; Thu, 12 Jan 2017 14:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 vJf5EOlnpeca for ; Thu, 12 Jan 2017 14:33:11 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 A42FA129536 for ; Thu, 12 Jan 2017 14:33:11 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cRnvh-0000CB-TY; Thu, 12 Jan 2017 22:33:10 +0000 Date: Fri, 13 Jan 2017 07:33:07 +0900 Message-ID: From: Randy Bush To: "Borchert, Oliver (Fed)" In-Reply-To: References: <2459DA8D-593F-4B75-9C74-619DDBA907E4@nist.gov> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Cc: sidr list Subject: Re: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 22:33:14 -0000 mornin' oliver, > This most likely would set a bad example for others that might start > issuing certificates with $B!H(Binfinite$B!I(B life spans. 'zactly > In this regards what about a Validity of 365 days within the > example. This seems feasible to me. >> of course that leaves open what lifetime to recommend. we're not >> gonna do oscp, but rather withdraw from the rpki. so to keep from >> making too much bgp noise, let me toss out O(year) to start the >> discussion. i can live with a year. i will be interested if others comment. i have a vague memory of talking about this before. one needs to deploy the replacement key in advance, as it can take some time to propagate to the far corners of the internet. and one probably does not want to reannounce all one's routes at once. a small i-d may be in order. randy From nobody Thu Jan 12 16:08:16 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49370129546; Thu, 12 Jan 2017 16:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 14-KKXV5-B6K; Thu, 12 Jan 2017 16:08:11 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0116.outbound.protection.outlook.com [23.103.200.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CCEE1294F1; Thu, 12 Jan 2017 16:08:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cATlEuUhjlZTeDewhMBmCa0GphOgOptsb7bEYYlf8QA=; b=ubhBE85+x7N5cEvwOmOuDuhtjr1lBfIm3OnXxJFhG2YFfbqzilaY9r651ciThXrZ8YAu3QC/KgvrRNfgbtqwcHnb6ZDTU+J885VxcjicCDzlMdvtt4Ng5h3/OKT7IrIt/6Ej/bmXIwIKCEQqr72mUsRXP1nLO0wxBGsWscqfpxo= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0445.namprd09.prod.outlook.com (10.161.252.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Fri, 13 Jan 2017 00:08:08 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0817.020; Fri, 13 Jan 2017 00:08:08 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Spencer Dawkins , The IESG Thread-Topic: Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) Thread-Index: AQHSZqXltReTUHCj80yY3nhxkKtF8KE1k1Xw Date: Fri, 13 Jan 2017 00:08:08 +0000 Message-ID: References: <148354658288.13030.6680402717954276501.idtracker@ietfa.amsl.com> In-Reply-To: <148354658288.13030.6680402717954276501.idtracker@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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.122] x-ms-office365-filtering-correlation-id: a75058cb-a673-4b24-5a17-08d43b484146 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0445; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0445; 7:GyEkEZYEk6yiWDreCx2RsisqU6zeJ3zw5APMW6eR7pJ00z1Gjr9VW40rXA0hhYkDE+FCWMevdMAQ5Znab9yeMUwFZl7bnzLXSqXm0CgGww+PoiKcpV9u7D5G6I5J/aDrTmggfPDegMImnZRNzUl0ln0LdBwjdjHR+dycFwXhBwAmN6Yj1yOStq8qLbcIlugAGP38OQIzbTqXjkIVCSumkLWxYuAX3xGha3ouXTlt17RGibOgrvYen9AuSUXuFGsQgj4EO7CsLnrIdKt6zpn5i6lyPqI6Rwtq44AC7Dbjh4jzr1qRUo/rAXKAagZgd3sbYjUmTm7f0lDagojmfY4eMwBRfI2pXO8vBOW15c+Rlchqo/k3HRlQ3nbQizWfqWlBHETNAV730G82y41N/CHN8oIBAHS5t6Ximj2YONyA5KMTNjp2Q9iNVIa6ZLhShQMQJu+4Z7ikEhyYsPvkY7iyRA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:DM2PR09MB0445; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0445; x-forefront-prvs: 018632C080 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39840400002)(39850400002)(39450400003)(39860400002)(199003)(189002)(229853002)(77096006)(54906002)(106116001)(86362001)(39060400001)(2950100002)(6116002)(106356001)(74316002)(101416001)(99286003)(54356999)(105586002)(2906002)(4326007)(92566002)(7696004)(3846002)(9686003)(55016002)(6506006)(6436002)(102836003)(25786008)(38730400001)(2900100001)(5660300001)(97736004)(68736007)(50986999)(3280700002)(8676002)(3660700001)(76176999)(122556002)(81156014)(81166006)(7736002)(33656002)(8936002)(230783001)(5001770100001)(305945005)(66066001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0445; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2017 00:08:08.1773 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0445 Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , "sidr-chairs@ietf.org" , Matthias Waehlisch , "sidr@ietf.org" Subject: Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 00:08:14 -0000 SGkgU3BlbmNlciwNCg0KUGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxpbmUgYmVsb3cgbWFya2Vk IHdpdGggW1NyaXJhbV0uDQpJIGhhdmUgbWFkZSBjaGFuZ2VzIGluIHRoZSBkb2N1bWVudCBpbiBy ZXNwb25zZSB0byB5b3VyIGNvbW1lbnRzLiANCllvdeKAmWxsIHNlZSB0aGVtIGluIHZlcnNpb24t MjIgKHRvIGJlIHVwbG9hZGVkIGluIHRoZSBuZXh0IGZldyBkYXlzKS4gDQoNCj5QZXJoYXBzIEkn bSBqdXN0IGhhdmluZyBhIGdvb2QgZGF5LCBidXQgdGhpcyBpcyANCj5vbmUgb2YgdGhlIGNsZWFy ZXN0IEJHUC1yZWxhdGVkIHNwZWNpZmljYXRpb25zIA0KPkkgY2FuIHJlbWVtYmVyIHJldmlld2lu Zy4gVGhhbmtzIGZvciB0aGF0LCANCj5hbmQgZXNwZWNpYWxseSBmb3IgdGhlIGJhY2tncm91bmQg b24gZGVzaWduIGRlY2lzaW9ucy4NCg0KW1NyaXJhbV0gVmVyeSBraW5kIG9mIHlvdS4gVGhhbmsg eW91Lg0KDQo+IA0KPiBJIGRpZCBoYXZlIHF1ZXN0aW9ucyBvbiB0d28gcG9pbnRzIA0KPih3aGlj aCBhcmUgc3ByZWFkIGFjcm9zcyBtdWx0aXBsZSBzZWN0aW9ucykuDQo+IA0KPiBJIHN0YXJ0ZWQg b3V0IHdvbmRlcmluZyB3aHkNCj4gDQo+ICAgIE5vdGUgdGhhdCBCR1BzZWMgdXBkYXRlIG1lc3Nh Z2VzIGNhbiBiZSBxdWl0ZSBsYXJnZSwgdGhlcmVmb3JlIGFueQ0KPiAgICBCR1BzZWMgc3BlYWtl ciBhbm5vdW5jaW5nIHRoZSBjYXBhYmlsaXR5IHRvIHJlY2VpdmUgQkdQc2VjIG1lc3NhZ2VzDQo+ ICAgIFNIT1VMRCBhbHNvIGFubm91bmNlIHN1cHBvcnQgZm9yIHRoZSBjYXBhYmlsaXR5IHRvIHJl Y2VpdmUgQkdQDQo+ICAgIGV4dGVuZGVkIG1lc3NhZ2VzIFtJLUQuaWV0Zi1pZHItYmdwLWV4dGVu ZGVkLW1lc3NhZ2VzXS4NCj4gDQo+IGlzbid0IGEgTVVTVCwgYnV0IFNlY3Rpb24gNyBleHBsYWlu cyB0aGlzIA0KPiANCj4gICAgSW4gU2VjdGlvbiAyLjIsIGlzIHdhcyBzdGF0ZWQgdGhhdCBhIEJH UHNlYyBzcGVha2VyIFNIT1VMRCBhbm5vdW5jZQ0KPiAgICBzdXBwb3J0IGZvciB0aGUgY2FwYWJp bGl0eSB0byByZWNlaXZlIEJHUCBleHRlbmRlZCBtZXNzYWdlcy4gIExhY2sgb2YNCj4gICAgbmVn b3RpYXRpb24gb2YgdGhpcyBjYXBhYmlsaXR5IGlzIG5vdCBleHBlY3RlZCB0byBwb3NlIGEgcHJv YmxlbSBpbg0KPiAgICB0aGUgZWFybHkgeWVhcnMgb2YgQkdQc2VjIGRlcGxveW1lbnQuICBIb3dl dmVyLCBhcyBCR1BzZWMgaXMgZGVwbG95ZWQNCj4gICAgbW9yZSBhbmQgbW9yZSwgdGhlIEJHUHNl YyB1cGRhdGUgbWVzc2FnZXMgd291bGQgZ3JvdyBpbiBzaXplIGFuZCBzb21lDQo+ICAgIG1lc3Nh Z2VzIG1heSBiZSBkcm9wcGVkIGR1ZSB0byB0aGVpciBzaXplIGV4Y2VlZGluZyB0aGUgY3VycmVu dCA0Sw0KPiAgICBieXRlcyBsaW1pdC4gIFRoZXJlZm9yZSwgaXQgaXMgc3Ryb25nbHkgUkVDT01N RU5ERUQgdGhhdCBhbGwgQkdQc2VjDQo+ICAgIHNwZWFrZXJzIG5lZ290aWF0ZSB0aGUgZXh0ZW5k ZWQgbWVzc2FnZSBjYXBhYmlsaXR5IHdpdGhpbiBhDQo+ICAgIHJlYXNvbmFibGUgcGVyaW9kIG9m IHRpbWUgYWZ0ZXIgaW5pdGlhbCBkZXBsb3ltZW50IG9mIEJHUHNlYy4NCj4gDQo+IFBlcmhhcHMg dGhhdCdzIHdvcnRoIGEgZm9yd2FyZCBwb2ludGVyPyANCj4ob3IgbWF5YmUgZXZlbiBkcmFnZ2lu ZyB0aGlzIHBhcmFncmFwaCBmb3J3YXJkIGZyb20gU2VjdGlvbiA3KQ0KDQpbU3JpcmFtXSBJIGhh dmUgcHV0IGluIGEgZm9yd2FyZCBwb2ludGVyIGluIFNlY3Rpb24gMi4yLg0KSXQgcmVhZHMsIOKA nFBsZWFzZSBzZWUgcmVsYXRlZCBvcGVyYXRpb25hbCBndWlkYW5jZSBpbiBTZWN0aW9uIDcu4oCd IA0KDQo+IA0KPiBJJ20gbG9va2luZyBhdCANCj4gDQo+ICAgIEJHUHNlYyBzcGVha2VycyBTSE9V TEQgZHJvcA0KPiAgICBpbmNvbWluZyB1cGRhdGUgbWVzc2FnZXMgd2l0aCBwQ291bnQgc2V0IHRv IHplcm8gaW4gY2FzZXMgd2hlcmUgdGhlDQo+ICAgIEJHUHNlYyBzcGVha2VyIGRvZXMgbm90IGV4 cGVjdCBpdHMgcGVlciB0byBzZXQgcENvdW50IHRvIHplcm8uIA0KPiAoVGhhdA0KPiAgICBpcywg cENvdW50IGlzIG9ubHkgdG8gYmUgc2V0IHRvIHplcm8gaW4gY2FzZXMgc3VjaCBhcyByb3V0ZSBz ZXJ2ZXJzDQo+ICAgIG9yIEFTIE51bWJlciBNaWdyYXRpb24gd2hlcmUgdGhlIEJHUHNlYyBzcGVh a2VyJ3MgcGVlciBleHBlY3RzIHBDb3VudA0KPiAgICB0byBiZSBzZXQgdG8gemVyby4pDQo+IA0K PiBhbmQgd29uZGVyaW5nIHdoeSB0aGF0J3Mgbm90IGEgTVVTVC4gIElmIEknbSB1bmRlcnN0YW5k aW5nIHRoaXMgDQo+Y29ycmVjdGx5ICh3aGljaCBpcyB0aGVvcmV0aWNhbGx5IHBvc3NpYmxlKSwg dGhlIEJHUHNlYyBzcGVha2VyIA0KPmlzIHRlbGxpbmcgaXRzIHBlZXIgdGhhdCBpdCdzIG5vdCBw YXJ0aWNpcGF0aW5nIGFzIGEgdHJhbnNpdCBBUywgDQo+YnV0IHRoZSBwZWVyIHRoaW5rcyBpdCBz aG91bGQgYmUuIElzIHRoZXJlIGFueXRoaW5nIGludGVsbGlnZW50IA0KPnRoYXQgdGhlIHBlZXIg Y2FuIGRvIHdpdGggdGhlIHVwZGF0ZT8NCg0KW1NyaXJhbV0gWW91IGFyZSBhYnNvbHV0ZWx5IHJp Z2h0OiBNVVNUIG1ha2VzIHNlbnNlLiBCZWNhdXNlIGxhdGVyIGluIA0KU2VjdGlvbiA1LjIgY2hl Y2sgbGlzdCwgd2Ugc2F5OiANCg0KICAgNy4gIElmIHRoZSB1cGRhdGUgbWVzc2FnZSB3YXMgcmVj ZWl2ZWQgZnJvbSBhIHBlZXIgdGhhdCBpcyBub3QNCiAgICAgICBleHBlY3RlZCB0byBzZXQgcENv dW50IGVxdWFsIHRvIHplcm8gKHNlZSBTZWN0aW9uIDQuMiBhbmQNCiAgICAgICBTZWN0aW9uIDQu MykgdGhlbiBjaGVjayB0byBlbnN1cmUgdGhhdCB0aGUgcENvdW50IGZpZWxkIGluIHRoZQ0KICAg ICAgIG1vc3QtcmVjZW50bHkgYWRkZWQgU2VjdXJlX1BhdGggU2VnbWVudCBpcyBub3QgZXF1YWwg dG8gemVyby4NCiAgICAgICAoU2VlIHJvdXRlciBjb25maWd1cmF0aW9uIGd1aWRhbmNlIHJlbGF0 ZWQgdG8gdGhpcyBpbiBTZWN0aW9uIDcuKQ0KDQpbU3JpcmFtXSBJbiBTZWN0aW9uIDUuMiwgd2Ug YWxzbyBzYXk6IA0KDQogICBJZiBhbnkgb2YgdGhlc2UgY2hlY2tzIGZhaWwsIGl0IGlzIGFuIGVy cm9yIGluIHRoZSBCR1BzZWNfUGF0aA0KICAgYXR0cmlidXRlLiAgDQoNCltTcmlyYW1dIFNpbmNl IHRoZSByZWNlaXZlciBhY3Rpb24gaXMgY2xlYXJseSBzdGF0ZWQgaW4gU2VjdGlvbiA1LjIsIA0K SSBoYXZlIGRyb3BwZWQgdGhlIHR3byBzZW50ZW5jZXMgeW91IGNpdGVkIGJlZ2lubmluZyB3aXRo IA0K4oCcQkdQc2VjIHNwZWFrZXJzIFNIT1VMRCBkcm9wIGluY29taW5nIHVwZGF0ZSANCm1lc3Nh Z2VzIHdpdGggcENvdW50IHNldCB0byB6ZXJv4oCm4oCdDQpmcm9tIFNlY3Rpb24gNC4yIHdoaWNo IGlzIGFsbCBhYm91dCBzZW5kZXIgYWN0aW9ucy4NClRoYXQgcGFydGljdWxhciBwYXJhZ3JhcGgg bm93IHJlYWRzOg0KDQogICBBIHJvdXRlIHNlcnZlciB0aGF0IHBhcnRpY2lwYXRlcyBpbiB0aGUg QkdQIGNvbnRyb2wgcGxhbmUsIGJ1dCBkb2VzDQogICBub3QgYWN0IGFzIGEgdHJhbnNpdCBBUyBp biB0aGUgZGF0YSBwbGFuZSwgbWF5IGNob29zZSB0byBzZXQgcENvdW50DQogICB0byAwLiAgVGhp cyBvcHRpb24gZW5hYmxlcyB0aGUgcm91dGUgc2VydmVyIHRvIHBhcnRpY2lwYXRlIGluIEJHUHNl Yw0KICAgYW5kIG9idGFpbiB0aGUgYXNzb2NpYXRlZCBzZWN1cml0eSBndWFyYW50ZWVzIHdpdGhv dXQgaW5jcmVhc2luZyB0aGUNCiAgIGxlbmd0aCBvZiB0aGUgQVMgcGF0aC4gIChOb3RlIHRoYXQg QkdQc2VjIHNwZWFrZXJzIGNvbXB1dGUgdGhlIGxlbmd0aA0KICAgb2YgdGhlIEFTIHBhdGggYnkg c3VtbWluZyB0aGUgcENvdW50IHZhbHVlcyBpbiB0aGUgQkdQc2VjX1BhdGgNCiAgIGF0dHJpYnV0 ZSwgc2VlIFNlY3Rpb24gNS4pICBIb3dldmVyLCB3aGVuIGEgcm91dGUgc2VydmVyIHNldHMgdGhl DQogICBwQ291bnQgdmFsdWUgdG8gMCwgaXQgc3RpbGwgaW5zZXJ0cyBpdHMgQVMgbnVtYmVyIGlu dG8gdGhlDQogICBTZWN1cmVfUGF0aCBTZWdtZW50LCBhcyB0aGlzIGluZm9ybWF0aW9uIGlzIG5l ZWRlZCB0byB2YWxpZGF0ZSB0aGUNCiAgIHNpZ25hdHVyZSBhZGRlZCBieSB0aGUgcm91dGUgc2Vy dmVyLiAgU2VlDQogICBbSS1ELmlldGYtc2lkci1hcy1taWdyYXRpb25dIGZvciBhIGRpc2N1c3Np b24gb2Ygc2V0dGluZyBwQ291bnQgdG8gMA0KICAgdG8gZmFjaWxpdGF0ZSBBUyBOdW1iZXIgTWln cmF0aW9uLiAgQWxzbyBzZWUgU2VjdGlvbiA0LjMgZm9yIHRoZSB1c2UNCiAgIG9mIHBDb3VudD0w IGluIHRoZSBjb250ZXh0IG9mIGFuIEFTIGNvbmZlZGVyYXRpb24uICBTZWUgU2VjdGlvbiA3IGZv cg0KICAgb3BlcmF0aW9uYWwgZ3VpZGFuY2UgZm9yIGNvbmZpZ3VyaW5nIGEgQkdQc2VjIHJvdXRl ciBmb3Igc2V0dGluZw0KICAgcENvdW50PTAgYW5kL29yIGFjY2VwdGluZyBwQ291bnQ9MCBmcm9t IGEgcGVlci4NCg0KPiANCj4gU2VjdGlvbiA3IHJlZmVycyB0byB0aGlzIFNIT1VMRCwgd2hpbGUg YWRkaW5nIGEgZmV3IG1vcmUgU0hPVUxEcy4gDQo+IA0KPiAgICBBIHBlZXIgdGhhdCBpcyBhbiBJ bnRlcm5ldCBFeGNoYW5nZSBQb2ludCAoSVhQKSAoaS5lLiAgUm91dGUgU2VydmVyKQ0KPiAgICB3 aXRoIGEgdHJhbnNwYXJlbnQgQVMgaXMgZXhwZWN0ZWQgdG8gc2V0IHBDb3VudCA9IDAgaW4gaXRz DQo+ICAgIFNlY3VyZV9QYXRoIFNlZ21lbnQgd2hpbGUgZm9yd2FyZGluZyBhbiB1cGRhdGUgdG8g YSBwZWVyIChzZWUNCj4gICAgU2VjdGlvbiA0LjIpLiAgQ2xlYXJseSwgc3VjaCBhbiBJWFAgU0hP VUxEIGNvbmZpZ3VyZSBpdHNlbGYgdG8gc2V0DQo+ICAgIGl0cyBvd24gcENvdW50ID0gMC4gIEFz IHN0YXRlZCBpbiBTZWN0aW9uIDQuMiwgIkJHUHNlYyBzcGVha2Vycw0KPiAgICBTSE9VTEQgZHJv cCBpbmNvbWluZyB1cGRhdGUgbWVzc2FnZXMgd2l0aCBwQ291bnQgc2V0IHRvIHplcm8gaW4gY2Fz ZXMNCj4gICAgd2hlcmUgdGhlIEJHUHNlYyBzcGVha2VyIGRvZXMgbm90IGV4cGVjdCBpdHMgcGVl ciB0byBzZXQgcENvdW50IHRvDQo+ICAgIHplcm8uIiAgVGhpcyBtZWFucyB0aGF0IGEgQkdQc2Vj IHNwZWFrZXIgU0hPVUxEIGJlIGNvbmZpZ3VyZWQgc28gdGhhdA0KPiAgICBpdCBwZXJtaXRzIHBD b3VudCA9MCBmcm9tIGFuIElYUCBwZWVyIGFuZCBuZXZlciBwZXJtaXRzIHBDb3VudCA9IDANCj4g ICAgZnJvbSBhIHBlZXIgdGhhdCBpcyBub3QgYW4gSVhQLg0KPiANCj4gQWdhaW4sIEknbSBjdXJp b3VzIGFib3V0IHdoeSBhIEJHUHNlYyBzcGVha2VyIA0KPndvdWxkbid0IGRvIHRoaXMuIElzIHRo YXQgb2J2aW91cywgdG8gdGhvc2Ugc2tpbGxlZCBpbiB0aGUgYXJ0Pw0KPiANCj4gSSdtIGxvb2tp bmcgYXQgU2VjdGlvbiA4LjQsIHdoaWNoIGFkZHMgc29tZSBtb3JlIGJhY2tncm91bmQuDQo+IA0K PiAgICBUaGUgbWVjaGFuaXNtIG9mIHNldHRpbmcgdGhlIHBDb3VudCBmaWVsZCB0byB6ZXJvIGlz IGluY2x1ZGVkIGluIHRoaXMNCj4gICAgc3BlY2lmaWNhdGlvbiB0byBlbmFibGUgcm91dGUgc2Vy dmVycyBpbiB0aGUgY29udHJvbCBwYXRoIHRvDQo+ICAgIHBhcnRpY2lwYXRlIGluIEJHUHNlYyB3 aXRob3V0IGluY3JlYXNpbmcgdGhlIGxlbmd0aCBvZiB0aGUgQVMgcGF0aC4NCj4gICAgSG93ZXZl ciwgZW50aXRpZXMgb3RoZXIgdGhhbiByb3V0ZSBzZXJ2ZXJzIGNvdWxkIGNvbmNlaXZhYmx5IHVz ZSB0aGlzDQo+ICAgIG1lY2hhbmlzbSAoc2V0IHRoZSBwQ291bnQgdG8gemVybykgdG8gYXR0cmFj dCB0cmFmZmljIChieSByZWR1Y2luZw0KPiAgICB0aGUgbGVuZ3RoIG9mIHRoZSBBUyBwYXRoKSBp bGxlZ2l0aW1hdGVseS4gIFRoaXMgcmlzayBpcyBsYXJnZWx5DQo+ICAgIG1pdGlnYXRlZCBpZiBl dmVyeSBCR1BzZWMgc3BlYWtlciBkcm9wcyBpbmNvbWluZyB1cGRhdGUgbWVzc2FnZXMgdGhhdA0K PiAgICBzZXQgcENvdW50IHRvIHplcm8gYnV0IGNvbWUgZnJvbSBhIHBlZXIgdGhhdCBpcyBub3Qg YSByb3V0ZSBzZXJ2ZXIuDQo+ICAgIEhvd2V2ZXIsIG5vdGUgdGhhdCBhIHJlY2lwaWVudCBvZiBh IEJHUHNlYyB1cGRhdGUgbWVzc2FnZSB3aXRoaW4NCj4gICAgd2hpY2ggYW4gdXBzdHJlYW0gZW50 aXR5IHR3byBvciBtb3JlIGhvcHMgYXdheSBoYXMgc2V0IHBDb3VudCB0byB6ZXJvDQo+ICAgIGlz IHVuYWJsZSB0byB2ZXJpZnkgZm9yIHRoZW1zZWx2ZXMgd2hldGhlciBwQ291bnQgd2FzIHNldCB0 byB6ZXJvDQo+ICAgIGxlZ2l0aW1hdGVseS4NCj4gDQo+IFNvLCB0aGUgcmVhc29uIHRoaXMgaXMg YSBTSE9VTEQsIGFuZCBub3QgYSBNVVNULCBpcyBiZWNhdXNlIA0KPmEgcmVjaXBpZW50IHR3byBv ciBtb3JlIGhvcHMgYXdheSBjYW4ndCBiZSBzdXJlIHBDb3VudCB3YXMgDQo+c2V0IGFwcHJvcHJp YXRlbHk/IEJ1dCBkb2Vzbid0IHRoZSBTSE9VTEQgaW5jcmVhc2UgdGhlIA0KPmNoYW5jZXMgdG8g cHJvcGFnYXRlIGFuIHVwZGF0ZSB3aXRoIGFuIGluYXBwcm9wcmlhdGUgcENvdW50Pw0KPiANCg0K W1NyaXJhbV0gSSBsaWdodCBvZiB3aGF0IEkgc2FpZCBhYm92ZSwgSSBoYXZlIHJldmlzZWQgdGhl IHBhcmFncmFwaA0KaW4gU2VjdGlvbiA3IHRvIHJlYWQ6DQoNCiAgIEEgcGVlciB0aGF0IGlzIGFu IEludGVybmV0IEV4Y2hhbmdlIFBvaW50IChJWFApIChpLmUuICBSb3V0ZSBTZXJ2ZXIpDQogICB3 aXRoIGEgdHJhbnNwYXJlbnQgQVMgaXMgZXhwZWN0ZWQgdG8gc2V0IHBDb3VudD0wIGluIGl0cyBT ZWN1cmVfUGF0aA0KICAgU2VnbWVudCB3aGlsZSBmb3J3YXJkaW5nIGFuIHVwZGF0ZSB0byBhIHBl ZXIgKHNlZSBTZWN0aW9uIDQuMikuDQogICBDbGVhcmx5LCBzdWNoIGFuIElYUCBtdXN0IGNvbmZp Z3VyZSBpdHMgQkdQc2VjIHJvdXRlciB0byBzZXQgcENvdW50PTANCiAgIGluIGl0cyBTZWN1cmVf UGF0aCBTZWdtZW50LiAgVGhpcyBhbHNvIG1lYW5zIHRoYXQgYSBCR1BzZWMgc3BlYWtlcg0KICAg TVVTVCBiZSBjb25maWd1cmVkIHNvIHRoYXQgaXQgcGVybWl0cyBwQ291bnQ9MCBmcm9tIGFuIElY UCBwZWVyLiAgVHdvDQogICBvdGhlciBjYXNlcyB3aGVyZSBwQ291bnQgaXMgc2V0IHRvIHplcm8g YXJlIGluIHRoZSBjb250ZXh0IEFTDQogICBjb25mZWRlcmF0aW9uIChzZWUgU2VjdGlvbiA0LjIp IGFuZCBBUyBtaWdyYXRpb24NCiAgIFtJLUQuaWV0Zi1zaWRyLWFzLW1pZ3JhdGlvbl0uICBJbiB0 aGVzZSB0d28gY2FzZXMsIHBDb3VudD0wIGlzIHNldA0KICAgYW5kIGFjY2VwdGVkIHdpdGhpbiB0 aGUgc2FtZSBBUyAoYWxiZWl0IHRoZSBBUyBoYXMgdHdvIGRpZmZlcmVudA0KICAgaWRlbnRpdGll cykuICBOb3RlIHRoYXQgaWYgYSBCR1BzZWMgc3BlYWtlciBkb2VzIG5vdCBleHBlY3QgYSBwZWVy IEFTDQogICB0byBzZXQgaXRzIHBDb3VudD0wLCBhbmQgaWYgYW4gdXBkYXRlIHJlY2VpdmVkIGZy b20gdGhhdCBwZWVyDQogICB2aW9sYXRlcyB0aGlzLCB0aGVuIHRoZSB1cGRhdGUgTVVTVCBiZSBj b25zaWRlcmVkIHRvIGJlIGluIGVycm9yIChzZWUNCiAgIHRoZSBsaXN0IG9mIGNoZWNrcyBpbiBT ZWN0aW9uIDUuMikuICBTZWUgU2VjdGlvbiA4LjQgZm9yIGENCiAgIGRpc2N1c3Npb24gb2Ygc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgY29uY2VybmluZyBwQ291bnQ9MC4NCiANCg0KW1NyaXJhbV0g SSBsaWdodCBvZiB3aGF0IEkgc2FpZCBhYm92ZSwgSSBoYXZlIGFsc28gcmV2aXNlZCB0aGUgcGFy YWdyYXBoDQppbiBTZWN0aW9uIDguNCB0byByZWFkOg0KDQogICBUaGUgbWVjaGFuaXNtIG9mIHNl dHRpbmcgdGhlIHBDb3VudCBmaWVsZCB0byB6ZXJvIGlzIGluY2x1ZGVkIGluIHRoaXMNCiAgIHNw ZWNpZmljYXRpb24gdG8gZW5hYmxlIHJvdXRlIHNlcnZlcnMgaW4gdGhlIGNvbnRyb2wgcGF0aCB0 bw0KICAgcGFydGljaXBhdGUgaW4gQkdQc2VjIHdpdGhvdXQgaW5jcmVhc2luZyB0aGUgbGVuZ3Ro IG9mIHRoZSBBUyBwYXRoLg0KICAgVHdvIG90aGVyIHNjZW5hcmlvcyB3aGVyZSBwQ291bnQ9MCBp cyB1dGlsaXplZCBhcmUgaW4gdGhlIGNvbnRleHQgQVMNCiAgIGNvbmZlZGVyYXRpb24gKHNlZSBT ZWN0aW9uIDQuMikgYW5kIEFTIG1pZ3JhdGlvbg0KICAgW0ktRC5pZXRmLXNpZHItYXMtbWlncmF0 aW9uXS4gIEluIHRoZXNlIHR3byBzY2VuYXJpb3MsIHBDb3VudD0wIGlzDQogICBzZXQgYW5kIGFs c28gYWNjZXB0ZWQgd2l0aGluIHRoZSBzYW1lIEFTIChhbGJlaXQgdGhlIEFTIGhhcyB0d28NCiAg IGRpZmZlcmVudCBpZGVudGl0aWVzKS4gIEhvd2V2ZXIsIGVudGl0aWVzIG90aGVyIHRoYW4gcm91 dGUgc2VydmVycywNCiAgIGNvbmZlZGVyYXRpb24gQVNlcyBvciBtaWdyYXRpbmcgQVNlcyBjb3Vs ZCBjb25jZWl2YWJseSB1c2UgdGhpcw0KICAgbWVjaGFuaXNtIChzZXQgdGhlIHBDb3VudCB0byB6 ZXJvKSB0byBhdHRyYWN0IHRyYWZmaWMgKGJ5IHJlZHVjaW5nDQogICB0aGUgbGVuZ3RoIG9mIHRo ZSBBUyBwYXRoKSBpbGxlZ2l0aW1hdGVseS4gIFRoaXMgcmlzayBpcyBsYXJnZWx5DQogICBtaXRp Z2F0ZWQgaWYgZXZlcnkgQkdQc2VjIHNwZWFrZXIgZm9sbG93cyB0aGUgb3BlcmF0aW9uYWwgZ3Vp ZGFuY2UgaW4NCiAgIFNlY3Rpb24gNyBmb3IgY29uZmlndXJhdGlvbiBmb3Igc2V0dGluZyBwQ291 bnQ9MCBhbmQvb3IgYWNjZXB0aW5nDQogICBwQ291bnQ9MCBmcm9tIGEgcGVlci4gIEhvd2V2ZXIs IG5vdGUgdGhhdCBhIHJlY2lwaWVudCBvZiBhIEJHUHNlYw0KICAgdXBkYXRlIG1lc3NhZ2Ugd2l0 aGluIHdoaWNoIGFuIHVwc3RyZWFtIGVudGl0eSB0d28gb3IgbW9yZSBob3BzIGF3YXkNCiAgIGhh cyBzZXQgcENvdW50IHRvIHplcm8gaXMgdW5hYmxlIHRvIHZlcmlmeSBmb3IgdGhlbXNlbHZlcyB3 aGV0aGVyDQogICBwQ291bnQgd2FzIHNldCB0byB6ZXJvIGxlZ2l0aW1hdGVseS4NCg0KDQpTcmly YW0NCg0K From nobody Thu Jan 12 16:44:22 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF61F1295A2; Thu, 12 Jan 2017 16:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 YPSXDQNm_NzD; Thu, 12 Jan 2017 16:44:19 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 E91411295AC; Thu, 12 Jan 2017 16:44:16 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cRpyY-0000o2-L4; Fri, 13 Jan 2017 00:44:14 +0000 Date: Fri, 13 Jan 2017 09:44:12 +0900 Message-ID: From: Randy Bush To: "Sriram, Kotikalapudi (Fed)" In-Reply-To: References: <148354658288.13030.6680402717954276501.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list , Spencer Dawkins , The IESG Subject: Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 00:44:21 -0000 >> Note that BGPsec update messages can be quite large, therefore any >> BGPsec speaker announcing the capability to receive BGPsec messages >> SHOULD also announce support for the capability to receive BGP >> extended messages [I-D.ietf-idr-bgp-extended-messages]. >> >> isn't a MUST, but Section 7 explains this >> >> In Section 2.2, is was stated that a BGPsec speaker SHOULD announce >> support for the capability to receive BGP extended messages. Lack of >> negotiation of this capability is not expected to pose a problem in >> the early years of BGPsec deployment. However, as BGPsec is deployed >> more and more, the BGPsec update messages would grow in size and some >> messages may be dropped due to their size exceeding the current 4K >> bytes limit. Therefore, it is strongly RECOMMENDED that all BGPsec >> speakers negotiate the extended message capability within a >> reasonable period of time after initial deployment of BGPsec. how about just saying A router announcing the capability to send or to receive BGPsec updates MUST also announce the capability to send and receive BGP extended messages [I-D.ietf-idr-bgp-extended-messages]. and call it a day? randy From nobody Thu Jan 12 17:16:29 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6B1129620 for ; Thu, 12 Jan 2017 17:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 RDmbNIsGLU3E for ; Thu, 12 Jan 2017 17:16:26 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 D6749129613 for ; Thu, 12 Jan 2017 17:16:25 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id s140so40025025qke.0 for ; Thu, 12 Jan 2017 17:16:25 -0800 (PST) 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=/lIs2gVJyn+d5/l2v2Fu2VFbsxAtm55ksIJrjBhKY1M=; b=AMGr0/haCbx9i06vjKd7Is6CCS+fkYqITpOjzoUlYPBo9nTLrlM8zo5LdkLZJQRIr0 gdtY4HTQU3oN8DegW+hHu1ojJnAv+nhSyr1Nf6/+5o51Vd4okBZH1cgHn2WyWFXLrzDe f037BJenyTJjuzZdew+PHG8mcQMtGKhbqqllk= 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=/lIs2gVJyn+d5/l2v2Fu2VFbsxAtm55ksIJrjBhKY1M=; b=XC1m+UBb65UeQFNhQgaZ2n+AZZvSylKDr51/pGUb6ZqEzzk7Aryj+HXHBCRPLmt+VJ /fwQIri3bEZLpaR0nmCvpAGaoANaEbJpgzeekKTbfJw4i96jXyNZxj66kGOh7YNJoiax 2z6/CLCNYZauBjMBXzwR5BIptA5JuCBSDAOrDidK17GR3SP7yW9s5KkQdd7X6ON8V+Q/ v8JiNk5DczX3YR2HuU/vaerZ5TQH4CToyX5pKems3Zca75Zatowp0dLp9a8gr9oKMacL md+F7/pB6YTZZ0/csW/JiYxLASwkRjg3K9oqGllokrlxNIzaU2lOM/eF7peYLqiYNxHC Ro+Q== X-Gm-Message-State: AIkVDXK5sVjBP+LzhLwkopTLcGnr3wxNwZEeWjTzWR7ROb5/PF9bu41tGo0ixGz0FfrBxQ== X-Received: by 10.55.100.88 with SMTP id y85mr15295835qkb.194.1484270185018; Thu, 12 Jan 2017 17:16:25 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id i41sm8024122qtc.18.2017.01.12.17.16.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 12 Jan 2017 17:16:24 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Thu, 12 Jan 2017 20:16:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2459DA8D-593F-4B75-9C74-619DDBA907E4@nist.gov> To: Randy Bush X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sidr list Subject: Re: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 01:16:27 -0000 > On Jan 12, 2017, at 17:33, Randy Bush wrote: >=20 > mornin' oliver, >=20 >> This most likely would set a bad example for others that might start >> issuing certificates with =E2=80=9Cinfinite=E2=80=9D life spans. >=20 > 'zactly >=20 >> In this regards what about a Validity of 365 days within the >> example. This seems feasible to me. >=20 >>> of course that leaves open what lifetime to recommend. we're not >>> gonna do oscp, but rather withdraw from the rpki. so to keep from >>> making too much bgp noise, let me toss out O(year) to start the >>> discussion. >=20 > i can live with a year. i will be interested if others comment. >=20 > i have a vague memory of talking about this before. one needs to = deploy > the replacement key in advance, as it can take some time to propagate = to > the far corners of the internet. and one probably does not want to > reannounce all one's routes at once. >=20 > a small i-d may be in order. The CPS really dictates the validity period. Can you check what your = RIPE issued RPKI certificates have as a validity date? You=E2=80=99re right that you need to get the replacement cert early to = make sure you don=E2=80=99t end up being without a certificate. RFC = 6484 recommends 1 week prior to the expiration of the old cert. I think = the CPS also allows some addition time to account for this problem. spt= From nobody Thu Jan 12 23:15:36 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3701D1294B0; Thu, 12 Jan 2017 23:15:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148429173222.3012.8919864893980202463.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2017 23:15:32 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-adverse-actions-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 07:15:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) Authors : Stephen Kent Di Ma Filename : draft-ietf-sidr-adverse-actions-04.txt Pages : 25 Date : 2017-01-12 Abstract: This document analyzes actions by or against a CA or independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is done from the perspective of an affected INR holder. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or independent repository manager) and fetched by Relying Parties (RPs). The analysis does not purport to be comprehensive; it does represent an orderly way to analyze a number of ways that errors by or attacks against a CA or repository manager can affect the RPKI and routing decisions based on RPKI data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-adverse-actions/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-adverse-actions-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-adverse-actions-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 13 06:48:31 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C53912966C; Fri, 13 Jan 2017 06:48:30 -0800 (PST) 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=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 OyneYqhoFf7l; Fri, 13 Jan 2017 06:48:29 -0800 (PST) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (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 E18F1129660; Fri, 13 Jan 2017 06:48:28 -0800 (PST) Received: by mail-yb0-x22e.google.com with SMTP id l23so15667833ybj.2; Fri, 13 Jan 2017 06:48:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WYpB7BibCIrSccRDVUur0Sgo4T6MFKuFn0RswkFYuFc=; b=rfRxLL8rplB3TvhrJTx/GxJ/xbJHuEASFcVK1bHGdNVRwhVKiBaAWsYcKuG7wJMwbs jeA5sZlVnXhcqurAu9W3MB1wyUDnz65VunI7La1b0+hY2SCQAtSi0pDxLjGN7ue2K18Y epA85Y6qnPHeEu36boHWIY/5rKWHAddWidNj6VfG52RhMygCZUiax/gBe1Wv3LWWJQS5 KQwl+oQGZZLf+n3vklHSJD2w1aEiEiY73A6sH9FYdRAY+XNvb+uyKlYIoidBobKVaAti yErGyGd3tSpQgrPsNv5Dcf/7F76sf+fy03T4hxmi6WJNfPIKfYqVj/Pq8qpJG3SD7ROy 3MKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WYpB7BibCIrSccRDVUur0Sgo4T6MFKuFn0RswkFYuFc=; b=MYHUV/jyQx7KnlsRjE7SW4kmCgsIXLqdhycxG57iFfUCwgDnxrKOW76EDviALx6yNx Rv20QU+c3hnEPFN6OVZs1n84FKA0Ru+5dN+cPcaS0/qOxHliX6H7Y6fCVubNv3uJzT4g 6SEgwN9KlMHhUZzvrv0AHooeO8mvhi0jjDomxZOR3KIuBQSaUKVBewcEShd9T/rfbW57 voLa8zpjRvuH0uyfEfI61w2hBuJ5Os1Rx/K8jT3WAFBhffo+bL2fj4zEM1vhpJD71H5K MaZ0AvUldneGIJ4kYzpTHBZkrmNdYXea1yQeZEW7M/Te1BCNBQu60wlr3r9tkUmaBWcL I+cA== X-Gm-Message-State: AIkVDXK9zSxJyYQqI3HFcmwgS3c4OCl2FN/PXxcqFzgfaeLB1SL3gg/gCidmJ+33E40sm1sy9Gp9EtnrZlGY9g== X-Received: by 10.37.204.193 with SMTP id l184mr12492766ybf.182.1484318908165; Fri, 13 Jan 2017 06:48:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.221.195 with HTTP; Fri, 13 Jan 2017 06:48:27 -0800 (PST) In-Reply-To: References: <148354658288.13030.6680402717954276501.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Fri, 13 Jan 2017 08:48:27 -0600 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=94eb2c083aa641344d0545faedea Archived-At: Cc: "Sriram, Kotikalapudi \(Fed\)" , The IESG , sidr wg list Subject: Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 14:48:30 -0000 --94eb2c083aa641344d0545faedea Content-Type: text/plain; charset=UTF-8 You folks are headed in the right direction. I'll be happy wherever you end up. Thanks! Spencer On Thursday, January 12, 2017, Randy Bush wrote: > >> Note that BGPsec update messages can be quite large, therefore any > >> BGPsec speaker announcing the capability to receive BGPsec messages > >> SHOULD also announce support for the capability to receive BGP > >> extended messages [I-D.ietf-idr-bgp-extended-messages]. > >> > >> isn't a MUST, but Section 7 explains this > >> > >> In Section 2.2, is was stated that a BGPsec speaker SHOULD announce > >> support for the capability to receive BGP extended messages. Lack of > >> negotiation of this capability is not expected to pose a problem in > >> the early years of BGPsec deployment. However, as BGPsec is deployed > >> more and more, the BGPsec update messages would grow in size and some > >> messages may be dropped due to their size exceeding the current 4K > >> bytes limit. Therefore, it is strongly RECOMMENDED that all BGPsec > >> speakers negotiate the extended message capability within a > >> reasonable period of time after initial deployment of BGPsec. > > how about just saying > > A router announcing the capability to send or to receive BGPsec > updates MUST also announce the capability to send and receive BGP > extended messages [I-D.ietf-idr-bgp-extended-messages]. > > and call it a day? > > randy > --94eb2c083aa641344d0545faedea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You folks are headed in the right direction. I'll be happy wherever you= end up.

Thanks!

Spencer
<= br>On Thursday, January 12, 2017, Randy Bush <randy@psg.com> wrote:
>&= gt;=C2=A0 =C2=A0 Note that BGPsec update messages can be quite large, there= fore any
>>=C2=A0 =C2=A0 BGPsec speaker announcing the capability to receive B= GPsec messages
>>=C2=A0 =C2=A0 SHOULD also announce support for the capability to re= ceive BGP
>>=C2=A0 =C2=A0 extended messages [I-D.ietf-idr-bgp-extended-mes= sages].
>>
>> isn't a MUST, but Section 7 explains this
>>
>>=C2=A0 =C2=A0 In Section 2.2, is was stated that a BGPsec speaker S= HOULD announce
>>=C2=A0 =C2=A0 support for the capability to receive BGP extended me= ssages.=C2=A0 Lack of
>>=C2=A0 =C2=A0 negotiation of this capability is not expected to pos= e a problem in
>>=C2=A0 =C2=A0 the early years of BGPsec deployment.=C2=A0 However, = as BGPsec is deployed
>>=C2=A0 =C2=A0 more and more, the BGPsec update messages would grow = in size and some
>>=C2=A0 =C2=A0 messages may be dropped due to their size exceeding t= he current 4K
>>=C2=A0 =C2=A0 bytes limit.=C2=A0 Therefore, it is strongly RECOMMEN= DED that all BGPsec
>>=C2=A0 =C2=A0 speakers negotiate the extended message capability wi= thin a
>>=C2=A0 =C2=A0 reasonable period of time after initial deployment of= BGPsec.

how about just saying

=C2=A0 =C2=A0A router announcing the capability to send or to receive BGPse= c
=C2=A0 =C2=A0updates MUST also announce the capability to send and receive = BGP
=C2=A0 =C2=A0extended messages [I-D.ietf-idr-bgp-extended-messages].
and call it a day?

randy
--94eb2c083aa641344d0545faedea-- From nobody Fri Jan 13 13:31:40 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176CE129B4B; Fri, 13 Jan 2017 13:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 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_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 SSaRMS3OS4-g; Fri, 13 Jan 2017 13:31:31 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0126.outbound.protection.outlook.com [23.103.201.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1DE128B38; Fri, 13 Jan 2017 13:31:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xKUTsPsH/kzw+FiPPLotO9cyb/uuXgZJVXae2ro/NEI=; b=Cd3+nsAJah7kCST0uq2falIHGBQeDk9gdSfjSeRh65r7PT0EG1238C2P1ozMKVur45fJr5oKchVLqBt0nC81pOP+a6ru1mzxXlmzd8E6RTjoQ9ikYXaUgCt9MxMNcJ8MePFBNjX/H8xhgZ6d3utYFeJbjBEWtNuYLsC271r9aRM= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0448.namprd09.prod.outlook.com (10.161.252.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Fri, 13 Jan 2017 21:31:29 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0817.020; Fri, 13 Jan 2017 21:31:28 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Mirja Kuehlewind , The IESG , "Alexey Melnikov" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-sidr-bgpsec-protocol-21:_(with_COMMENT)?= Thread-Index: AQHSZrizhvIT4qoXnkq4q8a0RO1mhqE28/Sg Date: Fri, 13 Jan 2017 21:31:28 +0000 Message-ID: References: <148355465867.12949.10785749487953700357.idtracker@ietfa.amsl.com> In-Reply-To: <148355465867.12949.10785749487953700357.idtracker@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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.122] x-ms-office365-filtering-correlation-id: 22f2b8a2-7296-426c-b422-08d43bfb891e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0448; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0448; 7:WgCIXIKxon2//eM4J6+RrPIyVpTgV1IK+2533Vlri9cP6thZCiQmpgA9sZ4XhNdGRlAt16yhm/RXZkCbz2/zR32jBuVxDfVF14z4hnEfY0Y6FLEZXtwp72rM7toS95D6ccXAQdqCRGc2gVhGNxrleRQIDZ2cM5FUzghCpnvohBfiH7VbVFMYRknCQqPSnUy3QV5zj9bZ6vQdzAqT0VYJ6Od/4lc85ZTwZWNOBcdDtT7C79KsFdFSrWNSSbsZudAZEBLuNJNyY2bVveWddWFTuRplMVIFTG+C+8E8kCFVcD82gvulfNGyaEy5Z4ChG2iWDcTu+VjMQdyMEP98xZDfBU3ouyZQz3YlGi/C3qzbViv9GlSkWsrbBRXeRAH/CTx1Ed9DYc1q3dIuFD8do/qwlseAheibcONj8NjLbJDreogo35KbBebQxFYJklbQo/e1zXNt7ijEfx9ss5E5cVzXlw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(131327999870524)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:DM2PR09MB0448; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0448; x-forefront-prvs: 018632C080 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39860400002)(39840400002)(39850400002)(39410400002)(189002)(199003)(2906002)(5001770100001)(3660700001)(66066001)(4326007)(97736004)(5660300001)(606005)(6436002)(77096006)(38730400001)(27001)(101416001)(99286003)(6506006)(7906003)(74316002)(25786008)(3280700002)(7736002)(55016002)(9686003)(92566002)(8666007)(345774005)(229853002)(122556002)(50986999)(54906002)(5890100001)(2900100001)(86362001)(224303003)(105586002)(76176999)(8936002)(54356999)(9326002)(230783001)(6116002)(6306002)(54896002)(102836003)(236005)(3846002)(790700001)(106356001)(81156014)(81166006)(68736007)(189998001)(2950100002)(33656002)(106116001)(224313004)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0448; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB0446C09E1BE1CEE94D43852684780DM2PR09MB0446namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2017 21:31:28.6911 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0448 Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , "sidr-chairs@ietf.org" , "m.waehlisch@fu-berlin.de" , "sidr@ietf.org" Subject: Re: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-bgpsec-protocol-21=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 21:31:36 -0000 --_000_DM2PR09MB0446C09E1BE1CEE94D43852684780DM2PR09MB0446namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWlyamEsDQoNCg0KDQpTb3JyeSBmb3IgdGhlIGRlbGF5IGluIHJlcGx5aW5nLg0KDQpUaGFu ayB5b3UgZm9yIHlvdXIgY2FyZWZ1bCByZXZpZXcsIGFuZCB0aGUgZGV0YWlsZWQgYW5kIGhlbHBm dWwgY29tbWVudHMuDQoNClBsZWFzZSBzZWUgbXkgcmVzcG9uc2VzIGlubGluZSBiZWxvdyBtYXJr ZWQgd2l0aCBbU3JpcmFtXS4NCg0KQ2hhbmdlcyByZWZsZWN0aW5nIHlvdXIgc3VnZ2VzdGlvbnMg YXMgZGlzY3Vzc2VkIGJlbG93DQoNCmhhdmUgYmVlbiBpbmNvcnBvcmF0ZWQgaW4gdGhlIGZvcnRo Y29taW5nIHZlcnNpb24tMjIuDQoNCg0KDQoNCg0KPkZpcnN0LCB0aGFua3MgZm9yIGEgd2VsbCB3 cml0dGVuIGRvY3VtZW50IQ0KDQoNCg0KDQoNClRoYW5rIHlvdS4NCg0KDQoNCg0KDQo+IEEgZmV3 IHF1ZXN0aW9uIG9uIHRoZSBkZXNpZ247IG5vdCB0byBwcm9wb3NlIGNoYW5nZXMgYnV0IEkgd291 bGQgbGlrZSB0byBsZWFybiB0aGUgcmVhc29uIHdoeSB0aGUgZGVzaWduIGlzIGFzIGl0IGlzOg0K DQo+IDEpIFdoeSBkbyB5b3UgbmVlZCB0byBzZW5kIHR3byBkaWZmZXJlbnQgbmVnb3RpYXRpb24g Y2FwYWJpbGl0aWVzIGZvciBlYWNoIGRpcmVjdGlvbiBpbnN0ZWFkIG9mIGp1c3QgdXNpbmcgdHdv IGZsYWdzIGluIHRoZSBzYW1lIGNhcGFiaWxpdHk/DQoNCj4gQW5kIHNpbWlsYXIgd2h5IGRvbid0 IHlvdSBqdXN0IGFubm91bmNlIG11bHRpcGxlIGFkZHJlc3MgZmFtaWxpZXMgaW4gdGhlIHNhbWUg Y2FwYWJpbGl0eSAodXNpbmcgdmFyaWFibGUgbGVuZ3RoKT8NCg0KPg0KDQoNCg0KDQoNCltTcmly YW1dIE9saXZlciBCb3JjaGVydCAoaW1wbGVtZW50ZXIgb2Ygb25lIG9mIHR3byBhdmFpbGFibGUg aW1wbGVtZW50YXRpb25zKSBwb3N0ZWQgaGlzIHRob3VnaHRzIG9uIHRoaXMgZWFybGllciAocmVz cG9uZGluZyB0byBhIHNpbWlsYXIgcXVlc3Rpb24gZnJvbSBSdXNzIEhvdXNsZXkpLiBIZSBoYWQg cHJlZmVyZW5jZSBmb3IgdGhlIHdheSBjdXJyZW50bHkgaXQgaXMgKHBsZWFzZSBzZWUg4oCcVG8g Q29tbWVudCAy4oCdIGluIHRoZSBsaW5rIGJlbG93KToNCg0KDQoNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvc2lkci9jdXJyZW50L21zZzA4MTMwLmh0bWwNCg0KDQoNCg0K DQpbU3JpcmFtXSBBbHNvLCBLZXl1ciBhbmQgSSB0YWxrZWQgYWJvdXQgdGhpcyBpc3N1ZSBpbiBh IHBob25lIGNhbGwgbGFzdCB3ZWVrLiBIZSB3b3VsZCBoYXZlIHByZWZlcnJlZCBjb21iaW5pbmcg dGhvc2UgbWVzc2FnZXMgKGluIGFncmVlbWVudCB3aXRoIHlvdSksIGJ1dCB0aG91Z2h0IGl0IHdh cyBhIG1pbm9yIGlzc3VlIGFuZCBjb3VsZCBiZSBsZWZ0IGFzIGlzIGZvciBub3cuIEhlIGFsc28g c3VnZ2VzdGVkIHRoYXQgaWYsIGRvd24gdGhlIHJvYWQsIHJvdXRlciB2ZW5kb3IgaW1wbGVtZW50 ZXJzIGV4cHJlc3Mgc3Ryb25nIHByZWZlcmVuY2UgZm9yIGl0LCBhIGJpcyBjYW4gYmUgcHVibGlz aGVkLiBSdXNzIGFsc28gdGhvdWdodCBpdCB3YXMgbWlub3IgYW5kIHdhcyBhbHNvIGFncmVlYWJs ZSB0byBsZWF2aW5nIGl0IGFzIGlzLiBQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IHN0aWxsIGZl ZWwgc3Ryb25nbHkuDQoNCg0KDQoNCg0KPiAyKSBXaHkgYXJlIHRoZSBTZWN1cmVfUGF0aCBlbGVt ZW50cyBhbmQgU2lnbmF0dXJlX0Jsb2NrIGJsb2NrcyBub3QgYWxpZ25lZCBidXQgaW4gdHdvIGRp ZmZlcmVudCBsaXN0cyAoZ2l2ZW4gdGhlcmUgaXMgYW5kIG9uZSB0byBvbmUgbWFwcGluZyk/IFdv dWxkbid0IGl0IGJlIGVhc2llciB0byBqdXN0IHVwZGF0ZSBvbmUgbGVuZ3RoIGZpZWxkIChhdCBh IGZpeGVkIHBvc2l0aW9uKSBhbmQgYXR0YWNoZWQgdGhlIG5ldyBpbmZvcm1hdGlvbiBhdCB0aGUg ZW5kPyBPciB0byBhc2sgdGhlIHF1ZXN0aW9uIGRpZmZlcmVudGx5OiB3aHkgaXMgdGhlIGZvcm1h dCBhcyBzaG93biBpbiBmaWd1cmUgOCBub3QgdXNlZCBpbiB0aGUgbWVzc2FnZSBpdHNlbGYgKC0+ dGhpcyBpcyByZWxhdGVkIHRvIFN1cmVzaCdzIHF1ZXN0aW9uKT8NCg0KPg0KDQoNCg0KDQoNCltT cmlyYW1dIFRoZSBzaG9ydCBhbnN3ZXIgaXMgdGhhdCB0aGUgcHJvdG9jb2wgZGVzaWduZXJzIGZl bHQgdGhhdCBpbiB0aGUgYnl0ZXMgc2VudCBvbiB0aGUgd2lyZSwgaXQgbWFkZSBzZW5zZSB0aGF0 IHRoZSB3aG9sZSBTZWN1cmVfUGF0aCBzaG91bGQgYmUgdG9nZXRoZXIgYW5kIHRoZSBzZXQgb2Yg U2lnbmF0dXJlcyBzaG91bGQgYmUgdG9nZXRoZXIuIEZvciBpbnN0YW5jZSwgdGhlbiBpdCBpcyBl YXN5IHRvIGNvbnZlcnQgU2VjdXJlX1BhdGggdG8gQVNfUEFUSCBpZiB0aGUgdXBkYXRlIG5lZWRz IHRvIGJlIGZvcndhcmRlZCB1bnNpZ25lZCB0byBhIG5vbi1CR1BzZWMgcGVlci4gVGhlIFNlY3Vy ZV9QYXRoIGluIGl0cyBlbnRpcmV0eSBpcyBhbHNvIHVzZWQgaW4gdGhlIGNoZWNrcyBwZXJmb3Jt ZWQgaW4gdGhlIGxpc3QgaW4gU2VjdGlvbiA1LjIuDQoNCg0KDQoNCg0KW1NyaXJhbV0gUmVnYXJk aW5nIEZpZ3VyZSA4IChmb3JtYXQgZm9yIHRoZSBkYXRhIHRvIGJlIGhhc2hlZCksIE9saXZlciBv ZmZlcmVkIHRoZSByYXRpb25hbGUgZm9yIGl0IGluIHRoZSBmb2xsb3dpbmcgcG9zdCBiYWNrIHdo ZW4gd2UgZmlyc3QgbWFkZSB0aGUgc3dpdGNoIHRvIHRoaXMgZm9ybWF0LiBNaWNoYWVsIEJhZXIg KGltcGxlbWVudGVyIG9mIHRoZSBvdGhlciBhdmFpbGFibGUgaW1wbGVtZW50YXRpb24pLCBPbGl2 ZXIsIG15c2VsZiwgYW5kIE1hdHQgTGVwaW5za2kgZGlzY3Vzc2VkL3Jldmlld2VkIGl0IGluIGRl dGFpbCBhbmQgdGhlbiB3ZSBwcm9jZWVkZWQgdG8gaW5jbHVkZSBpdCBpbiB0aGUgc3BlY2lmaWNh dGlvbi4NCg0KDQoNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc2lkci84 Ql9lNENOeFFDVUtlWl9BVXpzZG5uMmY1TVUNCg0KDQoNCg0KDQpbU3JpcmFtXSBTdXJlc2ggYW5k IEFsZXhleSBzZWVtZWQgdG8gYXBwcmVjaWF0ZSB0aGUgcmF0aW9uYWxlIHRoYXQgd2FzIGFwcGxp ZWQgZm9yIHRoZSBmb3JtYXQgaW4gRmlndXJlIDggKGFmdGVyIHRoZXkgcmVhZCBPbGl2ZXLigJlz IGV4cGxhbmF0aW9uKToNCg0KDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvc2lkci9jdXJyZW50L21zZzA4MjM3Lmh0bWwNCg0KDQoNCg0KDQo+IFF1ZXN0aW9ucyBvbiBv cGVyYXRpb246DQoNCj4gMSkgc2VjdGlvbiA1IHNheXMgImEgQkdQc2VjIHNwZWFrZXIgTUFZIHRl bXBvcmFyaWx5IGRlZmVyIHZhbGlkYXRpb24gb2YgaW5jb21pbmcgQkdQc2VjIHVwZGF0ZSBtZXNz YWdlcyIuDQoNCj4gRG9lcyB0aGlzIG1lYW4gaXQgaGFzIHRvIHJlbWVtYmVyIGl0cyBzdGF0ZSBi ZWZvcmUgYXBwbHlpbmcgdGhlIHVwZGF0ZSBtZXNzYWdlIHN1Y2ggdGhhdCBpcyBjYW4gcmV2ZXJ0 IHRvIHRoaXMgc3RhdGUgaWYgaXQgbGF0ZXIgZGV0ZWN0cyB0aGF0IGRpZSB1cGRhdGUgbWVzc2Fn ZSB3YXMgbm90IHZhbGlkPyBPciB3aGF0IGFjdGlvbiBpcyBzdXBwb3NlZCB0byBoYXBwZW4gaWYg dGhlIHVwZGF0ZSBtZXNzYWdlIGlzIGRldGVjdGVkIGFzIG5vdCB2YWxpZCBsYXRlciBvbg0KDQoN Cg0KDQoNCltTcmlyYW1dIEl0IGlzIGxlZnQgdXAgdG8gYW4gaW1wbGVtZW50YXRpb24gdGhlIG1l Y2hhbmlzbSBmb3Igc2F2aW5nIHRoZSBzdGF0ZSBhbmQgcmV0dXJuaW5nIHRvIHdoZXJlIGl0IHdh cyBsZWZ0IG9mZi4gSWYgdGhlIHJvdXRlciBkZWZlcnJlZCB2YWxpZGF0aW9uLCBpdCBjb21lcyBi YWNrIGxhdGVyIGFuZCBjb21wbGV0ZXMgdGhlIHZhbGlkYXRpb24uIElmIGFuIHVwZGF0ZSBtZXNz YWdlIGlzIGRldGVjdGVkIG5vdCB2YWxpZCBsYXRlciwgdGhlIGFjdGlvbiB3b3VsZCBiZSBzaW1p bGFyIHRvIHdoYXQgaXMgZG9uZSB3aGVuIHVwZGF0ZSB2YWxpZGl0eSBzdGF0ZSBjaGFuZ2Ugb2Nj dXJzIGR1ZSB0byBhbiBSUEtJIHN0YXRlIGNoYW5nZSwgaS5lLiByZS1ydW4gYmVzdCBwYXRoIHNl bGVjdGlvbiAg4oCTIHNlZSBleGNlcnB0IGJlbG93IChTZWN0aW9uIDUsIHAuMjIpOg0KDQoNCg0K ICAgRm9yIGV4YW1wbGUsIHdoZW4gYSBnaXZlbiBSUEtJIGNlcnRpZmljYXRlIGNlYXNlcyB0byBi ZSB2YWxpZCAoZS5nLiwNCg0KICAgaXQgZXhwaXJlcyBvciBpcyByZXZva2VkKSwgYWxsIHVwZGF0 ZSBtZXNzYWdlcyBjb250YWluaW5nIGEgc2lnbmF0dXJlDQoNCiAgIHdob3NlIFNLSSBtYXRjaGVz IHRoZSBTS0kgaW4gdGhlIGdpdmVuIGNlcnRpZmljYXRlIG11c3QgYmUgcmUtDQoNCiAgIGFzc2Vz c2VkIHRvIGRldGVybWluZSBpZiB0aGV5IGFyZSBzdGlsbCB2YWxpZC4gIElmIHRoaXMgcmVhc3Nl c3NtZW50DQoNCiAgIGRldGVybWluZXMgdGhhdCB0aGUgdmFsaWRpdHkgc3RhdGUgb2YgYW4gdXBk YXRlIGhhcyBjaGFuZ2VkIHRoZW4sDQoNCiAgIGRlcGVuZGluZyBvbiBsb2NhbCBwb2xpY3ksIGl0 IG1heSBiZSBuZWNlc3NhcnkgdG8gcmUtcnVuIGJlc3QgcGF0aA0KDQogICBzZWxlY3Rpb24uDQoN Cg0KDQoNCg0KPiAyKSBzZWMgNC4yIHNheXMgIk5leHQsIHRoZSBCR1BzZWMgc3BlYWtlciBnZW5l cmF0ZXMgb25lIG9yIHR3byBTaWduYXR1cmVfQmxvY2tzLiINCg0KPiBBcmUgeW91IHN1cmUgaXQn cyBhdCBtYXggMj8gSSBndWVzcyB0aGlzIGRlcGVuZHMgb24gdGhlIGV4cGVjdGVkIHVwZGF0ZSBj eWNsZXMgb2YgdGhlIGFsZ29yaXRobSBjb21wYXJlZCB0byB0aGUgZGV2aWNlcy4gR2l2ZW4gdXBk YXRlIGN5Y2xlcyBmb3IgZGV2aWNlcyBjYW4gYmUgdmVyeSBzbG93IGFuZCB1cGRhdGVzIGZvciBh bGdvcml0aG0gY2FuIGJlIGZhc3QgaWYgYW55IHNlY3VyaXR5IHByb2JsZW1zIGFyZSBkZXRlY3Rl ZCwgSSB3b3VsZG4ndCByZWNvbW1lbmQgdG8gbGltaXQgdGhpcyB0byB0d28uDQoNCg0KDQoNCg0K W1NyaXJhbV0gVGhpcyB3YXMgZGlzY3Vzc2VkIGF0IGFuIElFVEYgU0lEUiBtZWV0aW5nIGV4dGVu c2l2ZWx5LCBhbmQgdGhlIFdHIGhhZCBjb25zZW5zdXMgdGhhdCB0d28gU2lnbmF0dXJlX0Jsb2Nr cyB3b3VsZCBiZSBhZGVxdWF0ZS4NCg0KDQoNCj4gMykgSW4gcmVsYXRpb24gdG8gdGhlIGNvbW1l bnQgYWJvdmUsIEknbSBub3QgYSBiaWcgZmFuIG9mIHRoZSBhbGdvIG1pZ3JhdGlvbiBzdHJhdGVn eSBpbiBzZWN0aW9uIDYuMS4gSSB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtIHRoYXQgYWxsIHJvdXRl ciBvbiB0aGUgcGF0aCBuZWVkIHRvIHBvdGVudGlhbGx5IHN1cHBvcnQgdGhlIGFsZ28uIEhvd2V2 ZXIsIHlvdSBkbyBoYXZlIGFuIG5lZ290aWF0aW9uIHBoYXNlLiBTbyB3aHkgZG9uJ3QgeW91IHRo ZSBhZHZlcnRpc2UgdGhlIHNpZ25pbmcgYWxnb3JpdGhtIGluIHRoZSBuZWdvdGlhdGlvbiBjYXBh YmlsaXRpZXM/IEluIHRoaXMgY2FzZSB0aGUgc2VuZGVyIGNvdWxkIGF0IGxlYXN0IGNob29zZSB0 byBvbmx5IHNlbmQgdGhlIG9uZShzKSB0aGF0IGlzL2FyZSBhbHNvIHN1cHBvcnRlZCBieSB0aGUg cmVjZWl2ZXIgb3Igbm90IHVzZSBCR1BzZWMgYXQgYWxsIGlmIHRoZXJlIGlzIG5vIG1hdGNoLiBI b3dldmVyLCBJIGFsc28gdW5kZXJzdGFuZCB0aGF0IGl0IGlzIHByb2JhYmx5IHRvIGxhdGUgdG8g Y2hhbmdlIGFueXRoaW5nIG5vdyBhbmQgaWYgdGhlcmUgaXMgd2cgY29uc2Vuc3VzLCBJJ20gZmlu ZSB3aXRoIHRoYXQuLi4NCg0KDQoNCg0KDQpbU3JpcmFtXSBUaGUgV0cgaGFzIGhhZCBjb25zZW5z dXMgb24gdGhpcyBmb3IgcXVpdGUgc29tZSB0aW1lIG5vdyDigJMgdGhhdCBpbnN0ZWFkIG9mIG5l Z290aWF0aW9uIHVwZnJvbnQsIHRoZSBTaWduYXR1cmVfQmxvY2socykgaW4gdGhlIHVwZGF0ZSBt dXN0IGluZGljYXRlIHdoYXQgYWxnb3JpdGhtKHMpIGlzKGFyZSkgdXNlZC4NCg0KDQoNCg0KDQo+ IDQpIHNlY3Rpb24gOC4xIHNheXMgInRoZSByZWNpcGllbnQgb2YgYSB2YWxpZCBCR1BzZWMgdXBk YXRlIG1lc3NhZ2UgaXMgYXNzdXJlZCB0aGF0IHRoZSB1cGRhdGUgcHJvcGFnYXRlZCB2aWEgdGhl IHNlcXVlbmNlIG9mIEFTZXMgbGlzdGVkIGluIHRoZSBTZWN1cmVfUGF0aCBwb3J0aW9uIG9mIHRo ZSBCR1BzZWNfUGF0aCBhdHRyaWJ1dGUuIg0KDQo+IElzIHRoYXQgdHJ1ZT8gSXQgaXMgYXNzdXJl ZCB0aGF0IGF0IGxlYXN0IHRoZXNlIEFTZXMgaGF2ZSBiZWVuIGNyb3NzZWQgYnV0IHRoZXJlIG1p Z2h0IGhhdmUgYmVlbiBvdGhlcnMgb24gdGhlIHBhdGggdGhhdCBkaWQgbm90IHNpZ24gdGhlIEJH UHNlY19QYXRoIGF0dHJpYnV0ZSwgbm8/DQoNCg0KDQoNCg0KW1NyaXJhbV0gWWVzLCBpdCBpcyB0 cnVlLiBFYWNoIEFTIGluIHRoZSBwYXRoIE1VU1Qgc2lnbiB0byB0aGUgbmV4dCBBUyAoVGFyZ2V0 IEFTKS4gU2VjdGlvbiAzLjEgc2F5czoNCg0KDQoNCg0KDQogICBUaGUgU2VjdXJlX1BhdGggY29u dGFpbnMgb25lIFNlY3VyZV9QYXRoIFNlZ21lbnQgKHNlZSBGaWd1cmUgNSkgZm9yDQoNCiAgIGVh Y2ggQXV0b25vbW91cyBTeXN0ZW0gaW4gdGhlIHBhdGggdG8gdGhlIG9yaWdpbmF0aW5nIEFTIG9m IHRoZQ0KDQogICBwcmVmaXggc3BlY2lmaWVkIGluIHRoZSB1cGRhdGUgbWVzc2FnZS4NCg0KDQoN Cg0KDQpbU3JpcmFtXSBBbHNvLCBTZWN0aW9uIDMuMiBzYXlzOg0KDQoNCg0KDQoNCiAgIEEgU2ln bmF0dXJlX0Jsb2NrIGluIEZpZ3VyZSA2IGhhcyBleGFjdGx5IG9uZSBTaWduYXR1cmUgU2VnbWVu dCAoc2VlDQoNCiAgIEZpZ3VyZSA3KSBmb3IgZWFjaCBTZWN1cmVfUGF0aCBTZWdtZW50IGluIHRo ZSBTZWN1cmVfUGF0aCBwb3J0aW9uIG9mDQoNCiAgIHRoZSBCR1BzZWNfUGF0aCBBdHRyaWJ1dGUu DQoNCg0KDQoNCg0KDQoNCltTcmlyYW1dIFRoZSBmb2xsb3dpbmcgY2hlY2sgbGlzdGVkIGluIFNl Y3Rpb24gNS4yIG1ha2UgaXQgY2xlYXIgYXMgd2VsbDoNCg0KDQoNCg0KDQogICAzLiAgQ2hlY2sg dGhhdCBlYWNoIFNpZ25hdHVyZV9CbG9jayBjb250YWlucyBvbmUgU2lnbmF0dXJlIHNlZ21lbnQN Cg0KICAgICAgIGZvciBlYWNoIFNlY3VyZV9QYXRoIFNlZ21lbnQgaW4gdGhlIFNlY3VyZV9QYXRo IHBvcnRpb24gb2YgdGhlDQoNCiAgICAgICBCR1BzZWNfUGF0aCBhdHRyaWJ1dGUuICAoTm90ZSB0 aGF0IHRoZSBlbnRpcmV0eSBvZiBlYWNoDQoNCiAgICAgICBTaWduYXR1cmVfQmxvY2sgbXVzdCBi ZSBjaGVja2VkIHRvIGVuc3VyZSB0aGF0IGl0IGlzIHdlbGwgZm9ybWVkLA0KDQogICAgICAgZXZl biB0aG91Z2ggdGhlIHZhbGlkYXRpb24gcHJvY2VzcyBtYXkgdGVybWluYXRlIGJlZm9yZSBhbGwN Cg0KICAgICAgIHNpZ25hdHVyZXMgYXJlIGNyeXB0b2dyYXBoaWNhbGx5IHZlcmlmaWVkLikNCg0K DQoNCg0KDQo+IDUpIElzIGl0IHJlYWxseSBuZWNlc3NhcnkgdG8gY3JlYXRlIHJlZ2lzdHJpZXMg Zm9yICJCR1BzZWMgQ2FwYWJpbGl0eSINCg0KPiBhbmQgIkJHUHNlY19QYXRoIEZsYWdzIj8gR2l2 ZW4gdGhpcyBpcyBhIHJlYWxseSBzbWFsbCBudW1iZXIgb2YgYml0cy9mbGFncywgSSB0aGluayBu ZXcgUkZDcyB0aGF0IHVwZGF0ZSB0aGlzIFJGQyBhcmUgZW5vdWdoIHRvIGRlZmluZSBhIG5ldyB1 c2UgZm9yIHRoZXNlIHNvIGZhciB1bnVzZWQgYml0cy4NCg0KDQoNCg0KDQpbU3JpcmFtXSBUaGlz IGNhbWUgdXAgaW4gdGhlIFJ1c3MgSG91c2xleeKAmXMgcmV2aWV3IGFsc28uIEJ1dCBsYXRlciBo ZSBhZ3JlZWQgaXQgd2FzIE9LIHRvIGluY2x1ZGUgdGhlc2UuIEhlIG9mZmVyZWQgc29tZSBzdWdn ZXN0aW9ucyBmb3IgY2xhcmlmeWluZyB0aGUgYml0cyAoZmllbGRzKSB0aGF0IHdlcmUgYWxyZWFk eSBmdWxseSBzcGVjaWZpZWQgaW4gdGhlIHByb3RvY29sLCBhbmQgaGVuY2UgZGlkbuKAmXQgbmVl ZCBhbnkgSUFOQSBjb25zaWRlcmF0aW9uLiBIaXMgc3VnZ2VzdGlvbnMgd2VyZSBpbmNvcnBvcmF0 ZWQgaW4gdGhlIElBTkEgc2VjdGlvbiBpbiB2ZXJzaW9uIDIxLg0KDQoNCg0KDQoNCj4NCg0KPiBG dXJ0aGVyLCBlZGl0b3JpYWwgcHJvcG9zYWxzOg0KDQo+IDEpIEkgd291bGQgcHJvcG9zZSB0byBh ZGQgdGhlIENvbmZlZF9TZWdtZW50IGZsYWcgaW4gZmlndXJlIDUgKGFuZCBjYWxsIHRoZSByZW1h aW5pbmcgZmxhZyBmaWVsZCAncmVzZXJ2ZWQnKQ0KDQoNCg0KDQoNCltTcmlyYW1dIEdvb2QgaWRl YS4gSSBoYXZlIG1hZGUgdGhlIGNoYW5nZSBpbiB0aGUgZm9ydGhjb21pbmcgdmVyc2lvbi0yMi4N Cg0KDQoNCg0KDQoNCg0KPiAyKSBNYXliZSBleHBsYWluIEFkai1SSUItSW4gb3IgZ2l2ZSBhIHJl ZmVyZW5jZSB0byBSRkNyZmM0MjcxIHNlY3Rpb24gMS4xDQoNCj4NCg0KDQoNCg0KDQpbU3JpcmFt XSBEb25lLiBJ4oCZdmUgcHJvdmlkZWQgdGhlIHJlZmVyZW5jZSB0byBSRkM0MjcxLg0KDQoNCg0K DQoNClNyaXJhbQ0KDQoNCg0KDQoNCg0K --_000_DM2PR09MB0446C09E1BE1CEE94D43852684780DM2PR09MB0446namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IaSBN aXJqYSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5Tb3JyeSBmb3IgdGhlIGRlbGF5IGluIHJlcGx5aW5nLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhbmsgeW91IGZvciB5b3VyIGNh cmVmdWwgcmV2aWV3LCBhbmQgdGhlIGRldGFpbGVkIGFuZCBoZWxwZnVsIGNvbW1lbnRzLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGxlYXNlIHNlZSBteSByZXNwb25z ZXMgaW5saW5lIGJlbG93IG1hcmtlZCB3aXRoIFtTcmlyYW1dLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Q2hhbmdlcyByZWZsZWN0aW5nIHlvdXIgc3VnZ2VzdGlvbnMg YXMgZGlzY3Vzc2VkIGJlbG93PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5oYXZlIGJlZW4gaW5jb3Jwb3JhdGVkIGluIHRoZSBmb3J0aGNvbWluZyB2ZXJzaW9uLTIyLiA8 bzpwPg0KPC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtGaXJzdCwgdGhhbmtzIGZvciBhIHdlbGwgd3JpdHRl biBkb2N1bWVudCE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFuayB5b3UuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBBIGZldyBxdWVzdGlvbiBvbiB0aGUgZGVzaWduOyBub3QgdG8gcHJvcG9zZSBj aGFuZ2VzIGJ1dCBJIHdvdWxkIGxpa2UgdG8gbGVhcm4gdGhlIHJlYXNvbiB3aHkgdGhlIGRlc2ln biBpcyBhcyBpdCBpczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgMSkgV2h5IGRvIHlvdSBuZWVkIHRvIHNlbmQgdHdvIGRpZmZlcmVudCBuZWdvdGlhdGlvbiBj YXBhYmlsaXRpZXMgZm9yIGVhY2ggZGlyZWN0aW9uIGluc3RlYWQgb2YganVzdCB1c2luZyB0d28g ZmxhZ3MgaW4gdGhlIHNhbWUgY2FwYWJpbGl0eT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgQW5kIHNpbWlsYXIgd2h5IGRvbid0IHlvdSBqdXN0IGFubm91bmNl IG11bHRpcGxlIGFkZHJlc3MgZmFtaWxpZXMgaW4gdGhlIHNhbWUgY2FwYWJpbGl0eSAodXNpbmcg dmFyaWFibGUgbGVuZ3RoKT8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPltTcmlyYW1dIE9saXZlciBCb3JjaGVy dCAoaW1wbGVtZW50ZXIgb2Ygb25lIG9mIHR3byBhdmFpbGFibGUgaW1wbGVtZW50YXRpb25zKSBw b3N0ZWQgaGlzIHRob3VnaHRzIG9uIHRoaXMgZWFybGllciAocmVzcG9uZGluZyB0byBhIHNpbWls YXIgcXVlc3Rpb24gZnJvbSBSdXNzIEhvdXNsZXkpLiBIZSBoYWQgcHJlZmVyZW5jZSBmb3IgdGhl IHdheSBjdXJyZW50bHkgaXQgaXMgKHBsZWFzZSBzZWUg4oCcVG8gQ29tbWVudA0KIDLigJ0gaW4g dGhlIGxpbmsgYmVsb3cpOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpZHIvY3VycmVudC9tc2cwODEz MC5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpZHIvY3VycmVu dC9tc2cwODEzMC5odG1sPC9hPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+W1NyaXJhbV0gQWxzbywg S2V5dXIgYW5kIEkgdGFsa2VkIGFib3V0IHRoaXMgaXNzdWUgaW4gYSBwaG9uZSBjYWxsIGxhc3Qg d2Vlay4gSGUgd291bGQgaGF2ZSBwcmVmZXJyZWQgY29tYmluaW5nIHRob3NlIG1lc3NhZ2VzIChp biBhZ3JlZW1lbnQgd2l0aCB5b3UpLCBidXQgdGhvdWdodCBpdCB3YXMgYSBtaW5vciBpc3N1ZSBh bmQgY291bGQgYmUgbGVmdCBhcyBpcyBmb3Igbm93LiBIZSBhbHNvIHN1Z2dlc3RlZA0KIHRoYXQg aWYsIGRvd24gdGhlIHJvYWQsIHJvdXRlciB2ZW5kb3IgaW1wbGVtZW50ZXJzIGV4cHJlc3Mgc3Ry b25nIHByZWZlcmVuY2UgZm9yIGl0LCBhIGJpcyBjYW4gYmUgcHVibGlzaGVkLiBSdXNzIGFsc28g dGhvdWdodCBpdCB3YXMgbWlub3IgYW5kIHdhcyBhbHNvIGFncmVlYWJsZSB0byBsZWF2aW5nIGl0 IGFzIGlzLiBQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IHN0aWxsIGZlZWwgc3Ryb25nbHkuJm5i c3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDIpIFdoeSBhcmUgdGhlIFNlY3Vy ZV9QYXRoIGVsZW1lbnRzIGFuZCBTaWduYXR1cmVfQmxvY2sgYmxvY2tzIG5vdCBhbGlnbmVkIGJ1 dCBpbiB0d28gZGlmZmVyZW50IGxpc3RzIChnaXZlbiB0aGVyZSBpcyBhbmQgb25lIHRvIG9uZSBt YXBwaW5nKT8gV291bGRuJ3QgaXQgYmUgZWFzaWVyIHRvIGp1c3QgdXBkYXRlIG9uZSBsZW5ndGgg ZmllbGQgKGF0IGEgZml4ZWQgcG9zaXRpb24pIGFuZCBhdHRhY2hlZA0KIHRoZSBuZXcgaW5mb3Jt YXRpb24gYXQgdGhlIGVuZD8gT3IgdG8gYXNrIHRoZSBxdWVzdGlvbiBkaWZmZXJlbnRseTogd2h5 IGlzIHRoZSBmb3JtYXQgYXMgc2hvd24gaW4gZmlndXJlIDggbm90IHVzZWQgaW4gdGhlIG1lc3Nh Z2UgaXRzZWxmICgtJmd0O3RoaXMgaXMgcmVsYXRlZCB0byBTdXJlc2gncyBxdWVzdGlvbik/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPltTcmlyYW1dIFRoZSBzaG9ydCBhbnN3ZXIgaXMgdGhhdCB0aGUgcHJvdG9jb2wgZGVz aWduZXJzIGZlbHQgdGhhdCBpbiB0aGUgYnl0ZXMgc2VudCBvbiB0aGUgd2lyZSwgaXQgbWFkZSBz ZW5zZSB0aGF0IHRoZSB3aG9sZSBTZWN1cmVfUGF0aCBzaG91bGQgYmUgdG9nZXRoZXIgYW5kIHRo ZSBzZXQgb2YgU2lnbmF0dXJlcyBzaG91bGQgYmUgdG9nZXRoZXIuIEZvciBpbnN0YW5jZSwgdGhl biBpdCBpcyBlYXN5DQogdG8gY29udmVydCBTZWN1cmVfUGF0aCB0byBBU19QQVRIIGlmIHRoZSB1 cGRhdGUgbmVlZHMgdG8gYmUgZm9yd2FyZGVkIHVuc2lnbmVkIHRvIGEgbm9uLUJHUHNlYyBwZWVy LiBUaGUgU2VjdXJlX1BhdGggaW4gaXRzIGVudGlyZXR5IGlzIGFsc28gdXNlZCBpbiB0aGUgY2hl Y2tzIHBlcmZvcm1lZCBpbiB0aGUgbGlzdCBpbiBTZWN0aW9uIDUuMi48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+W1NyaXJhbV0gUmVnYXJkaW5nIEZpZ3VyZSA4IChmb3JtYXQgZm9yIHRoZSBkYXRhIHRv IGJlIGhhc2hlZCksIE9saXZlciBvZmZlcmVkIHRoZSByYXRpb25hbGUgZm9yIGl0IGluIHRoZSBm b2xsb3dpbmcgcG9zdCBiYWNrIHdoZW4gd2UgZmlyc3QgbWFkZSB0aGUgc3dpdGNoIHRvIHRoaXMg Zm9ybWF0LiBNaWNoYWVsIEJhZXIgKGltcGxlbWVudGVyIG9mIHRoZSBvdGhlciBhdmFpbGFibGUg aW1wbGVtZW50YXRpb24pLA0KIE9saXZlciwgbXlzZWxmLCBhbmQgTWF0dCBMZXBpbnNraSBkaXNj dXNzZWQvcmV2aWV3ZWQgaXQgaW4gZGV0YWlsIGFuZCB0aGVuIHdlIHByb2NlZWRlZCB0byBpbmNs dWRlIGl0IGluIHRoZSBzcGVjaWZpY2F0aW9uLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc2lkci84 Ql9lNENOeFFDVUtlWl9BVXpzZG5uMmY1TVUiPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvc2lkci84Ql9lNENOeFFDVUtlWl9BVXpzZG5uMmY1TVU8L2E+DQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5bU3JpcmFtXSBTdXJlc2ggYW5kIEFsZXhleSBzZWVtZWQgdG8gYXBwcmVjaWF0 ZSB0aGUgcmF0aW9uYWxlIHRoYXQgd2FzIGFwcGxpZWQgZm9yIHRoZSBmb3JtYXQgaW4gRmlndXJl IDggKGFmdGVyIHRoZXkgcmVhZCBPbGl2ZXLigJlzIGV4cGxhbmF0aW9uKTo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9zaWRyL2N1cnJlbnQvbXNnMDgyMzcuaHRtbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9zaWRyL2N1cnJlbnQvbXNnMDgyMzcuaHRtbDwvYT4NCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgUXVlc3Rpb25zIG9uIG9wZXJhdGlv bjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgMSkgc2VjdGlv biA1IHNheXMgJnF1b3Q7YSBCR1BzZWMgc3BlYWtlciBNQVkgdGVtcG9yYXJpbHkgZGVmZXIgdmFs aWRhdGlvbiBvZiBpbmNvbWluZyBCR1BzZWMgdXBkYXRlIG1lc3NhZ2VzJnF1b3Q7Lg0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IERvZXMgdGhpcyBtZWFuIGl0 IGhhcyB0byByZW1lbWJlciBpdHMgc3RhdGUgYmVmb3JlIGFwcGx5aW5nIHRoZSB1cGRhdGUgbWVz c2FnZSBzdWNoIHRoYXQgaXMgY2FuIHJldmVydCB0byB0aGlzIHN0YXRlIGlmIGl0IGxhdGVyIGRl dGVjdHMgdGhhdCBkaWUgdXBkYXRlIG1lc3NhZ2Ugd2FzIG5vdCB2YWxpZD8gT3Igd2hhdCBhY3Rp b24gaXMgc3VwcG9zZWQgdG8gaGFwcGVuIGlmIHRoZSB1cGRhdGUgbWVzc2FnZQ0KIGlzIGRldGVj dGVkIGFzIG5vdCB2YWxpZCBsYXRlciBvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPltTcmlyYW1dIEl0 IGlzIGxlZnQgdXAgdG8gYW4gaW1wbGVtZW50YXRpb24gdGhlIG1lY2hhbmlzbSBmb3Igc2F2aW5n IHRoZSBzdGF0ZSBhbmQgcmV0dXJuaW5nIHRvIHdoZXJlIGl0IHdhcyBsZWZ0IG9mZi4gSWYgdGhl IHJvdXRlciBkZWZlcnJlZCB2YWxpZGF0aW9uLCBpdCBjb21lcyBiYWNrIGxhdGVyIGFuZCBjb21w bGV0ZXMgdGhlIHZhbGlkYXRpb24uIElmIGFuIHVwZGF0ZSBtZXNzYWdlIGlzIGRldGVjdGVkDQog bm90IHZhbGlkIGxhdGVyLCB0aGUgYWN0aW9uIHdvdWxkIGJlIHNpbWlsYXIgdG8gd2hhdCBpcyBk b25lIHdoZW4gdXBkYXRlIHZhbGlkaXR5IHN0YXRlIGNoYW5nZSBvY2N1cnMgZHVlIHRvIGFuIFJQ S0kgc3RhdGUgY2hhbmdlLCBpLmUuIHJlLXJ1biBiZXN0IHBhdGggc2VsZWN0aW9uJm5ic3A7IOKA kyBzZWUgZXhjZXJwdCBiZWxvdyAoU2VjdGlvbiA1LCBwLjIyKTo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEZvciBleGFtcGxlLCB3aGVuIGEgZ2l2ZW4gUlBLSSBj ZXJ0aWZpY2F0ZSBjZWFzZXMgdG8gYmUgdmFsaWQgKGUuZy4sPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgaXQgZXhwaXJlcyBvciBpcyByZXZva2Vk KSwgYWxsIHVwZGF0ZSBtZXNzYWdlcyBjb250YWluaW5nIGEgc2lnbmF0dXJlPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgd2hvc2UgU0tJIG1hdGNo ZXMgdGhlIFNLSSBpbiB0aGUgZ2l2ZW4gY2VydGlmaWNhdGUgbXVzdCBiZSByZS08bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBhc3Nlc3NlZCB0byBk ZXRlcm1pbmUgaWYgdGhleSBhcmUgc3RpbGwgdmFsaWQuJm5ic3A7IElmIHRoaXMgcmVhc3Nlc3Nt ZW50PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg ZGV0ZXJtaW5lcyB0aGF0IHRoZSB2YWxpZGl0eSBzdGF0ZSBvZiBhbiB1cGRhdGUgaGFzIGNoYW5n ZWQgdGhlbiw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyBkZXBlbmRpbmcgb24gbG9jYWwgcG9saWN5LCBpdCBtYXkgYmUgbmVjZXNzYXJ5IHRvIHJl LXJ1biBiZXN0IHBhdGg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyBzZWxlY3Rpb24uJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgMikg c2VjIDQuMiBzYXlzICZxdW90O05leHQsIHRoZSBCR1BzZWMgc3BlYWtlciBnZW5lcmF0ZXMgb25l IG9yIHR3byBTaWduYXR1cmVfQmxvY2tzLiZxdW90Ow0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEFyZSB5b3Ugc3VyZSBpdCdzIGF0IG1heCAyPyBJIGd1ZXNz IHRoaXMgZGVwZW5kcyBvbiB0aGUgZXhwZWN0ZWQgdXBkYXRlIGN5Y2xlcyBvZiB0aGUgYWxnb3Jp dGhtIGNvbXBhcmVkIHRvIHRoZSBkZXZpY2VzLiBHaXZlbiB1cGRhdGUgY3ljbGVzIGZvciBkZXZp Y2VzIGNhbiBiZSB2ZXJ5IHNsb3cgYW5kIHVwZGF0ZXMgZm9yIGFsZ29yaXRobSBjYW4gYmUgZmFz dCBpZiBhbnkgc2VjdXJpdHkgcHJvYmxlbXMNCiBhcmUgZGV0ZWN0ZWQsIEkgd291bGRuJ3QgcmVj b21tZW5kIHRvIGxpbWl0IHRoaXMgdG8gdHdvLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPltTcmlyYW1d IFRoaXMgd2FzIGRpc2N1c3NlZCBhdCBhbiBJRVRGIFNJRFIgbWVldGluZyBleHRlbnNpdmVseSwg YW5kIHRoZSBXRyBoYWQgY29uc2Vuc3VzIHRoYXQgdHdvIFNpZ25hdHVyZV9CbG9ja3Mgd291bGQg YmUgYWRlcXVhdGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAzKSBJbiByZWxhdGlvbiB0byB0aGUgY29t bWVudCBhYm92ZSwgSSdtIG5vdCBhIGJpZyBmYW4gb2YgdGhlIGFsZ28gbWlncmF0aW9uIHN0cmF0 ZWd5IGluIHNlY3Rpb24gNi4xLiBJIHVuZGVyc3RhbmQgdGhlIHByb2JsZW0gdGhhdCBhbGwgcm91 dGVyIG9uIHRoZSBwYXRoIG5lZWQgdG8gcG90ZW50aWFsbHkgc3VwcG9ydCB0aGUgYWxnby4gSG93 ZXZlciwgeW91IGRvIGhhdmUgYW4gbmVnb3RpYXRpb24gcGhhc2UuDQogU28gd2h5IGRvbid0IHlv dSB0aGUgYWR2ZXJ0aXNlIHRoZSBzaWduaW5nIGFsZ29yaXRobSBpbiB0aGUgbmVnb3RpYXRpb24g Y2FwYWJpbGl0aWVzPyBJbiB0aGlzIGNhc2UgdGhlIHNlbmRlciBjb3VsZCBhdCBsZWFzdCBjaG9v c2UgdG8gb25seSBzZW5kIHRoZSBvbmUocykgdGhhdCBpcy9hcmUgYWxzbyBzdXBwb3J0ZWQgYnkg dGhlIHJlY2VpdmVyIG9yIG5vdCB1c2UgQkdQc2VjIGF0IGFsbCBpZiB0aGVyZSBpcyBubyBtYXRj aC4gSG93ZXZlciwgSQ0KIGFsc28gdW5kZXJzdGFuZCB0aGF0IGl0IGlzIHByb2JhYmx5IHRvIGxh dGUgdG8gY2hhbmdlIGFueXRoaW5nIG5vdyBhbmQgaWYgdGhlcmUgaXMgd2cgY29uc2Vuc3VzLCBJ J20gZmluZSB3aXRoIHRoYXQuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5bU3JpcmFtXSBUaGUgV0cg aGFzIGhhZCBjb25zZW5zdXMgb24gdGhpcyBmb3IgcXVpdGUgc29tZSB0aW1lIG5vdyDigJMgdGhh dCBpbnN0ZWFkIG9mIG5lZ290aWF0aW9uIHVwZnJvbnQsIHRoZSBTaWduYXR1cmVfQmxvY2socykg aW4gdGhlIHVwZGF0ZSBtdXN0IGluZGljYXRlIHdoYXQgYWxnb3JpdGhtKHMpIGlzKGFyZSkgdXNl ZC4mbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDQp IHNlY3Rpb24gOC4xIHNheXMgJnF1b3Q7dGhlIHJlY2lwaWVudCBvZiBhIHZhbGlkIEJHUHNlYyB1 cGRhdGUgbWVzc2FnZSBpcyBhc3N1cmVkIHRoYXQgdGhlIHVwZGF0ZSBwcm9wYWdhdGVkIHZpYSB0 aGUgc2VxdWVuY2Ugb2YgQVNlcyBsaXN0ZWQgaW4gdGhlIFNlY3VyZV9QYXRoIHBvcnRpb24gb2Yg dGhlIEJHUHNlY19QYXRoIGF0dHJpYnV0ZS4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgSXMgdGhhdCB0cnVlPyBJdCBpcyBhc3N1cmVkIHRoYXQgYXQg bGVhc3QgdGhlc2UgQVNlcyBoYXZlIGJlZW4gY3Jvc3NlZCBidXQgdGhlcmUgbWlnaHQgaGF2ZSBi ZWVuIG90aGVycyBvbiB0aGUgcGF0aCB0aGF0IGRpZCBub3Qgc2lnbiB0aGUgQkdQc2VjX1BhdGgg YXR0cmlidXRlLCBubz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5bU3JpcmFtXSBZZXMsIGl0IGlzIHRy dWUuIEVhY2ggQVMgaW4gdGhlIHBhdGggTVVTVCBzaWduIHRvIHRoZSBuZXh0IEFTIChUYXJnZXQg QVMpLiBTZWN0aW9uIDMuMSBzYXlzOg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 IFRoZSBTZWN1cmVfUGF0aCBjb250YWlucyBvbmUgU2VjdXJlX1BhdGggU2VnbWVudCAoc2VlIEZp Z3VyZSA1KSBmb3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyBlYWNoIEF1dG9ub21vdXMgU3lzdGVtIGluIHRoZSBwYXRoIHRvIHRoZSBvcmlnaW5h dGluZyBBUyBvZiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyBwcmVmaXggc3BlY2lmaWVkIGluIHRoZSB1cGRhdGUgbWVzc2FnZS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5bU3JpcmFtXSBBbHNvLCBTZWN0aW9uIDMuMiBzYXlzOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyBBIFNpZ25hdHVyZV9CbG9jayBpbiBGaWd1cmUgNiBoYXMg ZXhhY3RseSBvbmUgU2lnbmF0dXJlIFNlZ21lbnQgKHNlZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEZpZ3VyZSA3KSBmb3IgZWFjaCBTZWN1cmVf UGF0aCBTZWdtZW50IGluIHRoZSBTZWN1cmVfUGF0aCBwb3J0aW9uIG9mPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgdGhlIEJHUHNlY19QYXRoIEF0 dHJpYnV0ZS4mbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5bU3JpcmFtXSBUaGUgZm9sbG93aW5nIGNoZWNrIGxp c3RlZCBpbiBTZWN0aW9uIDUuMiBtYWtlIGl0IGNsZWFyIGFzIHdlbGw6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7IDMuJm5ic3A7IENoZWNrIHRoYXQgZWFjaCBTaWduYXR1cmVfQmxv Y2sgY29udGFpbnMgb25lIFNpZ25hdHVyZSBzZWdtZW50PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZm9y IGVhY2ggU2VjdXJlX1BhdGggU2VnbWVudCBpbiB0aGUgU2VjdXJlX1BhdGggcG9ydGlvbiBvZiB0 aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCR1BzZWNfUGF0aCBhdHRyaWJ1dGUuJm5ic3A7IChOb3Rl IHRoYXQgdGhlIGVudGlyZXR5IG9mIGVhY2g8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTaWduYXR1cmVf QmxvY2sgbXVzdCBiZSBjaGVja2VkIHRvIGVuc3VyZSB0aGF0IGl0IGlzIHdlbGwgZm9ybWVkLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGV2ZW4gdGhvdWdoIHRoZSB2YWxpZGF0aW9uIHByb2Nlc3MgbWF5 IHRlcm1pbmF0ZSBiZWZvcmUgYWxsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2lnbmF0dXJlcyBhcmUg Y3J5cHRvZ3JhcGhpY2FsbHkgdmVyaWZpZWQuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgNSkg SXMgaXQgcmVhbGx5IG5lY2Vzc2FyeSB0byBjcmVhdGUgcmVnaXN0cmllcyBmb3IgJnF1b3Q7QkdQ c2VjIENhcGFiaWxpdHkmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgYW5kICZxdW90O0JHUHNlY19QYXRoIEZsYWdzJnF1b3Q7PyBHaXZlbiB0aGlzIGlz IGEgcmVhbGx5IHNtYWxsIG51bWJlciBvZiBiaXRzL2ZsYWdzLCBJIHRoaW5rIG5ldyBSRkNzIHRo YXQgdXBkYXRlIHRoaXMgUkZDIGFyZSBlbm91Z2ggdG8gZGVmaW5lIGEgbmV3IHVzZSBmb3IgdGhl c2Ugc28gZmFyIHVudXNlZCBiaXRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPltTcmlyYW1dIFRoaXMg Y2FtZSB1cCBpbiB0aGUgUnVzcyBIb3VzbGV54oCZcyByZXZpZXcgYWxzby4gQnV0IGxhdGVyIGhl IGFncmVlZCBpdCB3YXMgT0sgdG8gaW5jbHVkZSB0aGVzZS4gSGUgb2ZmZXJlZCBzb21lIHN1Z2dl c3Rpb25zIGZvciBjbGFyaWZ5aW5nIHRoZSBiaXRzIChmaWVsZHMpIHRoYXQgd2VyZSBhbHJlYWR5 IGZ1bGx5IHNwZWNpZmllZCBpbiB0aGUgcHJvdG9jb2wsIGFuZCBoZW5jZSBkaWRu4oCZdA0KIG5l ZWQgYW55IElBTkEgY29uc2lkZXJhdGlvbi4gSGlzIHN1Z2dlc3Rpb25zIHdlcmUgaW5jb3Jwb3Jh dGVkIGluIHRoZSBJQU5BIHNlY3Rpb24gaW4gdmVyc2lvbiAyMS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBGdXJ0 aGVyLCBlZGl0b3JpYWwgcHJvcG9zYWxzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAxKSBJIHdvdWxkIHByb3Bvc2UgdG8gYWRkIHRoZSBDb25mZWRfU2VnbWVu dCBmbGFnIGluIGZpZ3VyZSA1IChhbmQgY2FsbCB0aGUgcmVtYWluaW5nIGZsYWcgZmllbGQgJ3Jl c2VydmVkJyk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5bU3JpcmFtXSBHb29kIGlkZWEuIEkgaGF2ZSBt YWRlIHRoZSBjaGFuZ2UgaW4gdGhlIGZvcnRoY29taW5nIHZlcnNpb24tMjIuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IDIpIE1heWJlIGV4cGxhaW4gQWRqLVJJQi1JbiBvciBnaXZlIGEgcmVmZXJlbmNlIHRvIFJG Q3JmYzQyNzEgc2VjdGlvbiAxLjE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+W1NyaXJhbV0gRG9uZS4gSeKAmXZlIHByb3Zp ZGVkIHRoZSByZWZlcmVuY2UgdG8gUkZDNDI3MS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TcmlyYW08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_DM2PR09MB0446C09E1BE1CEE94D43852684780DM2PR09MB0446namp_-- From nobody Sat Jan 14 08:51:20 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E3612A096 for ; Sat, 14 Jan 2017 08:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 Wc24lzXrJf5K for ; Sat, 14 Jan 2017 08:51:16 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA53712A093 for ; Sat, 14 Jan 2017 08:51:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15688; q=dns/txt; s=iport; t=1484412676; x=1485622276; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=sEOUw25Mz6Mplx6vqxFgZF/RQhOHJWtualL5w0t024k=; b=M+x6NC12yBa2A/foAxeHGIfydMun2xQjlAN3JZHI91nIxFgPmvk3++fH nDAWf5UEeMuMKdxHobW88XCo1opnz0ZopkPBh5PWQjei5X+5YPLlAfjAP NL2QZN7Ap6VO3zcc6o166yNYxY8RAkHa4BbD3jp0n9XLlbiTky4u5vvto M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAQDeVXpY/5RdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9KAQEBAQEfX4EJB4NKigeRdZAghSuCCx8BCoV4AhqBfj8YAQI?= =?us-ascii?q?BAQEBAQEBYyiEagIEAQEhCkEbAgEGAg4xAwICAiULFBECBAESCYh6DpMKnU6CJ?= =?us-ascii?q?SuJXgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GRYICCIJdh04tgjEFjyOGDIYLAZF?= =?us-ascii?q?egXeOdogailEBHziBRBUYIhABhiFzAYgMgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,228,1477958400"; d="scan'208,217";a="371852259" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jan 2017 16:51:15 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v0EGpFAn008143 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 14 Jan 2017 16:51:15 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 14 Jan 2017 10:51:14 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Sat, 14 Jan 2017 10:51:14 -0600 From: "Alvaro Retana (aretana)" To: Rob Austein , "sidr@ietf.org" Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-rfc6810-bis-08.txt Thread-Index: AQHSaT99NUKiLuV0+0Cz5dcadcVtWaEuE+yAgAomZQA= Date: Sat, 14 Jan 2017 16:51:14 +0000 Message-ID: <9982103D-AF45-4784-B36C-266BC314641E@cisco.com> References: <148383243975.2763.15066568719585600300.idtracker@ietfa.amsl.com> <20170107235109.A11784608565@minas-ithil.hactrn.net> In-Reply-To: <20170107235109.A11784608565@minas-ithil.hactrn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.11.68] Content-Type: multipart/alternative; boundary="_000_9982103DAF454784B36C266BC314641Eciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-rfc6810-bis-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 16:51:19 -0000 --_000_9982103DAF454784B36C266BC314641Eciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iOg0KDQpUaGFua3MgZm9yIHRoZSB1cGRhdGUhICBJ4oCZbSBzdGFydGluZyB0aGUgSUVURiBM YXN0IENhbGwuDQoNCkkgaGF2ZSB0d28gY29tbWVudHMgdGhhdCByZXN1bHQgZnJvbSBub3QgT2Jz b2xldGluZyBSRkM2ODEwOg0KDQoNCjEuICAgICAgIElmIHRoaXMgZG9jdW1lbnQgaXMgbm90IE9i c29sZXRpbmcgUkZDNjgxMCwgdGhlbiBjbGFyaWZ5aW5nIHRoZSB0aXRsZSB3b3VsZCBhdm9pZCBj b25mdXNpb24gZnJvbSBoYXZpbmcgMiBSRkNzIHdpdGggdGhlIHNhbWUgbmFtZS4gIE15IHN1Z2dl c3Rpb24gaXMgdG8gY2hhbmdlIHRoZSB0aXRsZSBvZiB0aGlzIGRvY3VtZW50IHRvIOKAnFRoZSBS ZXNvdXJjZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIChSUEtJKSB0byBSb3V0ZXIgUHJvdG9j b2wsIFZlcnNpb24gMeKAnS4NCg0KMi4gICAgICAgVGhlIElBTkEgQ29uc2lkZXJhdGlvbnMgc2Vj dGlvbiBpcyBub3QgYXMgcHJlc2NyaXB0aXZlIGFzIGl0IHNob3VsZCBiZSwgZm9yIGV4YW1wbGU6 IHRoZSBkb2N1bWVudCBzYXlzIHRoYXQg4oCcQXNzdW1pbmcgdGhhdCB0aGUgcmVnaXN0cnkgYWxs b3dzIHJhbmdlIG5vdGF0aW9uIGluIHRoZSBQcm90b2NvbCBWZXJzaW9uIGZpZWxk4oCm4oCdLCB3 aGlsZSB0aGUgcnBraS1ydHItcGR1IHJlZ2lzdHJ5IFsxXSBhbHJlYWR5IGhhcyBhIHZlcnNpb24g Y29sdW1uIChzbyBpdCBkb2VzIGFscmVhZHkgc3VwcG9ydCB2ZXJzaW9uIHNwZWNpZmljIGRldGFp bHMpLiAgIEZvciB0aGlzIGRvY3VtZW50LCBJQU5BIHNob3VsZCBvbmx5IGRlYWwgd2l0aCBWZXJz aW9uIDEgYWRkaXRpb25zIHRvIHRoZSByZWdpc3RyeSwgc28gdGhlcmXigJlzIG5vIG5lZWQgdG8g bWVudGlvbiB2ZXJzaW9uIDAgKGV4Y2VwdCBmb3IgdGhlIFR5cGUgOSBQRFUpLiAgSSB0aGluayB0 aGlzIHNob3VsZCBiZSBlYXN5IHRvIHJlc29sdmUsIGFuZCBJQU5BIHdpbGwgcHJvYmFibHkgcG9p bnQgaXQgb3VyIGR1cmluZyB0aGUgTGFzdCBDYWxsIOKAkyBzbyBsZXTigJlzIHdhaXQgZm9yIHRo ZWlyIGNvbW1lbnRzIGFuZCBmaXggdGhlIHRleHQgdGhlbi4NCg0KQWx2YXJvLg0KDQpbMV0gaHR0 cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9ycGtpL3Jwa2kueGh0bWwjcnBraS1ydHItcGR1 DQoNCg0KT24gMS83LzE3LCA1OjUxIFBNLCAic2lkciBvbiBiZWhhbGYgb2YgUm9iIEF1c3RlaW4i IDxzaWRyLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpZHItYm91bmNlc0BpZXRmLm9yZz4gb24g YmVoYWxmIG9mIHNyYUBoYWN0cm4ubmV0PG1haWx0bzpzcmFAaGFjdHJuLm5ldD4+IHdyb3RlOg0K DQpXaXRoIGFwb2xvZ2llcyB0byB0aGUgV0cgYW5kIG91ciBBRCBmb3IgdGFraW5nIHNvIHJpZGlj dWxvdXNseSBsb25nDQooZGVhZGxpbmVzIG9uIG90aGVyIHByb2plY3RzLCBidXQgdGhhdCdzIG5v IGV4Y3VzZSksIHdlIGhhdmUgZmluYWxseQ0KdXBsb2FkZWQgYW4gdXBkYXRlZCBJLUQgd2hpY2gg d2UgaG9wZSBkZWFscyB3aXRoIG1vc3QgKGFsbD8pIG9mIHRoZQ0KaXNzdWVzIHRoYXQgY2FtZSB1 cCBkdXJpbmcgQUQgcmV2aWV3LCBhcyB3ZWxsIGFzIGEgZmV3IG1pbm9yDQpjbGFyaWZpY2F0aW9u cyBhbmQgd29yZGluZyB0d2Vha3MuICBObyBwcm90b2NvbCBjaGFuZ2VzLCBqdXN0ICh3ZQ0KaG9w ZSkgYmV0dGVyIGRlc2NyaXB0aW9uIG9mIHRoZSBwcm90b2NvbC4NCg0KVGhlIG9uZSBpbXBvcnRh bnQgY2hhbmdlIGhlcmUgaW4gdGVybXMgb2YgSUVURiBzdGFuZGFyZGl6YXRpb24gaXMgdGhhdA0K d2UndmUgZHJvcHBlZCB0aGUgbm90aW9uIHRoYXQgdGhpcyBkb2N1bWVudCBzaG91bGQgb2Jzb2xl dGUgUkZDIDY4MTAuDQpXaGlsZSBBbHZhcm8ga2luZGx5IG9mZmVyZWQgdG8gaGVscCB1cyBmaW5k IGEgdHdpc3R5IHBhdGggd2hpY2ggd291bGQNCmxldCB1cyB3cml0ZSBhIHNpbmdsZSBkb2N1bWVu dCB3aGljaCB3b3VsZCBib3RoIGRlcHJlY2F0ZSBSRkMgNjgxMA0KKHByb3RvY29sIHZlcnNpb24g emVybykgYW5kIGFsc28gc3BlY2lmeWluZyBob3cgdG8gZG93bmdyYWRlIGZyb20NCnZlcnNpb24g b25lIHRvIHZlcnNpb24gemVybywgb24gcmVmbGVjdGlvbiB0aGUgYXV0aG9ycyBhZ3JlZWQgdGhh dA0KdGhpcyBpcyBub3Qgd29ydGggdGhlIHByb2NlZHVyYWwgaGVhZGFjaGUuDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaWRyIG1haWxpbmcgbGlz dA0Kc2lkckBpZXRmLm9yZzxtYWlsdG86c2lkckBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2lkcg0KDQo= --_000_9982103DAF454784B36C266BC314641Eciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFy YWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0 Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLm1zb0lu cw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTQwNzI2NTc3 NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NDYwNjIw Njk0IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1 IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQt aW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PlJvYjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGFua3MgZm9yIHRoZSB1cGRhdGUhICZu YnNwO0nigJltIHN0YXJ0aW5nIHRoZSBJRVRGIExhc3QgQ2FsbC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj5JIGhhdmUgdHdvIGNvbW1lbnRzIHRoYXQgcmVzdWx0IGZyb20gbm90IE9ic29sZXRp bmcgUkZDNjgxMDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPklmIHRoaXMgZG9jdW1lbnQgaXMg bm90IE9ic29sZXRpbmcgUkZDNjgxMCwgdGhlbiBjbGFyaWZ5aW5nIHRoZSB0aXRsZSB3b3VsZCBh dm9pZCBjb25mdXNpb24gZnJvbSBoYXZpbmcgMiBSRkNzIHdpdGggdGhlIHNhbWUgbmFtZS4mbmJz cDsgTXkgc3VnZ2VzdGlvbiBpcyB0byBjaGFuZ2UgdGhlIHRpdGxlIG9mIHRoaXMNCiBkb2N1bWVu dCB0byDigJxUaGUgUmVzb3VyY2UgUHVibGljIEtleSBJbmZyYXN0cnVjdHVyZSAoUlBLSSkgdG8g Um91dGVyIFByb3RvY29sLCBWZXJzaW9uIDHigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj5UaGUgSUFOQSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIGlzIG5vdCBhcyBwcmVz Y3JpcHRpdmUgYXMgaXQgc2hvdWxkIGJlLCBmb3IgZXhhbXBsZTogdGhlIGRvY3VtZW50IHNheXMg dGhhdCDigJxBc3N1bWluZyB0aGF0IHRoZSByZWdpc3RyeSBhbGxvd3MgcmFuZ2Ugbm90YXRpb24g aW4gdGhlIFByb3RvY29sIFZlcnNpb24NCiBmaWVsZOKApuKAnSwgd2hpbGUgdGhlIHJwa2ktcnRy LXBkdSByZWdpc3RyeSBbMV0gYWxyZWFkeSBoYXMgYSB2ZXJzaW9uIGNvbHVtbiAoc28gaXQgZG9l cyBhbHJlYWR5IHN1cHBvcnQgdmVyc2lvbiBzcGVjaWZpYyBkZXRhaWxzKS4mbmJzcDsgJm5ic3A7 Rm9yIHRoaXMgZG9jdW1lbnQsIElBTkEgc2hvdWxkIG9ubHkgZGVhbCB3aXRoIFZlcnNpb24gMSBh ZGRpdGlvbnMgdG8gdGhlIHJlZ2lzdHJ5LCBzbyB0aGVyZeKAmXMgbm8gbmVlZCB0byBtZW50aW9u IHZlcnNpb24gMCAoZXhjZXB0DQogZm9yIHRoZSBUeXBlIDkgUERVKS4mbmJzcDsgSSB0aGluayB0 aGlzIHNob3VsZCBiZSBlYXN5IHRvIHJlc29sdmUsIGFuZCBJQU5BIHdpbGwgcHJvYmFibHkgcG9p bnQgaXQgb3VyIGR1cmluZyB0aGUgTGFzdCBDYWxsIOKAkyBzbyBsZXTigJlzIHdhaXQgZm9yIHRo ZWlyIGNvbW1lbnRzIGFuZCBmaXggdGhlIHRleHQgdGhlbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj5BbHZhcm8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+WzFdIGh0dHA6Ly93d3cuaWFu YS5vcmcvYXNzaWdubWVudHMvcnBraS9ycGtpLnhodG1sI3Jwa2ktcnRyLXBkdTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxLzcvMTcsIDU6NTEgUE0s ICZxdW90O3NpZHIgb24gYmVoYWxmIG9mIFJvYiBBdXN0ZWluJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86c2lkci1ib3VuY2VzQGlldGYub3JnIj5zaWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9u IGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOnNyYUBoYWN0cm4ubmV0Ij5zcmFAaGFjdHJuLm5l dDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpdGggYXBvbG9naWVzIHRvIHRoZSBXRyBhbmQgb3VyIEFE IGZvciB0YWtpbmcgc28gcmlkaWN1bG91c2x5IGxvbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihkZWFkbGluZXMgb24gb3RoZXIgcHJvamVjdHMs IGJ1dCB0aGF0J3Mgbm8gZXhjdXNlKSwgd2UgaGF2ZSBmaW5hbGx5PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj51cGxvYWRlZCBhbiB1cGRhdGVkIEkt RCB3aGljaCB3ZSBob3BlIGRlYWxzIHdpdGggbW9zdCAoYWxsPykgb2YgdGhlPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pc3N1ZXMgdGhhdCBjYW1l IHVwIGR1cmluZyBBRCByZXZpZXcsIGFzIHdlbGwgYXMgYSBmZXcgbWlub3I8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNsYXJpZmljYXRpb25zIGFu ZCB3b3JkaW5nIHR3ZWFrcy4mbmJzcDsmbmJzcDtObyBwcm90b2NvbCBjaGFuZ2VzLCBqdXN0ICh3 ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aG9w ZSkgYmV0dGVyIGRlc2NyaXB0aW9uIG9mIHRoZSBwcm90b2NvbC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG9uZSBpbXBvcnRhbnQgY2hh bmdlIGhlcmUgaW4gdGVybXMgb2YgSUVURiBzdGFuZGFyZGl6YXRpb24gaXMgdGhhdDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2UndmUgZHJvcHBl ZCB0aGUgbm90aW9uIHRoYXQgdGhpcyBkb2N1bWVudCBzaG91bGQgb2Jzb2xldGUgUkZDIDY4MTAu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGls ZSBBbHZhcm8ga2luZGx5IG9mZmVyZWQgdG8gaGVscCB1cyBmaW5kIGEgdHdpc3R5IHBhdGggd2hp Y2ggd291bGQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPmxldCB1cyB3cml0ZSBhIHNpbmdsZSBkb2N1bWVudCB3aGljaCB3b3VsZCBib3RoIGRlcHJl Y2F0ZSBSRkMgNjgxMDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+KHByb3RvY29sIHZlcnNpb24gemVybykgYW5kIGFsc28gc3BlY2lmeWluZyBob3cg dG8gZG93bmdyYWRlIGZyb208bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPnZlcnNpb24gb25lIHRvIHZlcnNpb24gemVybywgb24gcmVmbGVjdGlvbiB0 aGUgYXV0aG9ycyBhZ3JlZWQgdGhhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+dGhpcyBpcyBub3Qgd29ydGggdGhlIHByb2NlZHVyYWwgaGVhZGFj aGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zaWRyIG1haWxpbmcg bGlzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGEgaHJlZj0ibWFpbHRvOnNpZHJAaWV0Zi5vcmciPnNpZHJAaWV0Zi5vcmc8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHIiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2lkcjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9982103DAF454784B36C266BC314641Eciscocom_-- From nobody Sat Jan 14 09:23:58 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8D1129486; Sat, 14 Jan 2017 09:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 eO9_Qh4gwYbN; Sat, 14 Jan 2017 09:23:29 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0123.outbound.protection.outlook.com [23.103.200.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC602129C5C; Sat, 14 Jan 2017 09:23:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pRvAc551G18DLt544p7xlDwHeJ7oioc/inT0taIJpsA=; b=tZrDYjMucmwPFSS9ZgFPELQ+KFrb1okM+wv9/XckRR+pFwm+Vnhc+uGyCWIs1jjSHnCJ0oX0dv+BoSRxFr99u1T7Yse5zR77P8Ctm3RFKhP4YELXeJY1Yim12hhnb6rsAq0tzU6jrdQXJAG34xcGAJMe+x7P4zs82DCLfa4vsg0= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0448.namprd09.prod.outlook.com (10.161.252.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Sat, 14 Jan 2017 17:23:27 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0817.020; Sat, 14 Jan 2017 17:23:27 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Ben Campbell , The IESG Thread-Topic: Ben Campbell's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) Thread-Index: AQHSZtOj8RWDBRi0KkOPVX8e3dZBrKE4RbqM Date: Sat, 14 Jan 2017 17:23:27 +0000 Message-ID: References: <148356622825.12945.17416255063037873581.idtracker@ietfa.amsl.com> In-Reply-To: <148356622825.12945.17416255063037873581.idtracker@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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.223.13] x-ms-office365-filtering-correlation-id: d14fda76-0fef-4408-4012-08d43ca20db1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0448; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0448; 7:omuv2vaaqPol82SPL1nnD4hR8VjrIu8qIQqxMVOzYgvCPwnk0yZv2CUetUR035PnC8FRYPM4lmmvHZQiPo8H+jqkc27MrJGRj58/mAN0/EGzzIZL+Ldv/ywuOvAk0/oEddRWredk3kE86uzX3Jc65tHRCbONgb6jd7jQ0dtAIVTsJPtM5jWYsXARySi+/n/ERDwfy6xktm3j0TIFAPZ8K/hDkp/ugeCPbyIN0uAFBu8DNLyMuBciV5dhWRXi1g+rZ7OKOiSRj8cOZJ66+n9ZfGDWmxUlD23ADgTpOBhSNxkXQwAXMXiS23dp1IU99dmOP3kh3cJCBlQhex44Psl4ey0yZ/rwvie5AIPr34r5M1yv4OdVBgkPnbuIlJ3SoMR7c6UScPbEuipEbeMjSlfzyq7lIgYbKMuzRWqaJNFq32O9JmmJkYcLz3juinFwRHIr8r2584Da1LqMOemKibrLwQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:DM2PR09MB0448; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0448; x-forefront-prvs: 0187F3EA14 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39840400002)(39860400002)(39450400003)(199003)(189002)(2900100001)(229853002)(54906002)(86362001)(105586002)(122556002)(345774005)(9686003)(92566002)(50986999)(189998001)(2950100002)(68736007)(81166006)(33656002)(81156014)(106356001)(6306002)(7696004)(8676002)(106116001)(230783001)(6116002)(8936002)(102836003)(76176999)(3846002)(54356999)(97736004)(66066001)(2906002)(3660700001)(5001770100001)(25786008)(305945005)(3280700002)(7736002)(55016002)(4326007)(6436002)(99286003)(6506006)(77096006)(101416001)(38730400001)(5660300001)(27001)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0448; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2017 17:23:27.5202 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0448 Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , "sidr-chairs@ietf.org" , Matthias Waehlisch , "sidr@ietf.org" Subject: Re: [sidr] Ben Campbell's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 17:23:35 -0000 Hi Ben, Sorry for the delay in responding.=20 Thank you for the review and very helpful comments. Please see my responses inline below. The changes mentioned below that reflect your comments/suggestions are already incorporated in the forthcoming version-22.=20 >-2: draft-ietf-sidr-bgpsec-protocol explicitly excludes non-capitalized > versions of 2119 words. This draft does not. It seems different 2119 > approaches among the various bgpsec draft could be confusing to the > reader. > [Update: Oops, sorry, I meant to say draft-ietf-sidr-bgpsec-ops exclude= s > non-capitalized versions of 2119 words. (That is to say, it treats them > as their normal English equivalents.)] Thank you for pointing this out. I have gone over the whole document=20 and wherever the standards language [RFC 2119] is applicable,=20 I have made sure that upper case =93MUST=94, =93SHOULD=94 etc. are used rather than lower case =93must=94, =93should=94 etc. > - 5.2, step 2: I'm almost sure I've missed something here, but if I > understand correctly, previous sections talked about how a peer can > propagate a BGPsec_Path attribute without modification. Will that cause = a > problem in this step if the immediate peer propagated an unmodified > BGPsec_Path that came from a different AS? You are right in pointing this out. The key is that 5.2, step 2=20 check is meant to be done with eBGP peer (not iBGP). Unmodified BGPsec update is sent only to=20 BGPsec-capable iBGP peers (internal peers). In the case of an eBGP (BGPsec capable) peer, the BGPsec update is always=20 modified and propagated with a new Secure_Path Segment and Signature added. So I have modified the wording in 5.2, step 2 to read as follows: 2. Check that AS number in the most recently added Secure_Path Segment (i.e. the one corresponding to the eBGP peer from which the update message was received) matches the AS number of that peer as specified in the BGP OPEN message. (Note: This check is performed only at an ingress BGPsec router where the update is first received from a peer AS.) > =20 > - 8.4, last paragraph: The text describes a replay attack, and delegates > the mitigation solution to. This is an > informational reference; it draft-ietf-sidr-bgpsec-rollover=20 >seems like it should be normative. The solution for mitigation of replay attacks is out of band (in relation to the BGPsec protocol).=20 As I see it, draft-ietf-sidr-bgpsec-rollover proposes 'a way' of replay attack mitigation. Techniques for key rollover /=20 replay attack mitigation are expected to continue to evolve.=20 There are various variants of the basic key rollover technique that=20 are discussed in this informational draft: https://tools.ietf.org/html/draft-sriram-replay-protection-design-discussio= n-07=20 What needs to be pointed out in the BGPsec specification is that=20 there are solutions available for replay attack mitigation.=20 The above are the reasons why=20 draft-ietf-sidr-bgpsec-rollover is included in informational references.=20 Sriram From nobody Sat Jan 14 10:56:19 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE08E12951B; Sat, 14 Jan 2017 10:56:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148442017790.24124.2732462706586628755.idtracker@ietfa.amsl.com> Date: Sat, 14 Jan 2017 10:56:17 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-publication@ietf.org, sidr@ietf.org Subject: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 18:56:18 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-sidr-publication-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-publication/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I find the document to be a bit short on normative references and some implementation details. Other than that the document looks fine. My specific questions and concern are as follows: 1) Please add a normative reference for HTTP, URI and RelaxNG on first use. 2) Base64 needs a normative reference (including the section number, as there are 2 variants). 3) Section 2 says that all payloads use CMS. None of your examples show CMS. Can you please elaborate on how CMS is used. 4) How can URI of the service be discovered? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In 2.5: is the list of error reasons extensible? Was Relax NG schema validated with a tool? In Section 5 you should reference the document, as IANA registrations cut & pasted to IANA website as separate files. From nobody Sat Jan 14 11:58:03 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 748B0129410; Sat, 14 Jan 2017 11:57:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148442387947.24076.17582145431791735786.idtracker@ietfa.amsl.com> Date: Sat, 14 Jan 2017 11:57:59 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-oob-setup@ietf.org, sidr@ietf.org Subject: [sidr] Alexey Melnikov's No Objection on draft-ietf-sidr-rpki-oob-setup-06: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 19:57:59 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-sidr-rpki-oob-setup-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-oob-setup/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a small list of minor issues that should be addressed before this document is approved: Base64 needs a normative reference (including the section number, as there are 2 variants). HTTP URI need a normative reference. Are HTTPS URIs allowed where HTTP URIs are mentioned in the document? In 5.3: id-ct-xml needs a reference. From nobody Sun Jan 15 01:58:59 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1DB129470; Sun, 15 Jan 2017 01:58:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148447433190.28499.15731548993808113925.idtracker@ietfa.amsl.com> Date: Sun, 15 Jan 2017 01:58:51 -0800 Archived-At: Cc: draft-ietf-sidr-rpki-oob-setup.all@ietf.org, ietf@ietf.org, sidr@ietf.org Subject: [sidr] Review of draft-ietf-sidr-rpki-oob-setup-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 09:58:52 -0000 Reviewer: Roni Even Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-sidr-rpki-oob-setup-06 Reviewer: Roni Even Review Date: 2017-01-15 IETF LC End Date: 2017-01-10 IESG Telechat date: 2017-01-19 Summary: This draft is ready for publication as a standard track RFC. Major issues: Minor issues: Nits/editorial comments: From nobody Mon Jan 16 05:00:15 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B7E1299C1; Mon, 16 Jan 2017 05:00:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148457160928.22540.4235560949029260207.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2017 05:00:09 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-delta-protocol-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 13:00:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : RPKI Repository Delta Protocol Authors : Tim Bruijnzeels Oleg Muravskiy Bryan Weber Rob Austein Filename : draft-ietf-sidr-delta-protocol-05.txt Pages : 24 Date : 2017-01-16 Abstract: In the Resource Public Key Infrastructure (RPKI), certificate authorities publish certificates, including end entity certificates, Certificate Revocation Lists (CRL), and RPKI signed objects to repositories. Relying Parties (RP) retrieve the published information from those repositories. This document specifies a protocol which provides relying parties with a mechanism to query a repository for incremental updates using the HTTP Over TLS (HTTPS) [RFC2818] protocol, thus enabling the RP to keep its state in sync with the repository using a secure transport channel. This document updates [RFC6480], [RFC6481], and [RFC7730]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-delta-protocol-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 16 05:01:49 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E72F1299D7; Mon, 16 Jan 2017 05:01:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148457170764.22584.8933948525563491675.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2017 05:01:47 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-oob-setup@ietf.org, sidr@ietf.org Subject: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-rpki-oob-setup-06=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 13:01:47 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-sidr-rpki-oob-setup-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-oob-setup/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- High level comment: I'm not sure if 'protocol' is the right term for this spec. For me this doc rather defines a set of messages, however given it does not specify any action that must follow as a reaction to a message (as well as no choice of the publication nor BPKI protocol), I find the term 'protocol' here rather confusing. Smaller comments: - Some more abbreviations could be spelled out, e.g. CMS - section 2 is not needed - sec 5: "Appendix A is a [RelaxNG] schema for this protocol. The schema is normative: in the event of a disagreement between the schema and the following textual description, the schema is authoritative." I guess in this case the schema should not be in the appendix. And would it be possible to make sure the schema does not disagree with the text...? From nobody Mon Jan 16 05:08:38 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB78612943B for ; Mon, 16 Jan 2017 05:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] 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 gP8dVr3BU2G6 for ; Mon, 16 Jan 2017 05:08:35 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 84DAF1294A9 for ; Mon, 16 Jan 2017 05:08:35 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cT71V-00018v-0G for sidr@ietf.org; Mon, 16 Jan 2017 14:08:34 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=[IPv6:::1]) by titi.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1cT71T-0002EP-OV; Mon, 16 Jan 2017 14:08:31 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Oleg Muravskiy In-Reply-To: <148457160928.22540.4235560949029260207.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2017 14:08:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <229D5EB4-25A5-4FB4-A24C-3A468FCC5074@ripe.net> References: <148457160928.22540.4235560949029260207.idtracker@ietfa.amsl.com> To: IETF SIDR X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------------ X-RIPE-Spam-Report: Spam Total Points: -12.6 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -3.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b741230135aaebab364298f5fab43abe45f Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-delta-protocol-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 13:08:38 -0000 Dear WG, This is an updated version of the draft-ietf-sidr-delta-protocol, = resolving comments from the AD review. The rfcdiff page seems to be down right now, but in general the diff = from previous version should be available at: = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-sidr-delta-protocol-04&url2= =3Ddraft-ietf-sidr-delta-protocol-05&difftype=3D--html Cheers, Oleg > On 16 Jan 2017, at 14:00, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing of the = IETF. >=20 > Title : RPKI Repository Delta Protocol > Authors : Tim Bruijnzeels > Oleg Muravskiy > Bryan Weber > Rob Austein > Filename : draft-ietf-sidr-delta-protocol-05.txt > Pages : 24 > Date : 2017-01-16 >=20 > Abstract: > In the Resource Public Key Infrastructure (RPKI), certificate > authorities publish certificates, including end entity certificates, > Certificate Revocation Lists (CRL), and RPKI signed objects to > repositories. Relying Parties (RP) retrieve the published > information from those repositories. This document specifies a > protocol which provides relying parties with a mechanism to query a > repository for incremental updates using the HTTP Over TLS (HTTPS) > [RFC2818] protocol, thus enabling the RP to keep its state in sync > with the repository using a secure transport channel. This document > updates [RFC6480], [RFC6481], and [RFC7730]. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-delta-protocol-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From nobody Mon Jan 16 05:29:52 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A48A12896F; Mon, 16 Jan 2017 05:29:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148457339142.22536.12377935833892537902.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2017 05:29:51 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-publication@ietf.org, sidr@ietf.org Subject: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-publication-10=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 13:29:51 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-sidr-publication-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-publication/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- My only question is why this is a sidr wg doc? This seems like a general mechanism that cannot only be used in the routing infrastructure. Has this doc been at least reviewed by other wgs? From nobody Mon Jan 16 07:37:09 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BB9129549; Mon, 16 Jan 2017 07:37:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148458102747.22470.13249180409651995242.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2017 07:37:07 -0800 Archived-At: Cc: morrowc@ops-netman.net, draft-ietf-sidr-adverse-actions@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-adverse-actions-04=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 15:37:07 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-sidr-adverse-actions-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-adverse-actions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document (still) has a lot of redundancy, mostly due to the chosen structure of the doc. I guess it's too late to change anything but it really makes it harder to get the actual message of this doc. From nobody Mon Jan 16 14:44:19 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E55F11297C9; Mon, 16 Jan 2017 14:44:17 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148460665789.22528.11968748281215128315.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2017 14:44:17 -0800 Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, sidr@ietf.org Subject: [sidr] Last Call: (The Resource Public Key Infrastructure (RPKI) to Router Protocol) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 22:44:18 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'The Resource Public Key Infrastructure (RPKI) to Router Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-01-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 1 of the rpki-rtr protocol. RFC 6810 describes version 0. Downref: Normative reference is made to an Obsolete document: RFC2385 (Protection of BGP Sessions via the TCP MD5 Signature Option). The text is clear about the Status, but the reference is used due to the lack of general availability of a preferred option. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc6810-bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc6810-bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jan 16 15:11:20 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 647D21294B3; Mon, 16 Jan 2017 15:11:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148460827940.22532.6630830513973081718.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2017 15:11:19 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-22.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 23:11:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : BGPsec Protocol Specification Authors : Matthew Lepinski Kotikalapudi Sriram Filename : draft-ietf-sidr-bgpsec-protocol-22.txt Pages : 44 Date : 2017-01-16 Abstract: This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems (ASes) through which a BGP update message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each autonomous system that propagates the update message. The digital signatures provide confidence that every AS on the path of ASes listed in the update message has explicitly authorized the advertisement of the route. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-protocol-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 16 15:21:50 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3056129874; Mon, 16 Jan 2017 15:21:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148460890792.22458.9507006802883221910.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2017 15:21:47 -0800 Archived-At: Cc: draft-ietf-sidr-bgpsec-protocol@ietf.org, sidr-chairs@ietf.org, m.waehlisch@fu-berlin.de, sidr@ietf.org Subject: [sidr] Stephen Farrell's Yes on draft-ietf-sidr-bgpsec-protocol-22: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 23:21:48 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-22: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss points. From nobody Mon Jan 16 16:50:30 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0813C129675; Mon, 16 Jan 2017 16:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 6PgyMOvekHHt; Mon, 16 Jan 2017 16:50:21 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0097.outbound.protection.outlook.com [23.103.200.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE643129438; Mon, 16 Jan 2017 16:50:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2qdA0Oif/mu1uSeJH4HVeC7YfcQJAHeHoAx7i5pS3yE=; b=gLc/mC2Cw8iH2lGrWqGl7JgGUy5fSaNDbxuBdGMizBxq/qXqlLSCY2nYN8r6rp5JOJf2xA+TXNlChsL6CzR3VuJl+NllUbXEluyljX967J9fqpkc5wdJyggKL6Ff0OaH0E5ZIyUGjoPm65kLlh2eiDLjF32MdsLxbLaL8S6wvMI= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0448.namprd09.prod.outlook.com (10.161.252.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Tue, 17 Jan 2017 00:50:18 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0845.013; Tue, 17 Jan 2017 00:50:18 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Stephen Farrell , "Mirja Kuehlewind (IETF)" , Alissa Cooper , Suresh Krishnan , Alexey Melnikov , "Ben Campbell" , Spencer Dawkins , Alvaro Retana , "keyur@arrcus.com" , Jonathan Hardwick , The IESG Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-22.txt Thread-Index: AQHScE3c4otI6dXur0aDquivJVjUfaE70e2K Date: Tue, 17 Jan 2017 00:50:18 +0000 Message-ID: References: <148460827940.22532.6630830513973081718.idtracker@ietfa.amsl.com> In-Reply-To: <148460827940.22532.6630830513973081718.idtracker@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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.218.58] x-ms-office365-filtering-correlation-id: 7b8bf5f2-b2b7-4f5b-05a2-08d43e72cf01 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0448; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0448; 7:vSM0JKNJIBsPNFt19s2e4ifdUW6FBCeLlPGnIJBU3NRBtYbJ6TiBUNi87ZVYLp2JEXCEwOHAReNtuMufIbC7y0iZRn6mDC+cURPvhVYc/rIQzbtSgNR8xcMh4iC7Y3msgTrGt1UJD7R5lagRolzLLDfKILsZTM00Ga8JW5fbtu4QTYgqD41Re5eTUpuiuYBvWLEQz7unzARwRNBWDXzX2ZfsyjETxwrc5G4nasuHJCiSxY2oBeDBDPSbBefympx/rzPVaVnCELd+rjIyg4MZ74kzE3rJv3V4rMBYpyZreEMsMEOBNZ69AKn58rV1g+xEyKmOQ2FMTKOPBplZ3rQ6jz0JYKq2AeNZor72vXA4sAxmgDS6f9tLTTQMAuInmvvZr+BV0ODH6bKDKmgM8Iycp9g3m+pql9fuEqwLt20z2jCifGgRNDmwUy7Seiri/i6lSTD9GvmnysjntiUGpk+xgQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:DM2PR09MB0448; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0448; x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39450400003)(39850400002)(39410400002)(199003)(377454003)(377424004)(189002)(3846002)(6116002)(77096006)(55016002)(3280700002)(99286003)(6506006)(105586002)(6436002)(50986999)(54906002)(102836003)(4326007)(68736007)(54356999)(3660700001)(76176999)(106356001)(6306002)(25786008)(8666007)(229853002)(122556002)(230783001)(106116001)(38730400001)(86362001)(2906002)(39060400001)(3900700001)(9686003)(101416001)(2900100001)(97736004)(305945005)(7696004)(66066001)(7416002)(92566002)(74316002)(81166006)(8676002)(7736002)(2501003)(189998001)(5660300001)(81156014)(5001770100001)(8936002)(2950100002)(33656002)(30001)(921003)(1121003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0448; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2017 00:50:18.3404 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0448 Archived-At: Cc: "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-22.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 00:50:23 -0000 This revision addresses the comments from the IESG reviewers, and also the comments from Keyur (RTGDIR review) and=20 Alvaro (some new comments in the context of Keyur=92s comments).=20 It also addresses comments from Oliver and Randy (mainly suggestions for making Sections 4.3 and 7 a bit crisper and more clear). I noticed that Stephen cleared his Discuss points=20 after seeing this revision, and he has updated his position to Yes. Thank you, Stephen. I had responded earlier to comments from=20 Mirja, Alissa, Suresh, Alexey, Ben, and Spencer. =20 This revision incorporates changes based on their comments as outlined in my responses to them on the WG list. Thank you all for greatly helping steer this document towards better clarity, accuracy, and presentation. Please let me know if I have missed responding to any=20 of your comments. Sriram ________________________________________ From: sidr on behalf of internet-drafts@ietf.org Sent: Monday, January 16, 2017 6:11 PM To: i-d-announce@ietf.org Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-22.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : BGPsec Protocol Specification Authors : Matthew Lepinski Kotikalapudi Sriram Filename : draft-ietf-sidr-bgpsec-protocol-22.txt Pages : 44 Date : 2017-01-16 Abstract: This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems (ASes) through which a BGP update message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each autonomous system that propagates the update message. The digital signatures provide confidence that every AS on the path of ASes listed in the update message has explicitly authorized the advertisement of the route. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-protocol-22 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 16 19:10:30 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C176129978; Mon, 16 Jan 2017 19:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 O36pckbKmtFz; Mon, 16 Jan 2017 19:10:27 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0117.outbound.protection.outlook.com [23.103.200.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6E61294B8; Mon, 16 Jan 2017 19:10:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=B1rWIgKOMFAWazWOwUDWedRjOCKpjYbT95mG+xkhNjc=; b=ldwZiax++q3Zs6wKUo5qWQxX3U0FNGmSYsH4hlpXtKBbKU7mQdLFEpIdkqL+/IZ1hj2l+Y6qjCYtJbTmLpEsLF2AREurGmIKFeh1t9ze7lHKAOdrmVw9ihWTgKMco+EGXcTzaC1aC+Om2ZDYQC7nLQY5B9djyZfUbYYNZXa/xSM= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Tue, 17 Jan 2017 03:10:25 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0845.013; Tue, 17 Jan 2017 03:10:25 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Keyur Patel , "Alvaro Retana (aretana)" Thread-Topic: draft-ietf-sidr-bgpsec-protocol Thread-Index: AQHSZthkNfH8MXPYLkOmxwl9coeqv6EoZskAgAKH0dSAASfLgIAG7GoAgAjunNs= Date: Tue, 17 Jan 2017 03:10:25 +0000 Message-ID: References: <6C8E073D-F1AB-4588-8DFF-FAA0A2465273@cisco.com>, <67DBF30E-B262-4568-87FB-96EEF9FB87A9@arrcus.com> In-Reply-To: <67DBF30E-B262-4568-87FB-96EEF9FB87A9@arrcus.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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.218.58] x-ms-office365-filtering-correlation-id: 430755ca-d913-47d3-16bc-08d43e8661ec x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0446; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 7:c3uS/jrZH6ElRwzEl44Za08HPTC2JZlVmaU55gl1wGN8e5CLGLlEbWaFwLih1JZ4CkPAWTC8HGbrY3o0UXFBov0B9OUE9RUiyD+kT+AoY5wVWvLIIDwSTVGVMRUmdX6kBNkuwk+GOolrng9q2d9scEkwADWaCWofUz50Jds5u8SCuTGWJSiy/7I3O5BD+sa1Sh5wCbaWnZGXxPNtkeagSUJ6M96+EglIapoc1kTdcXo/lBT5hE2BA5u2QXJhFczg3r1S/05pw0vnIHFF4mWMkwVrBVnGq4P9JR3t2kNy4SknukBUI5JL3NqqiAJFP0SNpE/87xVMNltKTb7IZYJHHYJPO6VkITA7gBAY5bqs2+KLE3UsVjtWZXtJ5iv/e0ATfna22TJ9t7CLrYa+mEpb0yG+5lbCHkfBRmIl/jf+BbkcGfmjkHnpXby8T0hLP3QUAI3CHXztdG3Q0c2S5Vbw2A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558021)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446; x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39850400002)(39410400002)(39840400002)(24454002)(52084003)(199003)(189002)(74316002)(55016002)(230783001)(189998001)(77096006)(6506006)(54906002)(99286003)(8676002)(81156014)(25786008)(102836003)(3846002)(4326007)(6436002)(81166006)(93886004)(6116002)(33656002)(30001)(38730400001)(9686003)(8936002)(3280700002)(229853002)(3660700001)(92566002)(122556002)(7696004)(2906002)(105586002)(86362001)(106356001)(2900100001)(68736007)(97736004)(305945005)(5660300001)(106116001)(5001770100001)(54356999)(76176999)(5890100001)(50986999)(66066001)(2950100002)(101416001)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2017 03:10:25.3523 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0446 Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , Jonathan Hardwick , "sidr-chairs@ietf.org" , sidr Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 03:10:29 -0000 Hi Alvaro, ... snip ... Alvaro wrote: >>I don=92t have an objection for this behavior, but I think=20 >>we should make the WG (and idr!) aware of the change=20 >>and get their comments (if any) before I approve the publication. Keyur responded: >#Keyur: Ack. Though I was only requesting some text clarification=20 >so that it is very clear to the implementers. So there was no change required as Keyur points out.=20 Oliver also agreed with Keyur's observation when I ran this by him last wee= k. Per Keyur's request, I have added the following text clarification in Secti= on 7: During Graceful Restart (GR), restarting and receiving BGPsec speakers MUST follow the procedures specified in [RFC4724] for restarting and receiving BGP speakers, respectively. In particular, the behavior of retaining the forwarding state for the routes in the Loc-RIB [RFC4271] and marking them as stale as well as not differentiating between stale and other information during forwarding will be the same as specified in [RFC4724]. ...snip... Alvaro wrote: >>=85how should an iBGP speaker perform loop detection=20 >>if there=92s no BGPsec_Path attribute? In other words,=20 >>there is no defined mechanism to run the algorithm in 4.4 without it. >> >>I=92m not suggesting that you include an empty attribute,=20 >>but that you indicate in 4.4 that no BGPsec_Path attribute=20 >>is equivalent to an empty AS_PATH. Per your suggestion, I have added the following text in Section 4.4:=20 Finally, one special case of reconstruction of AS_PATH is when the BGPsec_Path attribute is absent. As explained in Section 4.1, when a BGPsec speaker originates a prefix and sends it to a BGPsec-capable iBGP peer, the BGPsec_Path is not attached. So when received from a BGPsec-capable iBGP peer, no BGPsec_Path attribute in a BGPsec update is equivalent to an empty AS_PATH [RFC4271]. Please let me know if you have any comments/questions.=20 Thank you. Sriram= From nobody Tue Jan 17 03:05:32 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9D1129A3F for ; Tue, 17 Jan 2017 03:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-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 EV3y6vnYMNtt for ; Tue, 17 Jan 2017 03:05:30 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56730129A30 for ; Tue, 17 Jan 2017 03:05:29 -0800 (PST) Received: (qmail 14019 invoked from network); 17 Jan 2017 12:05:27 +0100 Received: from p5dec276e.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.39.110) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Jan 2017 12:05:27 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Tue, 17 Jan 2017 12:05:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148355465867.12949.10785749487953700357.idtracker@ietfa.amsl.com> To: "Sriram, Kotikalapudi (Fed)" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , Alexey Melnikov , "sidr-chairs@ietf.org" , The IESG , "sidr@ietf.org" , Matthias Waehlisch Subject: Re: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-bgpsec-protocol-21=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 11:05:31 -0000 Hi Sriram, thanks for your reply. That=E2=80=99s all fine. I really didn=E2=80=99t = expect any protocol changes at this late stage of the draft but wanted = at least to know if these points were previously discussed. Also happy = to see that some parts where discussed with Ross. One final question (related to point 4): What happens if one router on = the path does not support/understand BGPsec? Sorry, if that is a stupid = question but it=E2=80=99s still not fully clear to me from the draft=E2=80= =A6 Mirja > Am 13.01.2017 um 22:31 schrieb Sriram, Kotikalapudi (Fed) = : >=20 > Hi Mirja, > =20 > Sorry for the delay in replying. > Thank you for your careful review, and the detailed and helpful = comments. > Please see my responses inline below marked with [Sriram]. > Changes reflecting your suggestions as discussed below > have been incorporated in the forthcoming version-22.=20 > =20 > =20 > >First, thanks for a well written document! > =20 > =20 > Thank you. > =20 > =20 > > A few question on the design; not to propose changes but I would = like to learn the reason why the design is as it is: > > 1) Why do you need to send two different negotiation capabilities = for each direction instead of just using two flags in the same = capability? > > And similar why don't you just announce multiple address families in = the same capability (using variable length)? > >=20 > =20 > =20 > [Sriram] Oliver Borchert (implementer of one of two available = implementations) posted his thoughts on this earlier (responding to a = similar question from Russ Housley). He had preference for the way = currently it is (please see =E2=80=9CTo Comment 2=E2=80=9D in the link = below): > =20 > https://www.ietf.org/mail-archive/web/sidr/current/msg08130.html > =20 > =20 > [Sriram] Also, Keyur and I talked about this issue in a phone call = last week. He would have preferred combining those messages (in = agreement with you), but thought it was a minor issue and could be left = as is for now. He also suggested that if, down the road, router vendor = implementers express strong preference for it, a bis can be published. = Russ also thought it was minor and was also agreeable to leaving it as = is. Please let me know if you still feel strongly. =20 > =20 > =20 > > 2) Why are the Secure_Path elements and Signature_Block blocks not = aligned but in two different lists (given there is and one to one = mapping)? Wouldn't it be easier to just update one length field (at a = fixed position) and attached the new information at the end? Or to ask = the question differently: why is the format as shown in figure 8 not = used in the message itself (->this is related to Suresh's question)? > >=20 > =20 > =20 > [Sriram] The short answer is that the protocol designers felt that in = the bytes sent on the wire, it made sense that the whole Secure_Path = should be together and the set of Signatures should be together. For = instance, then it is easy to convert Secure_Path to AS_PATH if the = update needs to be forwarded unsigned to a non-BGPsec peer. The = Secure_Path in its entirety is also used in the checks performed in the = list in Section 5.2. > =20 > =20 > [Sriram] Regarding Figure 8 (format for the data to be hashed), Oliver = offered the rationale for it in the following post back when we first = made the switch to this format. Michael Baer (implementer of the other = available implementation), Oliver, myself, and Matt Lepinski = discussed/reviewed it in detail and then we proceeded to include it in = the specification. > =20 > https://mailarchive.ietf.org/arch/msg/sidr/8B_e4CNxQCUKeZ_AUzsdnn2f5MU > =20 > =20 > [Sriram] Suresh and Alexey seemed to appreciate the rationale that was = applied for the format in Figure 8 (after they read Oliver=E2=80=99s = explanation): > =20 > https://www.ietf.org/mail-archive/web/sidr/current/msg08237.html > =20 > =20 > > Questions on operation: > > 1) section 5 says "a BGPsec speaker MAY temporarily defer validation = of incoming BGPsec update messages". > > Does this mean it has to remember its state before applying the = update message such that is can revert to this state if it later detects = that die update message was not valid? Or what action is supposed to = happen if the update message is detected as not valid later on > =20 > =20 > [Sriram] It is left up to an implementation the mechanism for saving = the state and returning to where it was left off. If the router deferred = validation, it comes back later and completes the validation. If an = update message is detected not valid later, the action would be similar = to what is done when update validity state change occurs due to an RPKI = state change, i.e. re-run best path selection =E2=80=93 see excerpt = below (Section 5, p.22): > =20 > For example, when a given RPKI certificate ceases to be valid = (e.g., > it expires or is revoked), all update messages containing a = signature > whose SKI matches the SKI in the given certificate must be re- > assessed to determine if they are still valid. If this = reassessment > determines that the validity state of an update has changed then, > depending on local policy, it may be necessary to re-run best path > selection. =20 > =20 > =20 > > 2) sec 4.2 says "Next, the BGPsec speaker generates one or two = Signature_Blocks." > > Are you sure it's at max 2? I guess this depends on the expected = update cycles of the algorithm compared to the devices. Given update = cycles for devices can be very slow and updates for algorithm can be = fast if any security problems are detected, I wouldn't recommend to = limit this to two. > =20 > =20 > [Sriram] This was discussed at an IETF SIDR meeting extensively, and = the WG had consensus that two Signature_Blocks would be adequate. > =20 > > 3) In relation to the comment above, I'm not a big fan of the algo = migration strategy in section 6.1. I understand the problem that all = router on the path need to potentially support the algo. However, you do = have an negotiation phase. So why don't you the advertise the signing = algorithm in the negotiation capabilities? In this case the sender could = at least choose to only send the one(s) that is/are also supported by = the receiver or not use BGPsec at all if there is no match. However, I = also understand that it is probably to late to change anything now and = if there is wg consensus, I'm fine with that... > =20 > =20 > [Sriram] The WG has had consensus on this for quite some time now =E2=80= =93 that instead of negotiation upfront, the Signature_Block(s) in the = update must indicate what algorithm(s) is(are) used. =20 > =20 > =20 > > 4) section 8.1 says "the recipient of a valid BGPsec update message = is assured that the update propagated via the sequence of ASes listed in = the Secure_Path portion of the BGPsec_Path attribute." > > Is that true? It is assured that at least these ASes have been = crossed but there might have been others on the path that did not sign = the BGPsec_Path attribute, no? > =20 > =20 > [Sriram] Yes, it is true. Each AS in the path MUST sign to the next AS = (Target AS). Section 3.1 says: > =20 > =20 > The Secure_Path contains one Secure_Path Segment (see Figure 5) for > each Autonomous System in the path to the originating AS of the > prefix specified in the update message. > =20 > =20 > [Sriram] Also, Section 3.2 says: > =20 > =20 > A Signature_Block in Figure 6 has exactly one Signature Segment = (see > Figure 7) for each Secure_Path Segment in the Secure_Path portion = of > the BGPsec_Path Attribute. =20 > =20 > =20 > =20 > [Sriram] The following check listed in Section 5.2 make it clear as = well: > =20 > =20 > 3. Check that each Signature_Block contains one Signature segment > for each Secure_Path Segment in the Secure_Path portion of the > BGPsec_Path attribute. (Note that the entirety of each > Signature_Block must be checked to ensure that it is well = formed, > even though the validation process may terminate before all > signatures are cryptographically verified.) > =20 > =20 > > 5) Is it really necessary to create registries for "BGPsec = Capability" > > and "BGPsec_Path Flags"? Given this is a really small number of = bits/flags, I think new RFCs that update this RFC are enough to define a = new use for these so far unused bits. > =20 > =20 > [Sriram] This came up in the Russ Housley=E2=80=99s review also. But = later he agreed it was OK to include these. He offered some suggestions = for clarifying the bits (fields) that were already fully specified in = the protocol, and hence didn=E2=80=99t need any IANA consideration. His = suggestions were incorporated in the IANA section in version 21. > =20 > =20 > >=20 > > Further, editorial proposals: > > 1) I would propose to add the Confed_Segment flag in figure 5 (and = call the remaining flag field 'reserved') > =20 > =20 > [Sriram] Good idea. I have made the change in the forthcoming = version-22. > =20 > =20 > =20 > > 2) Maybe explain Adj-RIB-In or give a reference to RFCrfc4271 = section 1.1 > >=20 > =20 > =20 > [Sriram] Done. I=E2=80=99ve provided the reference to RFC4271. > =20 > =20 > Sriram From nobody Tue Jan 17 07:39:35 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C661293F8; Tue, 17 Jan 2017 07:39:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148466757366.32123.16117537823337252178.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2017 07:39:33 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-publication@ietf.org, sidr@ietf.org Subject: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 15:39:34 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sidr-publication-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-publication/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- What is the upgrade path for the future when new versions of this protocol get published? How are clients and servers meant to agree on which version to use? From nobody Tue Jan 17 07:46:08 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A502E1294D4; Tue, 17 Jan 2017 07:46:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148466796666.31979.17532709479234975824.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2017 07:46:06 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-publication@ietf.org, sidr@ietf.org Subject: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 15:46:07 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sidr-publication-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-publication/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- What is the upgrade path for the future when new versions of this protocol get published? How are clients and servers meant to agree on which version to use? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (Hit the send button too quickly, sorry for the multiple emails.) Although I understand why Section 6 says transport security is not strictly required, given that the authentication and authorization mechanisms that this protocol relies on are outside of the scope here, isn't it possible that clients and servers may be exchanging cookies or other headers in the course of using this protocol that would benefit from transport encryption? It seems like mentioning that transport security may still be beneficial although not required might be a good idea. From nobody Tue Jan 17 07:47:38 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6709E12947A; Tue, 17 Jan 2017 07:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 o5G_CoDDWb-R; Tue, 17 Jan 2017 07:47:27 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375F61294CD; Tue, 17 Jan 2017 07:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15036; q=dns/txt; s=iport; t=1484668047; x=1485877647; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ow5DlVoPt9ki4dBSdNSKZM1G+zLEU1UzgxVUHgmfp/c=; b=ELFsjp8lpllaZQ4vihOf4kvTRps6BYMSxHXGntJY3QiedeMIGWT0dbEz atEgYaGSNaK9wy0SfTPRtF/MXFvQzc2SwRyFSCUgxAkCAkzupOJ8pqrM9 KtvCDEycS0XVwXQtWBxT1j2aji4hXH/CifTrtX50uVLu4a1HHNn66FhFO w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAQBDO35Y/5JdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9KAQEBAQEfX4EJB4NKigeReR+QAVCCTIIPgguGIgIagXg/GAE?= =?us-ascii?q?CAQEBAQEBAWMohGoBBAEjUQUFCwIBCD8DAgICMBQGCwIEDgUfiFwIrzmCJSuJW?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GRYICCIJdh04tgjEFlS+GCwGRXoF3jna?= =?us-ascii?q?IGopRAR84gUQVSgGEJhwYgUdzhh0rgQOBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,245,1477958400"; d="scan'208,217";a="373653448" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2017 15:47:26 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v0HFlQdv021630 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Jan 2017 15:47:26 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 17 Jan 2017 09:47:25 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 17 Jan 2017 09:47:25 -0600 From: "Alvaro Retana (aretana)" To: "Mirja Kuehlewind (IETF)" , "Sriram, Kotikalapudi (Fed)" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-sidr-bgpsec-protocol-21:_(with_COMMENT)?= Thread-Index: AQHScLGgbhRfSiDCEU+RaxlXyOSsTqE84V2A Date: Tue, 17 Jan 2017 15:47:25 +0000 Message-ID: <9B17A0C3-3430-4643-9D0C-B4554FF04510@cisco.com> References: <148355465867.12949.10785749487953700357.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_9B17A0C3343046439D0CB4554FF04510ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , Alexey Melnikov , "sidr-chairs@ietf.org" , The IESG , "sidr@ietf.org" , Matthias Waehlisch Subject: Re: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-bgpsec-protocol-21=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 15:47:34 -0000 --_000_9B17A0C3343046439D0CB4554FF04510ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWlyamE6DQoNCkhpIQ0KDQpJZiBhbiBBUyBpbiB0aGUgcGF0aCBkb2VzbuKAmXQgc3VwcG9ydCBC R1BzZWMsIHRoZW4gQkdQIGdvZXMgYmFjayB0byDigJxub3JtYWzigJ0gbW9kZSAoYXMgaW4gYmVm b3JlIEJHUHNlYyksIGFuZCB0aGUgYXNzdXJhbmNlIHRoYXQgdGhlIOKAnHVwZGF0ZSBwcm9wYWdh dGVkIHZpYSB0aGUgc2VxdWVuY2Ugb2YgQVNlcyBsaXN0ZWTigJ0gaXMgbG9zdC4gIEluIG90aGVy IHdvcmRzLCBmcm9tIHRoZSBvcmlnaW4gQVMgdG8gdGhlIEFTIGJlZm9yZSB0aGUgb25lIG5vdCBz dXBwb3J0aW5nIEJHUHNlYywgd2UgY2FuIHN0aWxsIHByb3ZpZGUgdGhlIGFzc3VyYW5jZSwgYnV0 IG5vdCBiZXlvbmQgdGhhdCDigJMgc28gYW55IEFTIGluY2x1ZGluZyBhbmQgYmV5b25kIHRoZSBv bmUgbm90IHN1cHBvcnRpbmcgQkdQc2VjIHdvbuKAmXQgYmUgYWJsZSB0byB2ZXJpZnkgYW55dGhp bmcuDQoNCkFsdmFyby4NCg0KDQoNCg0KT24gMS8xNy8xNywgNjowNSBBTSwgIk1pcmphIEt1ZWhs ZXdpbmQgKElFVEYpIiA8aWV0ZkBrdWVobGV3aW5kLm5ldDxtYWlsdG86aWV0ZkBrdWVobGV3aW5k Lm5ldD4+IHdyb3RlOg0KDQpIaSBTcmlyYW0sDQoNCnRoYW5rcyBmb3IgeW91ciByZXBseS4gVGhh dOKAmXMgYWxsIGZpbmUuIEkgcmVhbGx5IGRpZG7igJl0IGV4cGVjdCBhbnkgcHJvdG9jb2wgY2hh bmdlcyBhdCB0aGlzIGxhdGUgc3RhZ2Ugb2YgdGhlIGRyYWZ0IGJ1dCB3YW50ZWQgYXQgbGVhc3Qg dG8ga25vdyBpZiB0aGVzZSBwb2ludHMgd2VyZSBwcmV2aW91c2x5IGRpc2N1c3NlZC4gQWxzbyBo YXBweSB0byBzZWUgdGhhdCBzb21lIHBhcnRzIHdoZXJlIGRpc2N1c3NlZCB3aXRoIFJvc3MuDQoN Ck9uZSBmaW5hbCBxdWVzdGlvbiAocmVsYXRlZCB0byBwb2ludCA0KTogV2hhdCBoYXBwZW5zIGlm IG9uZSByb3V0ZXIgb24gdGhlIHBhdGggZG9lcyBub3Qgc3VwcG9ydC91bmRlcnN0YW5kIEJHUHNl Yz8gU29ycnksIGlmIHRoYXQgaXMgYSBzdHVwaWQgcXVlc3Rpb24gYnV0IGl04oCZcyBzdGlsbCBu b3QgZnVsbHkgY2xlYXIgdG8gbWUgZnJvbSB0aGUgZHJhZnTigKYNCg0KTWlyamENCuKApg0KPiA0 KSBzZWN0aW9uIDguMSBzYXlzICJ0aGUgcmVjaXBpZW50IG9mIGEgdmFsaWQgQkdQc2VjIHVwZGF0 ZSBtZXNzYWdlIGlzIGFzc3VyZWQgdGhhdCB0aGUgdXBkYXRlIHByb3BhZ2F0ZWQgdmlhIHRoZSBz ZXF1ZW5jZSBvZiBBU2VzIGxpc3RlZCBpbiB0aGUgU2VjdXJlX1BhdGggcG9ydGlvbiBvZiB0aGUg QkdQc2VjX1BhdGggYXR0cmlidXRlLiINCj4gSXMgdGhhdCB0cnVlPyBJdCBpcyBhc3N1cmVkIHRo YXQgYXQgbGVhc3QgdGhlc2UgQVNlcyBoYXZlIGJlZW4gY3Jvc3NlZCBidXQgdGhlcmUgbWlnaHQg aGF2ZSBiZWVuIG90aGVycyBvbiB0aGUgcGF0aCB0aGF0IGRpZCBub3Qgc2lnbiB0aGUgQkdQc2Vj X1BhdGggYXR0cmlidXRlLCBubz8NCg0KDQpbU3JpcmFtXSBZZXMsIGl0IGlzIHRydWUuIEVhY2gg QVMgaW4gdGhlIHBhdGggTVVTVCBzaWduIHRvIHRoZSBuZXh0IEFTIChUYXJnZXQgQVMpLiBTZWN0 aW9uIDMuMSBzYXlzOg0KDQoNCiAgICBUaGUgU2VjdXJlX1BhdGggY29udGFpbnMgb25lIFNlY3Vy ZV9QYXRoIFNlZ21lbnQgKHNlZSBGaWd1cmUgNSkgZm9yDQogICAgZWFjaCBBdXRvbm9tb3VzIFN5 c3RlbSBpbiB0aGUgcGF0aCB0byB0aGUgb3JpZ2luYXRpbmcgQVMgb2YgdGhlDQogICAgcHJlZml4 IHNwZWNpZmllZCBpbiB0aGUgdXBkYXRlIG1lc3NhZ2UuDQoNCg0KW1NyaXJhbV0gQWxzbywgU2Vj dGlvbiAzLjIgc2F5czoNCg0KDQogICAgQSBTaWduYXR1cmVfQmxvY2sgaW4gRmlndXJlIDYgaGFz IGV4YWN0bHkgb25lIFNpZ25hdHVyZSBTZWdtZW50IChzZWUNCiAgICBGaWd1cmUgNykgZm9yIGVh Y2ggU2VjdXJlX1BhdGggU2VnbWVudCBpbiB0aGUgU2VjdXJlX1BhdGggcG9ydGlvbiBvZg0KICAg IHRoZSBCR1BzZWNfUGF0aCBBdHRyaWJ1dGUuDQoNCg0KDQpbU3JpcmFtXSBUaGUgZm9sbG93aW5n IGNoZWNrIGxpc3RlZCBpbiBTZWN0aW9uIDUuMiBtYWtlIGl0IGNsZWFyIGFzIHdlbGw6DQoNCg0K ICAgIDMuICBDaGVjayB0aGF0IGVhY2ggU2lnbmF0dXJlX0Jsb2NrIGNvbnRhaW5zIG9uZSBTaWdu YXR1cmUgc2VnbWVudA0KICAgICAgICBmb3IgZWFjaCBTZWN1cmVfUGF0aCBTZWdtZW50IGluIHRo ZSBTZWN1cmVfUGF0aCBwb3J0aW9uIG9mIHRoZQ0KICAgICAgICBCR1BzZWNfUGF0aCBhdHRyaWJ1 dGUuICAoTm90ZSB0aGF0IHRoZSBlbnRpcmV0eSBvZiBlYWNoDQogICAgICAgIFNpZ25hdHVyZV9C bG9jayBtdXN0IGJlIGNoZWNrZWQgdG8gZW5zdXJlIHRoYXQgaXQgaXMgd2VsbCBmb3JtZWQsDQog ICAgICAgIGV2ZW4gdGhvdWdoIHRoZSB2YWxpZGF0aW9uIHByb2Nlc3MgbWF5IHRlcm1pbmF0ZSBi ZWZvcmUgYWxsDQogICAgICAgIHNpZ25hdHVyZXMgYXJlIGNyeXB0b2dyYXBoaWNhbGx5IHZlcmlm aWVkLikNCg0KDQoNCg== --_000_9B17A0C3343046439D0CB4554FF04510ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4D24153030369F42995E159418D2F037@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5NaXJq YTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5IaSE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij5JZiBhbiBBUyBpbiB0aGUgcGF0aCBkb2VzbuKAmXQgc3VwcG9ydCBCR1BzZWMsIHRoZW4gQkdQ IGdvZXMgYmFjayB0byDigJxub3JtYWzigJ0gbW9kZSAoYXMgaW4gYmVmb3JlIEJHUHNlYyksIGFu ZCB0aGUgYXNzdXJhbmNlIHRoYXQgdGhlIOKAnHVwZGF0ZSBwcm9wYWdhdGVkIHZpYSB0aGUgc2Vx dWVuY2Ugb2YgQVNlcyBsaXN0ZWTigJ0gaXMNCiBsb3N0LiZuYnNwOyBJbiBvdGhlciB3b3Jkcywg ZnJvbSB0aGUgb3JpZ2luIEFTIHRvIHRoZSBBUyBiZWZvcmUgdGhlIG9uZSBub3Qgc3VwcG9ydGlu ZyBCR1BzZWMsIHdlIGNhbiBzdGlsbCBwcm92aWRlIHRoZSBhc3N1cmFuY2UsIGJ1dCBub3QgYmV5 b25kIHRoYXQg4oCTIHNvIGFueSBBUyBpbmNsdWRpbmcgYW5kIGJleW9uZCB0aGUgb25lIG5vdCBz dXBwb3J0aW5nIEJHUHNlYyB3b27igJl0IGJlIGFibGUgdG8gdmVyaWZ5IGFueXRoaW5nLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkFsdmFyby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1 QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g MS8xNy8xNywgNjowNSBBTSwgJnF1b3Q7TWlyamEgS3VlaGxld2luZCAoSUVURikmcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0Ij5pZXRmQGt1ZWhsZXdpbmQubmV0 PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgU3JpcmFtLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGFua3MgZm9yIHlvdXIgcmVwbHkuIFRoYXTi gJlzIGFsbCBmaW5lLiBJIHJlYWxseSBkaWRu4oCZdCBleHBlY3QgYW55IHByb3RvY29sIGNoYW5n ZXMgYXQgdGhpcyBsYXRlIHN0YWdlIG9mIHRoZSBkcmFmdCBidXQgd2FudGVkIGF0IGxlYXN0IHRv IGtub3cgaWYgdGhlc2UgcG9pbnRzIHdlcmUgcHJldmlvdXNseSBkaXNjdXNzZWQuIEFsc28gaGFw cHkgdG8gc2VlIHRoYXQgc29tZSBwYXJ0cyB3aGVyZSBkaXNjdXNzZWQNCiB3aXRoIFJvc3MuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBm aW5hbCBxdWVzdGlvbiAocmVsYXRlZCB0byBwb2ludCA0KTogV2hhdCBoYXBwZW5zIGlmIG9uZSBy b3V0ZXIgb24gdGhlIHBhdGggZG9lcyBub3Qgc3VwcG9ydC91bmRlcnN0YW5kIEJHUHNlYz8gU29y cnksIGlmIHRoYXQgaXMgYSBzdHVwaWQgcXVlc3Rpb24gYnV0IGl04oCZcyBzdGlsbCBub3QgZnVs bHkgY2xlYXIgdG8gbWUgZnJvbSB0aGUgZHJhZnTigKY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlyamE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0 REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCmIDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyA0KSBzZWN0 aW9uIDguMSBzYXlzICZxdW90O3RoZSByZWNpcGllbnQgb2YgYSB2YWxpZCBCR1BzZWMgdXBkYXRl IG1lc3NhZ2UgaXMgYXNzdXJlZCB0aGF0IHRoZSB1cGRhdGUgcHJvcGFnYXRlZCB2aWEgdGhlIHNl cXVlbmNlIG9mIEFTZXMgbGlzdGVkIGluIHRoZSBTZWN1cmVfUGF0aCBwb3J0aW9uIG9mIHRoZSBC R1BzZWNfUGF0aCBhdHRyaWJ1dGUuJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IElzIHRoYXQgdHJ1ZT8gSXQgaXMgYXNzdXJlZCB0 aGF0IGF0IGxlYXN0IHRoZXNlIEFTZXMgaGF2ZSBiZWVuIGNyb3NzZWQgYnV0IHRoZXJlIG1pZ2h0 IGhhdmUgYmVlbiBvdGhlcnMgb24gdGhlIHBhdGggdGhhdCBkaWQgbm90IHNpZ24gdGhlIEJHUHNl Y19QYXRoIGF0dHJpYnV0ZSwgbm8/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W1NyaXJhbV0gWWVzLCBpdCBpcyB0cnVl LiBFYWNoIEFTIGluIHRoZSBwYXRoIE1VU1Qgc2lnbiB0byB0aGUgbmV4dCBBUyAoVGFyZ2V0IEFT KS4gU2VjdGlvbiAzLjEgc2F5czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtU aGUgU2VjdXJlX1BhdGggY29udGFpbnMgb25lIFNlY3VyZV9QYXRoIFNlZ21lbnQgKHNlZSBGaWd1 cmUgNSkgZm9yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtlYWNoIEF1dG9ub21vdXMgU3lzdGVtIGluIHRo ZSBwYXRoIHRvIHRoZSBvcmlnaW5hdGluZyBBUyBvZiB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3By ZWZpeCBzcGVjaWZpZWQgaW4gdGhlIHVwZGF0ZSBtZXNzYWdlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltTcmlyYW1d IEFsc28sIFNlY3Rpb24gMy4yIHNheXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7QSBTaWduYXR1cmVfQmxvY2sgaW4gRmlndXJlIDYgaGFzIGV4YWN0bHkgb25lIFNpZ25hdHVy ZSBTZWdtZW50IChzZWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0ZpZ3VyZSA3KSBmb3IgZWFjaCBTZWN1 cmVfUGF0aCBTZWdtZW50IGluIHRoZSBTZWN1cmVfUGF0aCBwb3J0aW9uIG9mPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDt0aGUgQkdQc2VjX1BhdGggQXR0cmlidXRlLiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+W1NyaXJhbV0gVGhlIGZvbGxvd2luZyBjaGVjayBsaXN0ZWQgaW4gU2VjdGlvbiA1 LjIgbWFrZSBpdCBjbGVhciBhcyB3ZWxsOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzMuJm5ic3A7Jm5ic3A7Q2hlY2sgdGhhdCBlYWNoIFNpZ25hdHVyZV9CbG9jayBjb250YWlu cyBvbmUgU2lnbmF0dXJlIHNlZ21lbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO2ZvciBlYWNoIFNlY3VyZV9QYXRoIFNlZ21lbnQgaW4gdGhlIFNlY3VyZV9QYXRo IHBvcnRpb24gb2YgdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtCR1BzZWNfUGF0aCBhdHRyaWJ1dGUuJm5ic3A7Jm5ic3A7KE5vdGUgdGhhdCB0aGUgZW50aXJl dHkgb2YgZWFjaDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7U2ln bmF0dXJlX0Jsb2NrIG11c3QgYmUgY2hlY2tlZCB0byBlbnN1cmUgdGhhdCBpdCBpcyB3ZWxsIGZv cm1lZCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2V2ZW4gdGhv dWdoIHRoZSB2YWxpZGF0aW9uIHByb2Nlc3MgbWF5IHRlcm1pbmF0ZSBiZWZvcmUgYWxsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzaWduYXR1cmVzIGFyZSBjcnlw dG9ncmFwaGljYWxseSB2ZXJpZmllZC4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyNC4wcHQiPiZu YnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9B17A0C3343046439D0CB4554FF04510ciscocom_-- From nobody Tue Jan 17 07:49:31 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5706D129512; Tue, 17 Jan 2017 07:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 dgraEaPGECUs; Tue, 17 Jan 2017 07:49:28 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BC6B129532; Tue, 17 Jan 2017 07:49:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16008; q=dns/txt; s=iport; t=1484668166; x=1485877766; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bIWw18fZdD77vEhDOGOvztWRWQc1bN1WCu/2DlmceyE=; b=DQoan/3d8ESIxgdKdX3/AtB6I6dTcJtvU7tJX8H5U/4Drt0pom7BVox8 EbSLug7vNf9M74KeYE2ES6R1KtybVfv9KBqXOddMKQKXHE/3YiiCsUsJb 61MW1x1Xe5i2O1P9XRPEBKL8EO5rAAtspzouHweoo47R4bItkjQ31iwva Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAQAePH5Y/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9KAQEBAQEfX4EJB4NKigeiGYUrgguGIgIagXg/GAECAQEBAQE?= =?us-ascii?q?BAWMohGoGI1YQAgEIPwMCAgIwFBECBAENBYkDr0KCJSuJWQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2GRYICgmWHTi2CMQWVL4YLAZFegXeFDoNNhhuIGopRAR84gUQ?= =?us-ascii?q?VSgGGIXOHS4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,245,1477958400"; d="scan'208,217";a="372979882" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2017 15:49:25 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v0HFnOY9015215 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Jan 2017 15:49:24 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 17 Jan 2017 09:49:23 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 17 Jan 2017 09:49:23 -0600 From: "Alvaro Retana (aretana)" To: "Sriram, Kotikalapudi (Fed)" , Keyur Patel Thread-Topic: draft-ietf-sidr-bgpsec-protocol Thread-Index: AQHSaHILNfH8MXPYLkOmxwl9coeqv6EoZskAgAKH0dSAASfLgIAG7GoAgAjunNuAAQEAgA== Date: Tue, 17 Jan 2017 15:49:23 +0000 Message-ID: <0E5D570D-46F3-476B-A890-920172BAF10A@cisco.com> References: <6C8E073D-F1AB-4588-8DFF-FAA0A2465273@cisco.com> <67DBF30E-B262-4568-87FB-96EEF9FB87A9@arrcus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_0E5D570D46F3476BA890920172BAF10Aciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , Jonathan Hardwick , "sidr-chairs@ietf.org" , sidr Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 15:49:30 -0000 --_000_0E5D570D46F3476BA890920172BAF10Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3JpcmFtOg0KDQpIaSENCg0KWWVzLCBJIHRoaW5rIEkgbWF5IGhhdmUgcmVhZCBtb3JlIGludG8g S2V5dXLigJlzIGNvbW1lbnQgdGhhbiB3aGF0IGhlIHdhcyBhc2tpbmcgZm9yLCBzbyBJIHRoaW5r IHdl4oCZcmUgcmVhZHkgdG8gZ28uIOKYug0KDQpJ4oCZbGwgYXBwcm92ZSBwdWJsaWNhdGlvbi4N Cg0KVGhhbmtzISENCg0KQWx2YXJvLg0KDQpPbiAxLzE2LzE3LCAxMDoxMCBQTSwgIlNyaXJhbSwg S290aWthbGFwdWRpIChGZWQpIiA8a290aWthbGFwdWRpLnNyaXJhbUBuaXN0LmdvdjxtYWlsdG86 a290aWthbGFwdWRpLnNyaXJhbUBuaXN0Lmdvdj4+IHdyb3RlOg0KDQpIaSBBbHZhcm8sDQoNCi4u LiBzbmlwIC4uLg0KQWx2YXJvIHdyb3RlOg0KSSBkb27igJl0IGhhdmUgYW4gb2JqZWN0aW9uIGZv ciB0aGlzIGJlaGF2aW9yLCBidXQgSSB0aGluaw0Kd2Ugc2hvdWxkIG1ha2UgdGhlIFdHIChhbmQg aWRyISkgYXdhcmUgb2YgdGhlIGNoYW5nZQ0KYW5kIGdldCB0aGVpciBjb21tZW50cyAoaWYgYW55 KSBiZWZvcmUgSSBhcHByb3ZlIHRoZSBwdWJsaWNhdGlvbi4NCg0KS2V5dXIgcmVzcG9uZGVkOg0K I0tleXVyOiBBY2suIFRob3VnaCBJIHdhcyBvbmx5IHJlcXVlc3Rpbmcgc29tZSB0ZXh0IGNsYXJp ZmljYXRpb24NCnNvIHRoYXQgaXQgaXMgdmVyeSBjbGVhciB0byB0aGUgaW1wbGVtZW50ZXJzLg0K DQpTbyB0aGVyZSB3YXMgbm8gY2hhbmdlIHJlcXVpcmVkIGFzIEtleXVyIHBvaW50cyBvdXQuDQpP bGl2ZXIgYWxzbyBhZ3JlZWQgd2l0aCBLZXl1cidzIG9ic2VydmF0aW9uIHdoZW4gSSByYW4gdGhp cyBieSBoaW0gbGFzdCB3ZWVrLg0KUGVyIEtleXVyJ3MgcmVxdWVzdCwgSSBoYXZlIGFkZGVkIHRo ZSBmb2xsb3dpbmcgdGV4dCBjbGFyaWZpY2F0aW9uIGluIFNlY3Rpb24gNzoNCg0KICAgRHVyaW5n IEdyYWNlZnVsIFJlc3RhcnQgKEdSKSwgcmVzdGFydGluZyBhbmQgcmVjZWl2aW5nIEJHUHNlYw0K ICAgc3BlYWtlcnMgTVVTVCBmb2xsb3cgdGhlIHByb2NlZHVyZXMgc3BlY2lmaWVkIGluIFtSRkM0 NzI0XSBmb3INCiAgIHJlc3RhcnRpbmcgYW5kIHJlY2VpdmluZyBCR1Agc3BlYWtlcnMsIHJlc3Bl Y3RpdmVseS4gIEluIHBhcnRpY3VsYXIsDQogICB0aGUgYmVoYXZpb3Igb2YgcmV0YWluaW5nIHRo ZSBmb3J3YXJkaW5nIHN0YXRlIGZvciB0aGUgcm91dGVzIGluIHRoZQ0KICAgTG9jLVJJQiBbUkZD NDI3MV0gYW5kIG1hcmtpbmcgdGhlbSBhcyBzdGFsZSBhcyB3ZWxsIGFzIG5vdA0KICAgZGlmZmVy ZW50aWF0aW5nIGJldHdlZW4gc3RhbGUgYW5kIG90aGVyIGluZm9ybWF0aW9uIGR1cmluZyBmb3J3 YXJkaW5nDQogICB3aWxsIGJlIHRoZSBzYW1lIGFzIHNwZWNpZmllZCBpbiBbUkZDNDcyNF0uDQoN Ci4uLnNuaXAuLi4NCkFsdmFybyB3cm90ZToNCuKApmhvdyBzaG91bGQgYW4gaUJHUCBzcGVha2Vy IHBlcmZvcm0gbG9vcCBkZXRlY3Rpb24NCmlmIHRoZXJl4oCZcyBubyBCR1BzZWNfUGF0aCBhdHRy aWJ1dGU/ICBJbiBvdGhlciB3b3JkcywNCnRoZXJlIGlzIG5vIGRlZmluZWQgbWVjaGFuaXNtIHRv IHJ1biB0aGUgYWxnb3JpdGhtIGluIDQuNCB3aXRob3V0IGl0Lg0KDQpJ4oCZbSBub3Qgc3VnZ2Vz dGluZyB0aGF0IHlvdSBpbmNsdWRlIGFuIGVtcHR5IGF0dHJpYnV0ZSwNCmJ1dCB0aGF0IHlvdSBp bmRpY2F0ZSBpbiA0LjQgdGhhdCBubyBCR1BzZWNfUGF0aCBhdHRyaWJ1dGUNCmlzIGVxdWl2YWxl bnQgdG8gYW4gZW1wdHkgQVNfUEFUSC4NCg0KUGVyIHlvdXIgc3VnZ2VzdGlvbiwgSSBoYXZlIGFk ZGVkIHRoZSBmb2xsb3dpbmcgdGV4dCBpbiBTZWN0aW9uIDQuNDoNCg0KICAgRmluYWxseSwgb25l IHNwZWNpYWwgY2FzZSBvZiByZWNvbnN0cnVjdGlvbiBvZiBBU19QQVRIIGlzIHdoZW4gdGhlDQog ICBCR1BzZWNfUGF0aCBhdHRyaWJ1dGUgaXMgYWJzZW50LiAgQXMgZXhwbGFpbmVkIGluIFNlY3Rp b24gNC4xLCB3aGVuIGENCiAgIEJHUHNlYyBzcGVha2VyIG9yaWdpbmF0ZXMgYSBwcmVmaXggYW5k IHNlbmRzIGl0IHRvIGEgQkdQc2VjLWNhcGFibGUNCiAgIGlCR1AgcGVlciwgdGhlIEJHUHNlY19Q YXRoIGlzIG5vdCBhdHRhY2hlZC4gIFNvIHdoZW4gcmVjZWl2ZWQgZnJvbSBhDQogICBCR1BzZWMt Y2FwYWJsZSBpQkdQIHBlZXIsIG5vIEJHUHNlY19QYXRoIGF0dHJpYnV0ZSBpbiBhIEJHUHNlYyB1 cGRhdGUNCiAgIGlzIGVxdWl2YWxlbnQgdG8gYW4gZW1wdHkgQVNfUEFUSCBbUkZDNDI3MV0uDQoN ClBsZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBhbnkgY29tbWVudHMvcXVlc3Rpb25zLg0K DQpUaGFuayB5b3UuDQoNClNyaXJhbQ0K --_000_0E5D570D46F3476BA890920172BAF10Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <385016FE75E71F4BA1938321FECEC132@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAg MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsN CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDsNCglm b250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5tc29JbnMNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPlNyaXJhbTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5IaSE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5ZZXMsIEkgdGhpbmsgSSBtYXkgaGF2ZSByZWFkIG1vcmUgaW50byBL ZXl1cuKAmXMgY29tbWVudCB0aGFuIHdoYXQgaGUgd2FzIGFza2luZyBmb3IsIHNvIEkgdGhpbmsg d2XigJlyZSByZWFkeSB0byBnby4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpXaW5nZGluZ3MiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+SeKA mWxsIGFwcHJvdmUgcHVibGljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtz ISE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5BbHZhcm8uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEvMTYvMTcsIDEwOjEw IFBNLCAmcXVvdDtTcmlyYW0sIEtvdGlrYWxhcHVkaSAoRmVkKSZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmtvdGlrYWxhcHVkaS5zcmlyYW1AbmlzdC5nb3YiPmtvdGlrYWxhcHVkaS5zcmlyYW1A bmlzdC5nb3Y8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBBbHZhcm8sPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi4uLiBzbmlwIC4uLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWx2YXJvIHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRU UklCVVRJT05fQkxPQ0tRVU9URSI+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21h cmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklC VVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb27igJl0 IGhhdmUgYW4gb2JqZWN0aW9uIGZvciB0aGlzIGJlaGF2aW9yLCBidXQgSSB0aGluayA8bzpwPg0K PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2Ugc2hvdWxk IG1ha2UgdGhlIFdHIChhbmQgaWRyISkgYXdhcmUgb2YgdGhlIGNoYW5nZSA8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCBnZXQgdGhlaXIgY29t bWVudHMgKGlmIGFueSkgYmVmb3JlIEkgYXBwcm92ZSB0aGUgcHVibGljYXRpb24uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPktleXVyIHJlc3BvbmRlZDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0 REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFy Z2luLXJpZ2h0OjBpbiIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiNLZXl1cjogQWNrLiBUaG91Z2ggSSB3YXMgb25s eSByZXF1ZXN0aW5nIHNvbWUgdGV4dCBjbGFyaWZpY2F0aW9uDQo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNvIHRoYXQgaXQgaXMgdmVyeSBjbGVh ciB0byB0aGUgaW1wbGVtZW50ZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB0aGVyZSB3YXMgbm8gY2hhbmdl IHJlcXVpcmVkIGFzIEtleXVyIHBvaW50cyBvdXQuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T2xpdmVyIGFsc28gYWdyZWVkIHdpdGggS2V5dXIn cyBvYnNlcnZhdGlvbiB3aGVuIEkgcmFuIHRoaXMgYnkgaGltIGxhc3Qgd2Vlay48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBlciBLZXl1cidzIHJl cXVlc3QsIEkgaGF2ZSBhZGRlZCB0aGUgZm9sbG93aW5nIHRleHQgY2xhcmlmaWNhdGlvbiBpbiBT ZWN0aW9uIDc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwOyBEdXJpbmcgR3JhY2VmdWwgUmVzdGFydCAoR1IpLCByZXN0YXJ0 aW5nIGFuZCByZWNlaXZpbmcgQkdQc2VjPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgc3BlYWtlcnMgTVVTVCBmb2xsb3cgdGhl IHByb2NlZHVyZXMgc3BlY2lmaWVkIGluIFtSRkM0NzI0XSBmb3I8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyByZXN0YXJ0aW5n IGFuZCByZWNlaXZpbmcgQkdQIHNwZWFrZXJzLCByZXNwZWN0aXZlbHkuJm5ic3A7Jm5ic3A7SW4g cGFydGljdWxhciw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwOyB0aGUgYmVoYXZpb3Igb2YgcmV0YWluaW5nIHRoZSBmb3J3YXJk aW5nIHN0YXRlIGZvciB0aGUgcm91dGVzIGluIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IExvYy1SSUIgW1JGQzQyNzFd IGFuZCBtYXJraW5nIHRoZW0gYXMgc3RhbGUgYXMgd2VsbCBhcyBub3Q8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBkaWZmZXJl bnRpYXRpbmcgYmV0d2VlbiBzdGFsZSBhbmQgb3RoZXIgaW5mb3JtYXRpb24gZHVyaW5nIGZvcndh cmRpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyB3aWxsIGJlIHRoZSBzYW1lIGFzIHNwZWNpZmllZCBpbiBbUkZDNDcyNF0u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi4u LnNuaXAuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFsdmFybyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiIgaWQ9 Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiIgaWQ9Ik1B Q19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPuKApmhvdyBzaG91bGQgYW4gaUJHUCBzcGVha2VyIHBlcmZvcm0gbG9vcCBkZXRlY3Rp b24gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5p ZiB0aGVyZeKAmXMgbm8gQkdQc2VjX1BhdGggYXR0cmlidXRlPyZuYnNwOyZuYnNwO0luIG90aGVy IHdvcmRzLCA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPnRoZXJlIGlzIG5vIGRlZmluZWQgbWVjaGFuaXNtIHRvIHJ1biB0aGUgYWxnb3JpdGhtIGlu IDQuNCB3aXRob3V0IGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5J4oCZbSBub3Qgc3VnZ2VzdGluZyB0aGF0IHlvdSBpbmNsdWRlIGFuIGVt cHR5IGF0dHJpYnV0ZSwgPG86cD4NCjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmJ1dCB0aGF0IHlvdSBpbmRpY2F0ZSBpbiA0LjQgdGhhdCBubyBCR1BzZWNf UGF0aCBhdHRyaWJ1dGUgPG86cD4NCjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmlzIGVxdWl2YWxlbnQgdG8gYW4gZW1wdHkgQVNfUEFUSC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UGVyIHlvdXIgc3VnZ2VzdGlvbiwgSSBoYXZlIGFkZGVkIHRoZSBm b2xsb3dpbmcgdGV4dCBpbiBTZWN0aW9uIDQuNDoNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgRmluYWxseSwgb25lIHNw ZWNpYWwgY2FzZSBvZiByZWNvbnN0cnVjdGlvbiBvZiBBU19QQVRIIGlzIHdoZW4gdGhlPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDsgQkdQc2VjX1BhdGggYXR0cmlidXRlIGlzIGFic2VudC4mbmJzcDsmbmJzcDtBcyBleHBsYWlu ZWQgaW4gU2VjdGlvbiA0LjEsIHdoZW4gYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IEJHUHNlYyBzcGVha2VyIG9yaWdpbmF0 ZXMgYSBwcmVmaXggYW5kIHNlbmRzIGl0IHRvIGEgQkdQc2VjLWNhcGFibGU8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBpQkdQ IHBlZXIsIHRoZSBCR1BzZWNfUGF0aCBpcyBub3QgYXR0YWNoZWQuJm5ic3A7Jm5ic3A7U28gd2hl biByZWNlaXZlZCBmcm9tIGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBCR1BzZWMtY2FwYWJsZSBpQkdQIHBlZXIsIG5vIEJH UHNlY19QYXRoIGF0dHJpYnV0ZSBpbiBhIEJHUHNlYyB1cGRhdGU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBpcyBlcXVpdmFs ZW50IHRvIGFuIGVtcHR5IEFTX1BBVEggW1JGQzQyNzFdLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91 IGhhdmUgYW55IGNvbW1lbnRzL3F1ZXN0aW9ucy4gPG86cD4NCjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TcmlyYW08bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0E5D570D46F3476BA890920172BAF10Aciscocom_-- From nobody Tue Jan 17 07:52:33 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33406129546 for ; Tue, 17 Jan 2017 07:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 DwKvTk6YvA5H for ; Tue, 17 Jan 2017 07:52:28 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33887129541 for ; Tue, 17 Jan 2017 07:52:28 -0800 (PST) Received: (qmail 28402 invoked from network); 17 Jan 2017 16:52:26 +0100 Received: from p5dec276e.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.39.110) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Jan 2017 16:52:26 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <9B17A0C3-3430-4643-9D0C-B4554FF04510@cisco.com> Date: Tue, 17 Jan 2017 16:52:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1348EA28-8876-4B85-9F39-1AB74A5C6333@kuehlewind.net> References: <148355465867.12949.10785749487953700357.idtracker@ietfa.amsl.com> <9B17A0C3-3430-4643-9D0C-B4554FF04510@cisco.com> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , Alexey Melnikov , "Sriram, Kotikalapudi \(Fed\)" , "sidr-chairs@ietf.org" , The IESG , "sidr@ietf.org" , Matthias Waehlisch Subject: Re: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-bgpsec-protocol-21=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 15:52:32 -0000 Hi Alvaro, thanks for the very clear clarification. Not sure if it=E2=80=99s just = me or if that=E2=80=99s not clearly stated in the draft, but maybe it = would be worth it double-checking. Mirja > Am 17.01.2017 um 16:47 schrieb Alvaro Retana (aretana) = : >=20 > Mirja: > =20 > Hi! > =20 > If an AS in the path doesn=E2=80=99t support BGPsec, then BGP goes = back to =E2=80=9Cnormal=E2=80=9D mode (as in before BGPsec), and the = assurance that the =E2=80=9Cupdate propagated via the sequence of ASes = listed=E2=80=9D is lost. In other words, from the origin AS to the AS = before the one not supporting BGPsec, we can still provide the = assurance, but not beyond that =E2=80=93 so any AS including and beyond = the one not supporting BGPsec won=E2=80=99t be able to verify anything. > =20 > Alvaro. > =20 > =20 > =20 > =20 >> On 1/17/17, 6:05 AM, "Mirja Kuehlewind (IETF)" = wrote: >> =20 >> Hi Sriram, >> =20 >> thanks for your reply. That=E2=80=99s all fine. I really didn=E2=80=99t= expect any protocol changes at this late stage of the draft but wanted = at least to know if these points were previously discussed. Also happy = to see that some parts where discussed with Ross. >> =20 >> One final question (related to point 4): What happens if one router = on the path does not support/understand BGPsec? Sorry, if that is a = stupid question but it=E2=80=99s still not fully clear to me from the = draft=E2=80=A6 >> =20 >> Mirja >>> =E2=80=A6=20 >>> > 4) section 8.1 says "the recipient of a valid BGPsec update = message is assured that the update propagated via the sequence of ASes = listed in the Secure_Path portion of the BGPsec_Path attribute." >>> > Is that true? It is assured that at least these ASes have been = crossed but there might have been others on the path that did not sign = the BGPsec_Path attribute, no? >>> =20 >>> =20 >>> [Sriram] Yes, it is true. Each AS in the path MUST sign to the next = AS (Target AS). Section 3.1 says: >>> =20 >>> =20 >>> The Secure_Path contains one Secure_Path Segment (see Figure 5) = for >>> each Autonomous System in the path to the originating AS of the >>> prefix specified in the update message. >>> =20 >>> =20 >>> [Sriram] Also, Section 3.2 says: >>> =20 >>> =20 >>> A Signature_Block in Figure 6 has exactly one Signature Segment = (see >>> Figure 7) for each Secure_Path Segment in the Secure_Path = portion of >>> the BGPsec_Path Attribute. =20 >>> =20 >>> =20 >>> =20 >>> [Sriram] The following check listed in Section 5.2 make it clear as = well: >>> =20 >>> =20 >>> 3. Check that each Signature_Block contains one Signature = segment >>> for each Secure_Path Segment in the Secure_Path portion of = the >>> BGPsec_Path attribute. (Note that the entirety of each >>> Signature_Block must be checked to ensure that it is well = formed, >>> even though the validation process may terminate before all >>> signatures are cryptographically verified.) >>> =20 >>> =20 >> =20 From nobody Tue Jan 17 07:54:20 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7A6129546; Tue, 17 Jan 2017 07:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 eNZ-HpCKdFV1; Tue, 17 Jan 2017 07:54:17 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2494F129426; Tue, 17 Jan 2017 07:54:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4238; q=dns/txt; s=iport; t=1484668457; x=1485878057; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tiupgJyg4l4BJIFDr6tK71IelyYhR8wz/hrmGDx+AYQ=; b=Y7gDFBC/nZIiDCQSaZgKvOMZg+ctHWeLss0PdA1wCOQxIcsfL9J2EHqi 2BCg6PGMCLl/yypt4mUnttImIRJaD8yqrL5oVzNCKLRutCjmaUlpSw1cu TqAAXrcRrAb3qf/rdH/8NL2IBxlfgV+SbgRDWUrHulCcQyUNu2iiDjEMd E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAQA7PX5Y/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9KAQEBAQEfX4EJB4NKigeReZAgUIJMgg+CC4YiAhqBeD8YAQI?= =?us-ascii?q?BAQEBAQEBYyiEagYjVhACAQgEOwMCAgIwFAYLAgQOBYkDr0WCJSuJWQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2GRYICCIJdh04tgjEFmzoBkV6QbZJrAR84gUQVSgG?= =?us-ascii?q?EWoFHc4dLgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,245,1477958400"; d="scan'208,217";a="194197960" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2017 15:54:16 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v0HFsGKQ015465 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Jan 2017 15:54:16 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 17 Jan 2017 09:54:15 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 17 Jan 2017 09:54:15 -0600 From: "Alvaro Retana (aretana)" To: "Mirja Kuehlewind (IETF)" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-sidr-bgpsec-protocol-21:_(with_COMMENT)?= Thread-Index: AQHScLGgbhRfSiDCEU+RaxlXyOSsTqE84V2AgABVOYD//6yygA== Date: Tue, 17 Jan 2017 15:54:15 +0000 Message-ID: References: <148355465867.12949.10785749487953700357.idtracker@ietfa.amsl.com> <9B17A0C3-3430-4643-9D0C-B4554FF04510@cisco.com> <1348EA28-8876-4B85-9F39-1AB74A5C6333@kuehlewind.net> In-Reply-To: <1348EA28-8876-4B85-9F39-1AB74A5C6333@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_A6A1E78180194152B646FA23CC76E0AAciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , Alexey Melnikov , "Sriram, Kotikalapudi \(Fed\)" , "sidr-chairs@ietf.org" , The IESG , "sidr@ietf.org" , Matthias Waehlisch Subject: Re: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-bgpsec-protocol-21=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 15:54:18 -0000 --_000_A6A1E78180194152B646FA23CC76E0AAciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QUNLDQoNCk9uIDEvMTcvMTcsIDEwOjUyIEFNLCAiTWlyamEgS3VlaGxld2luZCAoSUVURikiIDxp ZXRmQGt1ZWhsZXdpbmQubmV0PG1haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0Pj4gd3JvdGU6DQoN CnRoYW5rcyBmb3IgdGhlIHZlcnkgY2xlYXIgY2xhcmlmaWNhdGlvbi4gTm90IHN1cmUgaWYgaXTi gJlzIGp1c3QgbWUgb3IgaWYgdGhhdOKAmXMgbm90IGNsZWFybHkgc3RhdGVkIGluIHRoZSBkcmFm dCwgYnV0IG1heWJlIGl0IHdvdWxkIGJlIHdvcnRoIGl0IGRvdWJsZS1jaGVja2luZy4NCg== --_000_A6A1E78180194152B646FA23CC76E0AAciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4611344B2BCFD64DA37644D874D8CC9D@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3Rl eHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNv SW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5BQ0s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMS8xNy8xNywgMTA6NTIgQU0sICZxdW90O01pcmph IEt1ZWhsZXdpbmQgKElFVEYpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBrdWVobGV3 aW5kLm5ldCI+aWV0ZkBrdWVobGV3aW5kLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+dGhhbmtzIGZvciB0aGUgdmVyeSBjbGVhciBj bGFyaWZpY2F0aW9uLiBOb3Qgc3VyZSBpZiBpdOKAmXMganVzdCBtZSBvciBpZiB0aGF04oCZcyBu b3QgY2xlYXJseSBzdGF0ZWQgaW4gdGhlIGRyYWZ0LCBidXQgbWF5YmUgaXQgd291bGQgYmUgd29y dGggaXQgZG91YmxlLWNoZWNraW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A6A1E78180194152B646FA23CC76E0AAciscocom_-- From nobody Tue Jan 17 09:22:23 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F83127077; Tue, 17 Jan 2017 09:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 QXsT2wJAuihP; Tue, 17 Jan 2017 09:22:20 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599A1120725; Tue, 17 Jan 2017 09:22:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6506; q=dns/txt; s=iport; t=1484673740; x=1485883340; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LYqi6LyBD9S9r4mi2SEOI52/9F22RZGB6I3zEJEo1KE=; b=Nlc5WzzhdP/rkPkip3aYS79cbZNpG0YX42fbfw+dKI60uCI8jEAvTBsJ B7WY4ftXAKD9qEyJFEvK0Cg6z0HLq6oiIDKmtYx9tqDW84nVNAEbKQGOj ojU5WcmSFmeIUrpGxAyi4NWblXYPgMYXGkm1XzX9sZwMDKyBGL0VRbGt2 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAQBpUX5Y/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9KAQEBAQEfX4EJB4NKigeiGYUrgguGIgIagXk/GAECAQEBAQE?= =?us-ascii?q?BAWMohGoGI1YQAgEIPwMCAgIwFBECBAENBYkDr1GCJSuJfAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2GRYICgmWHTi2CMQWVL4YLAYlzh2uBd4UOiWiIGopRAR84gUQ?= =?us-ascii?q?VSgGGIXOHS4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,245,1477958400"; d="scan'208,217";a="372865676" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2017 17:22:19 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v0HHMJ7w016852 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Jan 2017 17:22:19 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 17 Jan 2017 11:22:18 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 17 Jan 2017 11:22:18 -0600 From: "Alvaro Retana (aretana)" To: Oleg Muravskiy , IETF SIDR Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-delta-protocol-05.txt Thread-Index: AQHSb/iGiqs+B0gGXk2c9GKVBlmwMKE7d+mAgAGFawA= Date: Tue, 17 Jan 2017 17:22:18 +0000 Message-ID: References: <148457160928.22540.4235560949029260207.idtracker@ietfa.amsl.com> <229D5EB4-25A5-4FB4-A24C-3A468FCC5074@ripe.net> In-Reply-To: <229D5EB4-25A5-4FB4-A24C-3A468FCC5074@ripe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_FCC7F3982FF5499CAF60D3CA6964A80Bciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sidr-chairs@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-delta-protocol-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 17:22:22 -0000 --_000_FCC7F3982FF5499CAF60D3CA6964A80Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W09sZWc6ICBUaGFua3MgZm9yIHRoZSB1cGRhdGUhXQ0KDQpEZWFyIFdHOg0KDQpPbmUgb2YgdGhl IHNpZ25pZmljYW50IGNoYW5nZXMgaW4gdGhpcyB2ZXJzaW9uIGlzIGFuIFVwZGF0ZSB0byBSRkM2 NDgwLCBSRkM2NDgxLCBhbmQgUkZDNzczMCwgaW4gb3JkZXIgdG8gcmVtb3ZlIHRoZSBub3JtYXRp dmUgZGVwZW5kZW5jeSBvbiByc3luYyBhcyBuZWVkZWQgaW4gZXZlcnkgZGVwbG95bWVudC4gIFBs ZWFzZSB0YWtlIGEgY2xvc2UgbG9vayBhdCB0aGUgbmV3IHRleHQgaW4gU2VjdGlvbiA0Lg0KDQpU aGFua3MhDQoNCkFsdmFyby4NCg0KDQoNCk9uIDEvMTYvMTcsIDg6MDggQU0sICJzaWRyIG9uIGJl aGFsZiBvZiBPbGVnIE11cmF2c2tpeSIgPHNpZHItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lk ci1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Ygb2xlZ0ByaXBlLm5ldDxtYWlsdG86b2xl Z0ByaXBlLm5ldD4+IHdyb3RlOg0KDQpUaGlzIGlzIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGUg ZHJhZnQtaWV0Zi1zaWRyLWRlbHRhLXByb3RvY29sLCByZXNvbHZpbmcgY29tbWVudHMgZnJvbSB0 aGUgQUQgcmV2aWV3Lg0KDQo= --_000_FCC7F3982FF5499CAF60D3CA6964A80Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <186391D03722334AA5092F3EFEDE1574@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3Rl eHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNv SW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5bT2xlZzombmJzcDsgVGhhbmtzIGZvciB0aGUgdXBkYXRlIV08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj5EZWFyIFdHOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki Pk9uZSBvZiB0aGUgc2lnbmlmaWNhbnQgY2hhbmdlcyBpbiB0aGlzIHZlcnNpb24gaXMgYW4gVXBk YXRlIHRvIFJGQzY0ODAsIFJGQzY0ODEsIGFuZCBSRkM3NzMwLCBpbiBvcmRlciB0byByZW1vdmUg dGhlIG5vcm1hdGl2ZSBkZXBlbmRlbmN5IG9uIHJzeW5jIGFzIG5lZWRlZCBpbiBldmVyeSBkZXBs b3ltZW50LiZuYnNwOyBQbGVhc2UNCiB0YWtlIGEgY2xvc2UgbG9vayBhdCB0aGUgbmV3IHRleHQg aW4gU2VjdGlvbiA0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rcyE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5BbHZhcm8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDoz Ljc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIDEvMTYvMTcsIDg6MDggQU0sICZxdW90O3NpZHIgb24gYmVoYWxmIG9mIE9sZWcgTXVy YXZza2l5JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2lkci1ib3VuY2VzQGlldGYub3JnIj5z aWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOm9s ZWdAcmlwZS5uZXQiPm9sZWdAcmlwZS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+VGhpcyBpcyBhbiB1cGRhdGVkIHZlcnNpb24gb2YgdGhlIGRyYWZ0 LWlldGYtc2lkci1kZWx0YS1wcm90b2NvbCwgcmVzb2x2aW5nIGNvbW1lbnRzIGZyb20gdGhlIEFE IHJldmlldy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_FCC7F3982FF5499CAF60D3CA6964A80Bciscocom_-- From nobody Tue Jan 17 10:00:30 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C84129424; Tue, 17 Jan 2017 10:00:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148467602955.32082.12289843566112325669.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2017 10:00:29 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-oob-setup@ietf.org, sidr@ietf.org Subject: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-rpki-oob-setup-06: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 18:00:29 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sidr-rpki-oob-setup-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-oob-setup/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) I agree with Mirja that this document seems to be missing the actual protocol specification, unless Section 6 is meant to provide the normative specification of how the messages are to be exchanged. Is it? If so, I would expect that to be explicit in the document. (2) If there is in fact supposed to be a protocol specified here, I have the same question as I had on draft-ietf-sidr-publication, which is how do the entities migrate from one version to another and do version negotiation? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 5.2.4: Per my comment on draft-ietf-sidr-publication, it would be good if service_uri accommodated either HTTPS or HTTP URLs, if HTTP URLs must be supported. 5.4: If it becomes obvious that a new reason code needs to be added to the element in the future, will that require a new version of the protocol? That seems like a bit of a heavy lift as compared to, say, creating a registry for these with an appropriate registration policy. From nobody Tue Jan 17 11:02:05 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C42129474; Tue, 17 Jan 2017 11:02:04 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148467972417.32014.8458088398368216411.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2017 11:02:04 -0800 Archived-At: Cc: Chris Morrow , draft-ietf-sidr-delta-protocol@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: [sidr] Last Call: (RPKI Repository Delta Protocol) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 19:02:04 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'RPKI Repository Delta Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-01-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In the Resource Public Key Infrastructure (RPKI), certificate authorities publish certificates, including end entity certificates, Certificate Revocation Lists (CRL), and RPKI signed objects to repositories. Relying Parties (RP) retrieve the published information from those repositories. This document specifies a protocol which provides relying parties with a mechanism to query a repository for incremental updates using the HTTP Over TLS (HTTPS) [RFC2818] protocol, thus enabling the RP to keep its state in sync with the repository using a secure transport channel. This document updates [RFC6480], [RFC6481], and [RFC7730]. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5781: The rsync URI Scheme (Informational - IETF stream) rfc2818: HTTP Over TLS (Informational - IETF stream) rfc6480: An Infrastructure to Support Secure Internet Routing (Informational - IETF stream) All 3 references have been considered by the community before and are already listed in the acceptable Downref Registry: https://trac.ietf.org/trac/iesg/wiki/DownrefRegistry From nobody Tue Jan 17 11:34:30 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13C3129597; Tue, 17 Jan 2017 11:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=unavailable 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 htsPA0m5dlE3; Tue, 17 Jan 2017 11:34:28 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 CAF16129587; Tue, 17 Jan 2017 11:34:28 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v0HJYIvd097441 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 17 Jan 2017 13:34:18 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Sriram, Kotikalapudi" Date: Tue, 17 Jan 2017 13:34:40 -0600 Message-ID: In-Reply-To: References: <148356622825.12945.17416255063037873581.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , "sidr-chairs@ietf.org" , The IESG , "sidr@ietf.org" , Matthias Waehlisch Subject: Re: [sidr] Ben Campbell's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 19:34:29 -0000 Thanks for the response. I have one remaining comment, below. I removed = sections that I think are resolved. Thanks! Ben. On 14 Jan 2017, at 11:23, Sriram, Kotikalapudi (Fed) wrote: >> >> - 8.4, last paragraph: The text describes a replay attack, and = >> delegates >> the mitigation solution to. This is an >> informational reference; it draft-ietf-sidr-bgpsec-rollover >> seems like it should be normative. > > The solution for mitigation of replay attacks is out of band > (in relation to the BGPsec protocol). > As I see it, draft-ietf-sidr-bgpsec-rollover proposes 'a way' > of replay attack mitigation. Techniques for key rollover / > replay attack mitigation are expected to continue to evolve. > There are various variants of the basic key rollover technique that > are discussed in this informational draft: > https://tools.ietf.org/html/draft-sriram-replay-protection-design-discu= ssion-07 > What needs to be pointed out in the BGPsec specification is that > there are solutions available for replay attack mitigation. > The above are the reasons why > draft-ietf-sidr-bgpsec-rollover is included in informational = > references. That is a reasonable response, if you think it is realistic that people = would implement solutions other than the one in the reference. It would = help if the text were more clear that draft-ietf-sider-bgpsec rollover = is an example of a possible solutions, and other solutions are possible. From nobody Tue Jan 17 14:05:37 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 506ED1295CB; Tue, 17 Jan 2017 14:05:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Peter Yee To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148469073332.32074.8816499370686348748.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2017 14:05:33 -0800 Archived-At: Cc: draft-ietf-sidr-publication.all@ietf.org, ietf@ietf.org, sidr@ietf.org Subject: [sidr] Review of draft-ietf-sidr-publication-10 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 22:05:33 -0000 Reviewer: Peter Yee Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-sidr-publication-10 Reviewer: Peter Yee Review Date: 2017-01-17 IETF LC End Date: 2017-01-06 IESG Telechat date: 2017-01-19 Summary: This specification defines a protocol for handling objects in an RPKI repository. Version 10 gives additional explanatory text that is helpful and fixes the nits I previously submitted. Major issues: None Minor issues: None Nits/editorial comments: Page 3, Section 1, 2nd paragraph before end of page, 2nd sentence: change "RCC" to "RFC". Page 6, Section 2.2, 3rd paragraph, 3rd sentence: delete "is" before "MUST". Page 7, 5th full paragraph: change "messages" to "message". From nobody Tue Jan 17 19:41:19 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B4D1294B7; Tue, 17 Jan 2017 19:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 Okr_s3VJ6D3o; Tue, 17 Jan 2017 19:41:15 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0116.outbound.protection.outlook.com [23.103.201.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1506127058; Tue, 17 Jan 2017 19:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6AJ0Uw7ZMc/Xtoq9gJzqIEZKRajJSvMZZK8OGptxd7Q=; b=fUhpHhNJoKLS7QOEXFre9ao7uqL9ZzZtmj6VtKeQchRJUesK8aY7DwulR3Ch/4WuCWTUPwazPEs1FbOqh5o6eeNomKjJEXwBHXwYN3pz3x07KuoCwtfYbpuzViBQKJn5Vz48+QLgJqwHmCG1I3wH4KkKAWkbZCUCM97aTH/BVkk= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0445.namprd09.prod.outlook.com (10.161.252.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Wed, 18 Jan 2017 03:41:12 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0845.013; Wed, 18 Jan 2017 03:41:12 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "Mirja Kuehlewind (IETF)" , "Alvaro Retana (aretana)" Thread-Topic: =?Windows-1252?Q?Mirja_K=FChlewind's_No_Objection_on_draft-ietf-sidr-bgps?= =?Windows-1252?Q?ec-protocol-21:_(with_COMMENT)?= Thread-Index: AQHSZrizhvIT4qoXnkq4q8a0RO1mhqE28/SggAWh0ACAAE7JgIAAAWaAgADCZCE= Date: Wed, 18 Jan 2017 03:41:12 +0000 Message-ID: References: <148355465867.12949.10785749487953700357.idtracker@ietfa.amsl.com> <9B17A0C3-3430-4643-9D0C-B4554FF04510@cisco.com>, <1348EA28-8876-4B85-9F39-1AB74A5C6333@kuehlewind.net> In-Reply-To: <1348EA28-8876-4B85-9F39-1AB74A5C6333@kuehlewind.net> 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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.222.227] x-ms-office365-filtering-correlation-id: bdc7395e-c1f4-4b91-164c-08d43f53d962 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0445; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0445; 7:u+As5K6nw+FyOCEuEhWtLKpKksVGCAUoWhtCL6qvoMc+4XtX/4APQef9iqcHA4xJWOHaCn6EZxX3tnBSfSoIwsQT0YILdvxQOwuhVe9OkGx/HG5P3kYybju9JFQ9JQkKfxxFbZonwfzhsSoQqcgdZvVL4Z884RxbM9tDlEQtTHodZinqlQZ7ICqGkQf0zg3lc4vweK3uyedpHr66854PPDj5TJjpplFzqEJkRHzDet/XhBQtECwjW6Otc1CLhUS3pJc5sUF+Sv8qVR6xcTpkP7xeS6kF6sgah+vDht/1APFLx2BKuYOgD9FIp6RyeO9pkfW6hl9gjs+5aigGxujsD68btO16PAMoX7Bx7B5LuNZayHYVploJ0zFtuOs8XOWJaY2Df/7INaWM9WeDC1idRZZOY1yMr9wEr0k3+vmRIr8r4D7Vq2Ga22Ut7JnKHwkjPtj+PygtGlW8URL7wk/hJg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:DM2PR09MB0445; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0445; x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39450400003)(39860400002)(39850400002)(39410400002)(189002)(377454003)(199003)(51914003)(24454002)(53936002)(4326007)(189998001)(2906002)(55016002)(5001770100001)(54906002)(97736004)(33656002)(2900100001)(81156014)(5660300001)(6436002)(99286003)(9686003)(66066001)(77096006)(92566002)(8666007)(229853002)(6506006)(38730400001)(230783001)(54356999)(76176999)(8936002)(93886004)(50986999)(86362001)(101416001)(7696004)(3280700002)(3660700001)(74316002)(224313004)(102836003)(6116002)(25786008)(105586002)(7736002)(68736007)(3900700001)(122556002)(3846002)(224303003)(106116001)(81166006)(106356001)(2950100002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0445; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2017 03:41:12.6761 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0445 Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , Alexey Melnikov , "sidr-chairs@ietf.org" , The IESG , "sidr@ietf.org" , Matthias Waehlisch Subject: Re: [sidr] =?windows-1252?q?Mirja_K=FChlewind=27s_No_Objection_on_dra?= =?windows-1252?q?ft-ietf-sidr-bgpsec-protocol-21=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 03:41:18 -0000 Hi Mirja, >thanks for the very clear clarification.=20 >Not sure if it=92s just me or if that=92s not clearly stated=20 >in the draft, but maybe it would be worth it double-checking. The draft says the following which covey it (IMO): Section 2.2, p.5 BGP update messages without the BGPsec_Path attribute MAY be sent within a session regardless of whether or not the use of BGPsec is successfully negotiated.=20 #Sriram: BGP update messages without the BGPsec_Path attribute=20 =3D=3D Traditional BGP update message with AS_PATH (I should make that substitution in the document for clarity.)=20 Top of Section 4.4: BGPsec update messages do not contain the AS_PATH attribute. However, the AS_PATH attribute can be reconstructed from the BGPsec_Path attribute. This is necessary in the case where a route advertisement is received via a BGPsec update message and then propagated to a peer via a non-BGPsec update message (e.g., because the latter peer does not support BGPsec). Section 7, p 32.=20 How will migration from BGP to BGPsec look like? What are the benefits for the first adopters? Initially small groups of contiguous ASes would be doing BGPsec. There would be possibly one or more such groups in different geographic regions of the global Internet. Only the routes originated within each group and propagated within its borders would get the benefits of cryptographic AS path protection. As BGPsec adoption grows, each group grows in size and eventually they join together to form even larger BGPsec capable groups of contiguous ASes. The benefit for early adopters starts with AS path security within the contiguous-AS regions spanned by their respective groups. Over time they would see those contiguous-AS regions grow much larger. But I'll see if Alvaro's wording can be additionally=20 folded into the document in an appropriate place. Thank you. Sriram ________________________________________ From: Mirja Kuehlewind (IETF) Sent: Tuesday, January 17, 2017 10:52 AM To: Alvaro Retana (aretana) Cc: Sriram, Kotikalapudi (Fed); draft-ietf-sidr-bgpsec-protocol@ietf.org; A= lexey Melnikov; sidr-chairs@ietf.org; The IESG; sidr@ietf.org; Matthias Wae= hlisch Subject: Re: Mirja K=FChlewind's No Objection on draft-ietf-sidr-bgpsec-pro= tocol-21: (with COMMENT) Hi Alvaro, thanks for the very clear clarification. Not sure if it=92s just me or if t= hat=92s not clearly stated in the draft, but maybe it would be worth it dou= ble-checking. Mirja > Am 17.01.2017 um 16:47 schrieb Alvaro Retana (aretana) : > > Mirja: > > Hi! > > If an AS in the path doesn=92t support BGPsec, then BGP goes back to =93n= ormal=94 mode (as in before BGPsec), and the assurance that the =93update p= ropagated via the sequence of ASes listed=94 is lost. In other words, from= the origin AS to the AS before the one not supporting BGPsec, we can still= provide the assurance, but not beyond that =96 so any AS including and bey= ond the one not supporting BGPsec won=92t be able to verify anything. > > Alvaro. > > > > >> On 1/17/17, 6:05 AM, "Mirja Kuehlewind (IETF)" wro= te: >> >> Hi Sriram, >> >> thanks for your reply. That=92s all fine. I really didn=92t expect any p= rotocol changes at this late stage of the draft but wanted at least to know= if these points were previously discussed. Also happy to see that some par= ts where discussed with Ross. >> >> One final question (related to point 4): What happens if one router on t= he path does not support/understand BGPsec? Sorry, if that is a stupid ques= tion but it=92s still not fully clear to me from the draft=85 >> >> Mirja >>> =85 >>> > 4) section 8.1 says "the recipient of a valid BGPsec update message i= s assured that the update propagated via the sequence of ASes listed in the= Secure_Path portion of the BGPsec_Path attribute." >>> > Is that true? It is assured that at least these ASes have been crosse= d but there might have been others on the path that did not sign the BGPsec= _Path attribute, no? >>> >>> >>> [Sriram] Yes, it is true. Each AS in the path MUST sign to the next AS = (Target AS). Section 3.1 says: >>> >>> >>> The Secure_Path contains one Secure_Path Segment (see Figure 5) for >>> each Autonomous System in the path to the originating AS of the >>> prefix specified in the update message. >>> >>> >>> [Sriram] Also, Section 3.2 says: >>> >>> >>> A Signature_Block in Figure 6 has exactly one Signature Segment (se= e >>> Figure 7) for each Secure_Path Segment in the Secure_Path portion o= f >>> the BGPsec_Path Attribute. >>> >>> >>> >>> [Sriram] The following check listed in Section 5.2 make it clear as wel= l: >>> >>> >>> 3. Check that each Signature_Block contains one Signature segment >>> for each Secure_Path Segment in the Secure_Path portion of the >>> BGPsec_Path attribute. (Note that the entirety of each >>> Signature_Block must be checked to ensure that it is well forme= d, >>> even though the validation process may terminate before all >>> signatures are cryptographically verified.) >>> >>> >> From nobody Tue Jan 17 19:54:40 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512381294B7; Tue, 17 Jan 2017 19:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 hBLu3JxlnxmF; Tue, 17 Jan 2017 19:54:37 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0111.outbound.protection.outlook.com [23.103.200.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9333C129671; Tue, 17 Jan 2017 19:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DK1SKQPsJg+bfWPa6un3RRzEhX8JVXTGIcctznMd1E8=; b=UPkFth7+xgBBqKXcAOrCs46mpg4Hx7HeeLzitIGShc13FRH/QluGXgd8vcB23EL1bKL1rYWAf4K25zDpJG7ePaVI2qe2BS0Tj6E4wjLB1tmftBy098ynKuGlZiR0tVDaWEpJF2wKu/TUF4fg22uFAf7ZuxsOI6FZHPG6W0tJCUE= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0448.namprd09.prod.outlook.com (10.161.252.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Wed, 18 Jan 2017 03:54:36 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0845.013; Wed, 18 Jan 2017 03:54:36 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Ben Campbell Thread-Topic: Ben Campbell's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) Thread-Index: AQHSZtOj8RWDBRi0KkOPVX8e3dZBrKE4RbqMgATeHACAAIgR9w== Date: Wed, 18 Jan 2017 03:54:36 +0000 Message-ID: References: <148356622825.12945.17416255063037873581.idtracker@ietfa.amsl.com> , In-Reply-To: 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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.222.227] x-ms-office365-filtering-correlation-id: ed0e207c-7b30-4438-e60b-08d43f55b84d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0448; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0448; 7:N8hVi3mfAGfBaaGDSGNf/6hYSgIKjTZi7cdb/wWcdEARGjNFTah70aqYIBckLpQAnuTsjtTEA9dUUMW4ElHrjDXZM9rYrozBYaLntvGcrR8tcnpnO6FAg664qCGRL3m8DfTHnMjXw1ug23r8M/E49Dd3OTbOfusInUJ1FhpvZCM0sUPXmm252vFqhA3/MHZOaIHtwMzcaH3KR/iRkkfz0scXJmPVCAEJSN5evAiw0ai2T0EnxPVbQbhwQgsR99+bCN2ZBYzIMFzI2ssQKGMG7WXWaYo1gMsvr5ll9kJRXrrDjAnEbzHsn11bhcTXNYqYuaT+k9WuaiZl790kmAZXmWmJB1BlY70jHZi2EYXAo8t9wJPAYQfavknEpC+1GZ1elSo+ON9tWG1E8PnReYDuN8cLsdXN7DZfHKw/rcFowURHDyU+aCTVTx5HGV+RfurINFE1KDBkeBQcG1lBN/eDXw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:DM2PR09MB0448; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0448; x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39860400002)(39450400003)(39840400002)(199003)(189002)(8676002)(81166006)(7696004)(305945005)(6116002)(97736004)(66066001)(74316002)(110136003)(92566002)(6916009)(53936002)(2950100002)(8936002)(33656002)(189998001)(81156014)(5660300001)(122556002)(105586002)(6436002)(3280700002)(4326007)(55016002)(99286003)(6506006)(102836003)(7736002)(50986999)(54906002)(106116001)(77096006)(3846002)(86362001)(38730400001)(76176999)(230783001)(2906002)(2900100001)(9686003)(68736007)(3660700001)(54356999)(101416001)(6306002)(25786008)(106356001)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0448; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2017 03:54:36.1454 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0448 Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" , "sidr-chairs@ietf.org" , The IESG , "sidr@ietf.org" , Matthias Waehlisch Subject: Re: [sidr] Ben Campbell's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 03:54:39 -0000 Ben, Thank you. Please see my response inline below. >>> >>> - 8.4, last paragraph: The text describes a replay attack, and >>> delegates >>> the mitigation solution to. This is an >>> informational reference; it draft-ietf-sidr-bgpsec-rollover >>> seems like it should be normative. >> >> The solution for mitigation of replay attacks is out of band >> (in relation to the BGPsec protocol). >> As I see it, draft-ietf-sidr-bgpsec-rollover proposes 'a way' >> of replay attack mitigation. Techniques for key rollover / >> replay attack mitigation are expected to continue to evolve. >> There are various variants of the basic key rollover technique that >> are discussed in this informational draft: >> https://tools.ietf.org/html/draft-sriram-replay-protection-design-discus= sion-07 >> What needs to be pointed out in the BGPsec specification is that >> there are solutions available for replay attack mitigation. >> The above are the reasons why >> draft-ietf-sidr-bgpsec-rollover is included in informational >> references. > >That is a reasonable response, if you think it is realistic that people >would implement solutions other than the one in the reference. It would >help if the text were more clear that draft-ietf-sider-bgpsec rollover >is an example of a possible solutions, and other solutions are possible. > I will try to edit the text a bit to make that clear when I have the next opportunity to edit the document.=20 Sriram From nobody Tue Jan 17 22:17:19 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3086B129404; Tue, 17 Jan 2017 22:17:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148472023518.31998.4080694870556892818.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2017 22:17:15 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-publication@ietf.org, sidr@ietf.org Subject: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 06:17:15 -0000 Terry Manderson has entered the following ballot position for draft-ietf-sidr-publication-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-publication/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for finally bringing this protocol forward. I support Alissa's and Alexey's concerns. I only have one discuss for this draft. Looking at section 4, operational considerations I was expecting to see a review of any considerations as to how this protocol works, the interaction between the layers of HTTP, CMS, and XML and any implementation differences/difficulties that exist between the 2 known implementations. Instead there is a discussion on laying out the repository structure under the mandatory to implement _retrieval_ mechanism (RSYNC) and the nuances of RSYNC itself. This appears to be misplaced as the protocol (HTTP/CMS/XML) interactions here are simply about publication from a certificate authority operator to a repository operator, and in that space surely the publication protocol (this doc) is agnostic to the exact repo structure. In both a database world (not a file based one) and where multiple RPKI fetch mechanisms (rsync, http, torrent, etc ...) are used, how is the exact URI meaningful for sidr-publication? There might be a deeper problem here regarding any potential collisions and negotiation of the URI space between the certificate authority operator and the publication repository operator. (sure, in a situation where Alice does both, no problem.) So you may wish to address issues like that in the operational considerations section as opposed to dealing with RSYNC (in)efficiencies. From nobody Tue Jan 17 22:29:51 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8918F120727; Tue, 17 Jan 2017 22:29:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148472099055.32074.3466420839397217706.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2017 22:29:50 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-publication@ietf.org, sidr@ietf.org Subject: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 06:29:50 -0000 Terry Manderson has entered the following ballot position for draft-ietf-sidr-publication-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-publication/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Updating after reading sidr-oob-setup-06. I see that the publisher wins as per Section 5.2.4 My original discuss us below, so you may omit the concern about negotiating the URI. The remainder stands. Thanks T. =-=-=-=-=-=-=-=- Thanks for finally bringing this protocol forward. I support Alissa's and Alexey's concerns. I only have one discuss for this draft. Looking at section 4, operational considerations I was expecting to see a review of any considerations as to how this protocol works, the interaction between the layers of HTTP, CMS, and XML and any implementation differences/difficulties that exist between the 2 known implementations. Instead there is a discussion on laying out the repository structure under the mandatory to implement _retrieval_ mechanism (RSYNC) and the nuances of RSYNC itself. This appears to be misplaced as the protocol (HTTP/CMS/XML) interactions here are simply about publication from a certificate authority operator to a repository operator, and in that space surely the publication protocol (this doc) is agnostic to the exact repo structure. In both a database world (not a file based one) and where multiple RPKI fetch mechanisms (rsync, http, torrent, etc ...) are used, how is the exact URI meaningful for sidr-publication? There might be a deeper problem here regarding any potential collisions and negotiation of the URI space between the certificate authority operator and the publication repository operator. (sure, in a situation where Alice does both, no problem.) So you may wish to address issues like that in the operational considerations section as opposed to dealing with RSYNC (in)efficiencies. From nobody Wed Jan 18 06:16:15 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C186E1297E8; Wed, 18 Jan 2017 06:16:11 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148474897178.2001.16211850862792513000.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 06:16:11 -0800 Archived-At: Cc: draft-ietf-sidr-bgpsec-protocol@ietf.org, sidr-chairs@ietf.org, The IESG , sidr@ietf.org, m.waehlisch@fu-berlin.de, rfc-editor@rfc-editor.org Subject: [sidr] Protocol Action: 'BGPsec Protocol Specification' to Proposed Standard (draft-ietf-sidr-bgpsec-protocol-22.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 14:16:12 -0000 The IESG has approved the following document: - 'BGPsec Protocol Specification' (draft-ietf-sidr-bgpsec-protocol-22.txt) as Proposed Standard This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ Technical Summary This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems through which a BGP update message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries a digital signature produced by each autonomous system that propagates the update message. Working Group Summary This document has been discussed in the working group since 2011. The WG has been asked periodically to confirm continued interest, and has each time indicated that the work is valuable and should continue. The idr WG has also provided feedback and input. Document Quality The work mentioned here is applicable to all inter-domain BGP operators. BGPsec has been implemented in BIRD and Quagga, two popular open source BGP daemons. The BIRD community explicitly agreed to integrate this extension in the main branch. Personnel Shepherd: Matthias Waehlisch Responsible AD: Alvaro Retana RFC Editor Note This document is the base of a series being considered by the IESG; most are titled draft-ietf-sidr-bgpsec-*. This document should be published with the lowest RFC number, and be followed with consecutive RFC numbers by draft-ietf-sidr-as-migration and draft-ietf-sidr-bgpsec-ops. All other related documents don't require consecutive numbers. From nobody Wed Jan 18 10:17:06 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E3E120725; Wed, 18 Jan 2017 10:17:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148476342049.2020.11557954514441735216.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 10:17:00 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-publication@ietf.org, sidr@ietf.org Subject: [sidr] Kathleen Moriarty's No Objection on draft-ietf-sidr-publication-10: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 18:17:00 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-sidr-publication-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-publication/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing the security directorate review. As for Alissa's comment on transport, more language added to the Security Considerations section would be helpful to explain why the CMS signature is sufficient. I am assuming that the only exposure would be to public information during transport that is protected from tampering, unless I missed something in reading the draft (I don't think you are transferring private keys and didn't see that in the text). Security controls being managed according to the CA policy mentioned earlier in the document is appropriate, having run CAs before - there are strict requirements already depending on the level you plan to run the CA. From nobody Wed Jan 18 12:59:51 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4A21295AD; Wed, 18 Jan 2017 12:59:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148477318982.2006.5926498434357117741.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 12:59:49 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-publication@ietf.org, sidr@ietf.org Subject: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-publication-10: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 20:59:50 -0000 Ben Campbell has entered the following ballot position for draft-ietf-sidr-publication-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-publication/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Most of my comments have already been made by others. But with the questions about upgrade paths, I see there is in fact a "version" element defined. How is that expected to be used? I don't see a version related error code. From nobody Wed Jan 18 13:15:23 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5435A129485; Wed, 18 Jan 2017 13:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 5BiICVXdRSZl; Wed, 18 Jan 2017 13:15:21 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id DEF3E127077; Wed, 18 Jan 2017 13:15:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 428DB2CD02; Wed, 18 Jan 2017 23:15:20 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byzP2ozU3Tru; Wed, 18 Jan 2017 23:15:19 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 847932CCAF; Wed, 18 Jan 2017 23:15:19 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FFF14E0B-B954-48CD-A502-6E1E5CE81627"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <148469073332.32074.8816499370686348748.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 23:15:18 +0200 Message-Id: References: <148469073332.32074.8816499370686348748.idtracker@ietfa.amsl.com> To: Peter Yee X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: gen-art@ietf.org, sidr@ietf.org, draft-ietf-sidr-publication.all@ietf.org, ietf@ietf.org Subject: Re: [sidr] [Gen-art] Review of draft-ietf-sidr-publication-10 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 21:15:22 -0000 --Apple-Mail=_FFF14E0B-B954-48CD-A502-6E1E5CE81627 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Thanks for your (re-)review, Peter! Jari --Apple-Mail=_FFF14E0B-B954-48CD-A502-6E1E5CE81627 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYf9rmAAoJEM80gCTQU46q9DAP/iQ+2LVPmFUy4ngVX26mAXwI GkV8J+rWEPV0bqt0WgSuz2qG+rdF+tG9XaFNGpLywcZYqXZB8T2SvVAjkOpsxysk qI5mwFNZ5RQPURLf8LzxoEnvlIYvIapD3Fq+5G8k+xQLxl2kjSfRsfFX1gZHlseM CmByor55ZRbIJHJ/lcLZq0/RpD4D/UUDad96hcB0SbG1Ls37MghfXOGyC9XGINpV cJJalnRAOe2p6OTnp2122wZBNuzr8querzr3LioJ3GcQ//EP41/7xbQFAj8GCBZ5 at8TW9zKyeYw9LaJ7GBHSDJzpuDfYMh329Cj08KljfQpLN7rPaVRBH7bem8FrIaC Ewc4fX7YcVB9L80A4zbl6czd92YMPTQ6axp0KzVXGOiFiELqlfPRxADvEWBTw0HX KI65rMibFknYl2s/0yUnYEE+4sI5471WQIzkYrQdtl+lYxySidKUi2rkzd3XQ+p2 GaafsVVaPeqBJvsBRxJkEVcD537MA/yAwLU37ve3gHyU9nAFmWyGsUuiR3m171Ng gh9kZHJyeXmHm9dgSJ2sKzM0ET8rneECrQ14SclYLQrdGEnCG36TpScYkAr1ER2K dY8X1ptUA7FpF5Yp7i4Gf+1zCRcEOnl6yQ5HyLeGU/xRv96awGXiOAPBzcjvPKCr eKKKXVURMH+9PvtKYFgC =JBnu -----END PGP SIGNATURE----- --Apple-Mail=_FFF14E0B-B954-48CD-A502-6E1E5CE81627-- From nobody Wed Jan 18 15:37:20 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3907E126D74; Wed, 18 Jan 2017 15:37:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148478263922.2016.5321289551939679747.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 15:37:19 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-oob-setup@ietf.org, sidr@ietf.org Subject: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-rpki-oob-setup-06: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 23:37:19 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-sidr-rpki-oob-setup-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-oob-setup/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - abstract: would it be better to replace "agreeable secure means" here with "agreeable means that provides acceptable data integrity and authentication" ? Just a suggestion. - all examples: the xmlns attribute value gets me a 404. (I mean for "http://www.hactrn.net/uris/rpki/rpki-setup/") While that's ok since we don't want folks to de-reference that at run-time, it might be better if it returned the schema or something useful. And would https be even better there? (Not sure, been a while since I've xml'd;-) - examples would be better with Figure numbers and brief captions. - 5.2.1: Do we really want references to mathematical deities in examples? Real keys would be better, but that said, I do like the whimsical content of those I decoded;-) - As it happens I disagree with Alissa's discuss. This seems clear enough to me, same as any sneakernet protocol. From nobody Wed Jan 18 16:08:29 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBCE126D74; Wed, 18 Jan 2017 16:08:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148478450463.2001.14196919509991761982.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 16:08:24 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-publication@ietf.org, sidr@ietf.org Subject: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 00:08:24 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-sidr-publication-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-publication/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Why is sha-256 hardcoded? You could easily include a hash alg-id even as an option and in that way get algorithm agility, as called for by BCP201. (Or you could use something like ni URIs but that's a bit of a self-serving suggestion;-) Anyway, what's the plan for replacing sha-256 here? (This is a bit of a subset of Alissa's discuss with which I agree.) One possible way to handle this here is to identify sha-256 as the default hash algorithm but to re-define the ABNF for hash to allow an alg-id of some sort to be included there. Or have some generic versioning text somewhere that calls for a version bump if sha-256 is not to be used. (If the authors want to include this as a part of the discussion of Alissa's discuss, I'm fine with that and with clearing this discuss and letting the disucsion happen on that thread. But since the solutions could differ, I wanted to at least start a separate discussion on alg. agility.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - general: I think a design that uses https with mutual auth would have been better and easier. But given that this is implemented and deployed, I guess it's too late for this one. - As with the oob spec, the xmlns values get me a 404. - section 6: I don't agree that CMS signed data means that https is not needed. The latter provides confidentiality and integrity and server auth which the former does not. And even ignoring the security reasons, https is arguably much easier to deploy and requires less development. And http is vulnerable to middlebox messing (e.g. a client using http is more likely to be forced to support cleartext proxy-auth passwords). I would encourage you to encourage use of https with server auth in addition to CMS signed data payloads. From nobody Wed Jan 18 17:54:21 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9AE127A90; Wed, 18 Jan 2017 17:54:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148479085970.2001.17044016074905975890.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 17:54:19 -0800 Archived-At: Cc: morrowc@ops-netman.net, draft-ietf-sidr-adverse-actions@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org Subject: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-adverse-actions-04: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 01:54:19 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-sidr-adverse-actions-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-adverse-actions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think the secdir reviewer [1] and authors agreed on a couple of minor changes that it'd be good to make. [1] https://mailarchive.ietf.org/arch/search/?email_list=secdir&gbt=1&index=Ro20P04lGSg2-nldZmzZL1TLY94 From nobody Thu Jan 19 00:29:24 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816F7129458; Thu, 19 Jan 2017 00:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 TBBO-k247aff; Thu, 19 Jan 2017 00:29:15 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 1886312940E; Thu, 19 Jan 2017 00:29:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 20B5E2CEBB; Thu, 19 Jan 2017 10:29:14 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZ_pjY-rOnDD; Thu, 19 Jan 2017 10:29:13 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 91B602CCAF; Thu, 19 Jan 2017 10:29:13 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1B93DB5F-A295-4DDF-8E3E-CD5CF69B2F08"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: Date: Thu, 19 Jan 2017 10:29:09 +0200 Message-Id: <843D98C6-7250-4C45-9807-7F94A098B291@piuha.net> References: <148395897584.24935.4865204550913882433.idtracker@ietfa.amsl.com> To: Steve KENT X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "sidr@ietf.org" , "gen-art@ietf.org" , Dan Romascanu , "ietf@ietf.org" , "draft-ietf-sidr-adverse-actions.all@ietf.org" Subject: Re: [sidr] Review of draft-ietf-sidr-adverse-actions-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 08:29:16 -0000 --Apple-Mail=_1B93DB5F-A295-4DDF-8E3E-CD5CF69B2F08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Many thanks again for the review, Dan. Thanks for the explanation re: = the title, Steve =97 I was also wondering about it at first. I have posted a no-objection position for this document in tonight=92s = IESG telechat. Jari --Apple-Mail=_1B93DB5F-A295-4DDF-8E3E-CD5CF69B2F08 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYgHjWAAoJEM80gCTQU46q508P/1uUY/djGU2YNdTiRooyoP3v j4lvQuJ+MUOHuya1FfYM/g04n3BZCzIHRbUX/fn0z4t0p6YNUYNqR0nRUwfSaDzZ +Gf61saroPp5yI9HDpwrU5PIO08m64KmN6JSV4Bz/EUCFO3llKZJa+dt1YMjdYKS U+9/o7BQ715cKrVKIUEYjafcqMTRqQH9bS6teM9Wjs1S8WegIUTQP3kD7qxDrt+7 tAqbPQCt4wuaN/AOEVBRl1Dz3NUrfVevlBMt7af/I0AFB1G2RScuyQG5N7Gellof EjvdTl7hWmLXXRE9wmMR6tY4/uLfONk6+Ul6IkdxX5UU4RbGEhSnf4vd3B/9bDIa GLM29hw4UGj990+42Owkb/GsNGklz4MBlDJ/iRlda+LftljZuWRVCPcpm2Hol50p zlGNBIIlycQjiohLkg54MMHoJ9bMKzcg4bM8Z3mAc0A2HxXROJsx9Ob+GkM+GKBn qo1a2zcKkLI4ys8qwCGXnbNKceDZeCGHAcg4L/i0f71Eq2L6FxXthg4hXJh3AXGq ab+dww3V8mX+HAMRYnKgQi2/eeQgc7YeEwQGxxp1dLFagc7UOmNqx8EXBsh9kC0a frke5aoDTduqBqtP7lfM6mcGn3loOb01i34usb7ZebWVcYxkNMaLEmGV1gEdEr+q OgUp5SP6MS6D3quK9x/a =c0U/ -----END PGP SIGNATURE----- --Apple-Mail=_1B93DB5F-A295-4DDF-8E3E-CD5CF69B2F08-- From nobody Thu Jan 19 05:55:07 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C97B1270B4; Thu, 19 Jan 2017 05:55:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148483410630.10438.8785043345786209600.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 05:55:06 -0800 Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-oob-setup@ietf.org, sidr@ietf.org Subject: [sidr] Benoit Claise's No Objection on draft-ietf-sidr-rpki-oob-setup-06: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 13:55:06 -0000 Benoit Claise has entered the following ballot position for draft-ietf-sidr-rpki-oob-setup-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-oob-setup/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The title is misleading with "setup protocol". >From RFC 2026: 3.1 Technical Specification (TS) A Technical Specification is any description of a protocol, service, procedure, convention, or format We deal with a "format" here or maybe messages definition. Thankfully, the abstract is rather clear that is the protocol is unspecified. So it's not THAT bad. From nobody Thu Jan 19 06:34:12 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2C112952C; Thu, 19 Jan 2017 06:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 138JGlNP3kST; Thu, 19 Jan 2017 06:34:08 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C7D12941A; Thu, 19 Jan 2017 06:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10438; q=dns/txt; s=iport; t=1484836448; x=1486046048; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KbPuMYJFr37auMIoAauMgaFeswLxOO6g97KCd3kIrG8=; b=NL1/qcxFLmnIowkL1SG1sMvnjfiXW8yP3APm5CSVvbCjO/FA7OUpNR5+ 6YK74FIdxTRHHBFhbqiBpDc+RaGjmDljzamilS16CRj/TaTlBRQIWWzAG z5QwFzCG8UcTNRoonmlUWYNjjFtOyGW9VhiRFYJvX6G12N7ResUHcvSRh 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BpAQAHzYBY/4oNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9QAQEBAQEfYIEJB4NKigiiBIMcgg+CDIYiAhqBZD8YAQIBAQE?= =?us-ascii?q?BAQEBYyiEagYjTwcQAgEGAj8DAgICMBQRAgQBDQWJA5InnU6CJSuKFQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2GS4IFgmmHTy2CMQWIfow3hg8BkWSQbpJvAR84gUY?= =?us-ascii?q?VSgGEXoFIc4hXgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,254,1477958400"; d="scan'208,217";a="374491871" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jan 2017 14:34:07 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v0JEY7va028520 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Jan 2017 14:34:07 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 19 Jan 2017 08:34:06 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Thu, 19 Jan 2017 08:34:06 -0600 From: "Alvaro Retana (aretana)" To: Alissa Cooper , The IESG Thread-Topic: Alissa Cooper's Discuss on draft-ietf-sidr-rpki-oob-setup-06: (with DISCUSS and COMMENT) Thread-Index: AQHScmEWBhJhHECFykyAwB5iD2w/Tg== Date: Thu, 19 Jan 2017 14:34:06 +0000 Message-ID: <6549BAF8-95A7-42C6-A8E6-A80754DB2867@cisco.com> References: <148467602955.32082.12289843566112325669.idtracker@ietfa.amsl.com> In-Reply-To: <148467602955.32082.12289843566112325669.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_6549BAF895A742C6A8E6A80754DB2867ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Chris Morrow , "sidr-chairs@ietf.org" , "draft-ietf-sidr-rpki-oob-setup@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-rpki-oob-setup-06: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 14:34:10 -0000 --_000_6549BAF895A742C6A8E6A80754DB2867ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkhDQoNCkkgd2FzIGdvaW5nIHRvIHdhaXQgZm9yIHRoZSBhdXRob3IsIGJ1dCBoZSBoYXMgYmVl biBvdXQgc2ljayB0aGlzIHdlZWvigKYg4pi5DQoNClBpY2tpbmcgdXAgZnJvbSBCZW5vaXTigJlz IGNvbW1lbnQg4oCTIHRoZSB1c2Ugb2Yg4oCccHJvdG9jb2zigJ0gaXMgbWlzbGVhZGluZy4gIFdo YXQgaXMgZGVzY3JpYmVkIGlzIGEgcHJvY2VzcyB0aGF0IGNhbiBiZSBmb2xsb3dlZCBhbmQgdGhl IG5lY2Vzc2FyeSBpbmZvcm1hdGlvbiBleGNoYW5nZWQg4oCcdG8gc2ltcGxpZnkgY29uZmlndXJh dGlvbuKApmJ5IHNldHRpbmcgdXAgcmVsYXRpb25zaGlwcyBhbmQgZXhjaGFuZ2luZyBrZXlpbmcg bWF0ZXJpYWwgdXNlZCB0byBhdXRoZW50aWNhdGUgdGhvc2UgcmVsYXRpb25zaGlwcy7igJ0NCg0K VGhhbmtzIQ0KDQpBbHZhcm8uDQoNCk9uIDEvMTcvMTcsIDE6MDAgUE0sICJBbGlzc2EgQ29vcGVy IiA8YWxpc3NhQGNvb3BlcncuaW48bWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluPj4gd3JvdGU6DQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCkRJU0NVU1M6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCigxKSBJIGFncmVlIHdp dGggTWlyamEgdGhhdCB0aGlzIGRvY3VtZW50IHNlZW1zIHRvIGJlIG1pc3NpbmcgdGhlIGFjdHVh bA0KcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiwgdW5sZXNzIFNlY3Rpb24gNiBpcyBtZWFudCB0byBw cm92aWRlIHRoZQ0Kbm9ybWF0aXZlIHNwZWNpZmljYXRpb24gb2YgaG93IHRoZSBtZXNzYWdlcyBh cmUgdG8gYmUgZXhjaGFuZ2VkLiBJcyBpdD8NCklmIHNvLCBJIHdvdWxkIGV4cGVjdCB0aGF0IHRv IGJlIGV4cGxpY2l0IGluIHRoZSBkb2N1bWVudC4NCg0KKDIpIElmIHRoZXJlIGlzIGluIGZhY3Qg c3VwcG9zZWQgdG8gYmUgYSBwcm90b2NvbCBzcGVjaWZpZWQgaGVyZSwgSSBoYXZlDQp0aGUgc2Ft ZSBxdWVzdGlvbiBhcyBJIGhhZCBvbiBkcmFmdC1pZXRmLXNpZHItcHVibGljYXRpb24sIHdoaWNo IGlzIGhvdw0KZG8gdGhlIGVudGl0aWVzIG1pZ3JhdGUgZnJvbSBvbmUgdmVyc2lvbiB0byBhbm90 aGVyIGFuZCBkbyB2ZXJzaW9uDQpuZWdvdGlhdGlvbj8NCg0K --_000_6549BAF895A742C6A8E6A80754DB2867ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAg MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsN CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAg MCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ Y29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3Jt YWw7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0 eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0 ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkhpITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPkkgd2FzIGdvaW5nIHRvIHdhaXQgZm9yIHRoZSBhdXRob3IsIGJ1dCBoZSBoYXMgYmVlbiBv dXQgc2ljayB0aGlzIHdlZWvigKYNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpXaW5nZGluZ3MiPkw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+UGlj a2luZyB1cCBmcm9tIEJlbm9pdOKAmXMgY29tbWVudCDigJMgdGhlIHVzZSBvZiDigJxwcm90b2Nv bOKAnSBpcyBtaXNsZWFkaW5nLiZuYnNwOyBXaGF0IGlzIGRlc2NyaWJlZCBpcyBhIHByb2Nlc3Mg dGhhdCBjYW4gYmUgZm9sbG93ZWQgYW5kIHRoZSBuZWNlc3NhcnkgaW5mb3JtYXRpb24gZXhjaGFu Z2VkIOKAnHRvIHNpbXBsaWZ5IGNvbmZpZ3VyYXRpb27igKZieQ0KIHNldHRpbmcgdXAgcmVsYXRp b25zaGlwcyBhbmQgZXhjaGFuZ2luZyBrZXlpbmcgbWF0ZXJpYWwgdXNlZCB0byBhdXRoZW50aWNh dGUgdGhvc2UgcmVsYXRpb25zaGlwcy7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGFu a3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+QWx2YXJvLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxLzE3LzE3LCAxOjAw IFBNLCAmcXVvdDtBbGlzc2EgQ29vcGVyJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWxpc3Nh QGNvb3BlcncuaW4iPmFsaXNzYUBjb29wZXJ3LmluPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjpibGFjayI+RElTQ1VTUzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtp dC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+KDEpIEkgYWdyZWUgd2l0aCBNaXJqYSB0aGF0IHRoaXMgZG9jdW1lbnQg c2VlbXMgdG8gYmUgbWlzc2luZyB0aGUgYWN0dWFsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPnByb3RvY29sIHNwZWNpZmljYXRpb24sIHVubGVzcyBTZWN0aW9uIDYgaXMgbWVhbnQgdG8g cHJvdmlkZSB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFu ZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+bm9ybWF0aXZlIHNwZWNp ZmljYXRpb24gb2YgaG93IHRoZSBtZXNzYWdlcyBhcmUgdG8gYmUgZXhjaGFuZ2VkLiBJcyBpdD88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SWYgc28sIEkgd291bGQgZXhwZWN0IHRoYXQg dG8gYmUgZXhwbGljaXQgaW4gdGhlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFu ZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+KDIpIElmIHRoZXJlIGlz IGluIGZhY3Qgc3VwcG9zZWQgdG8gYmUgYSBwcm90b2NvbCBzcGVjaWZpZWQgaGVyZSwgSSBoYXZl PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPnRoZSBzYW1lIHF1ZXN0aW9uIGFzIEkgaGFk IG9uIGRyYWZ0LWlldGYtc2lkci1wdWJsaWNhdGlvbiwgd2hpY2ggaXMgaG93PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPmRvIHRoZSBlbnRpdGllcyBtaWdyYXRlIGZyb20gb25lIHZlcnNp b24gdG8gYW5vdGhlciBhbmQgZG8gdmVyc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5uZWdvdGlhdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_6549BAF895A742C6A8E6A80754DB2867ciscocom_-- From nobody Fri Jan 20 16:55:05 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84019129625 for ; Fri, 20 Jan 2017 16:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 GxMoBclHuo-g for ; Fri, 20 Jan 2017 16:55:02 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02EC912961F for ; Fri, 20 Jan 2017 16:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3579; q=dns/txt; s=iport; t=1484960102; x=1486169702; h=from:to:subject:date:message-id:mime-version; bh=v3wRAZbjLse5y9kGDndA0owKeFeq7CgfkIhiWorwk5I=; b=duyP/+XqLKY1M92NCzHX7gGp37VuMg6Yj5WKdse+MEhqCY11I6tLq27C /uUTWXuWoaCMTtFV3SE6WO3lCMcHoRBe0hDcxZYAM7WqQPxYLfIRwpsCh wBdjJtrqYvJjlSKj0TjqmKoXFyT7wBzS/DpDJ2B3yyGWpRrEXBf8G8Cf2 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAQCOsIJY/5xdJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9OAQEBAQEfYIEQjVSiCIUrgg0miBM/FAECAQEBAQEBAWMdC4UdXgE?= =?us-ascii?q?MdCYBBBuIfg6fEJImikkBAQEBAQUBAQEBAQEBHAWGS48dBZU3hhEBhmGKfJB3k?= =?us-ascii?q?nMBHziBRRWGb4kPAYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.33,260,1477958400"; d="scan'208,217";a="196054541" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2017 00:55:01 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v0L0t01o007939 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 21 Jan 2017 00:55:01 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 20 Jan 2017 18:55:00 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 20 Jan 2017 18:55:00 -0600 From: "Jakob Heitz (jheitz)" To: "sidr@ietf.org" Thread-Topic: EE cert to RTR Thread-Index: AdJzgKmliLrUFkOGQIazoMbEymh20Q== Date: Sat, 21 Jan 2017 00:54:59 +0000 Message-ID: <191c277b0ab244bdb6e8c6c2223e7233@XCH-ALN-014.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.35] Content-Type: multipart/alternative; boundary="_000_191c277b0ab244bdb6e8c6c2223e7233XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [sidr] EE cert to RTR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 00:55:03 -0000 --_000_191c277b0ab244bdb6e8c6c2223e7233XCHALN014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there a protocol to get the public key in an EE cert to the router? Something like https://tools.ietf.org/html/rfc6810 needed to verify BGPSEC signatures. Thanks, Jakob. --_000_191c277b0ab244bdb6e8c6c2223e7233XCHALN014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is there a protocol to get the public key in= an EE cert to the router?

Something like https://tools.ietf.org/html= /rfc6810

needed to verify BGPSEC signatures.

 

Thanks,

Jakob.

 

--_000_191c277b0ab244bdb6e8c6c2223e7233XCHALN014ciscocom_-- From nobody Fri Jan 20 16:59:20 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB23129625 for ; Fri, 20 Jan 2017 16:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 rKi3AuxsE1Vk for ; Fri, 20 Jan 2017 16:59:17 -0800 (PST) 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 D916A129583 for ; Fri, 20 Jan 2017 16:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5630; q=dns/txt; s=iport; t=1484960356; x=1486169956; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=F9p7EBkqbgp1ehez6mkxGMDLTb9ysuiw4HStGVubbCk=; b=Wx7oxHW9+gREXYExV58+y4ywFLVXZncneEz9sC3oroirrEkD394vmpzb OTNuWBwo+uY3wi5QxCkuxFSgtCV9gOaxThyevnqEN48LIH48H86WMF/ip eRiEyiT76z13rD3fUPuIhnOErmmRIUrnhVPLvNg6F06f1VgEYmdnP99w9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AwAQBDsYJY/4ENJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9OAQEBAQEfYIEJB41UkgWQA4Urgg0qhXgCghU/FAECAQEBAQE?= =?us-ascii?q?BAWMdC4RpAQEBBC1cAgEIEQQBASgHMhQJCAEBBBMIiH4OsTWKSQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFhkuEcIR/hS4FiWiLT4YRAYZhinyQd5JzAR84gUUVhm9?= =?us-ascii?q?ziBwBgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,260,1477958400"; d="scan'208,217";a="375380166" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jan 2017 00:59:15 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v0L0xFZH024368 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 21 Jan 2017 00:59:15 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 20 Jan 2017 18:59:15 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 20 Jan 2017 18:59:14 -0600 From: "Jakob Heitz (jheitz)" To: "sidr@ietf.org" Thread-Topic: EE cert to RTR Thread-Index: AdJzgKmliLrUFkOGQIazoMbEymh20QAANlZg Date: Sat, 21 Jan 2017 00:59:14 +0000 Message-ID: <31d3cc54874344d38e0a085301420c19@XCH-ALN-014.cisco.com> References: <191c277b0ab244bdb6e8c6c2223e7233@XCH-ALN-014.cisco.com> In-Reply-To: <191c277b0ab244bdb6e8c6c2223e7233@XCH-ALN-014.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.35] Content-Type: multipart/alternative; boundary="_000_31d3cc54874344d38e0a085301420c19XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] EE cert to RTR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 00:59:18 -0000 --_000_31d3cc54874344d38e0a085301420c19XCHALN014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Found it. https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-08 Thanks, Jakob. From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of Jakob Heitz (jheitz) Sent: Friday, January 20, 2017 4:55 PM To: sidr@ietf.org Subject: [sidr] EE cert to RTR Is there a protocol to get the public key in an EE cert to the router? Something like https://tools.ietf.org/html/rfc6810 needed to verify BGPSEC signatures. Thanks, Jakob. --_000_31d3cc54874344d38e0a085301420c19XCHALN014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Found it.

https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-= rfc6810-bis-08

 

Thanks,

Jakob.

 

From: sidr [mailto:sidr-bounces@ietf.org] = On Behalf Of Jakob Heitz (jheitz)
Sent: Friday, January 20, 2017 4:55 PM
To: sidr@ietf.org
Subject: [sidr] EE cert to RTR

 

Is there a protocol to get the public key in= an EE cert to the router?

Something like https://tools.ietf.org/html= /rfc6810

needed to verify BGPSEC signatures.

 

Thanks,

Jakob.

 

--_000_31d3cc54874344d38e0a085301420c19XCHALN014ciscocom_-- From nobody Fri Jan 20 18:55:33 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39AB12966E for ; Fri, 20 Jan 2017 18:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 NJcE1bUmzzut for ; Fri, 20 Jan 2017 18:55:30 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 D521812966A for ; Fri, 20 Jan 2017 18:55:30 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cUlpw-0002vn-Ed; Sat, 21 Jan 2017 02:55:28 +0000 Date: Sat, 21 Jan 2017 11:55:26 +0900 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <31d3cc54874344d38e0a085301420c19@XCH-ALN-014.cisco.com> References: <191c277b0ab244bdb6e8c6c2223e7233@XCH-ALN-014.cisco.com> <31d3cc54874344d38e0a085301420c19@XCH-ALN-014.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] EE cert to RTR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 02:55:32 -0000 > https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-08 dragon research labs software supports it. drl relying party cacheware fully supports 6810-bis. and the drl CA gooey has the router cert functions you need to create the router certs. and i presume the two test bgpsec implementations have some way of generating router certs which you can then use with any relying party cacheware which supports 6810-bis. randy From nobody Mon Jan 23 08:04:29 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C1412965B; Mon, 23 Jan 2017 08:04:25 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148518746572.29490.17975566046336212833.idtracker@ietfa.amsl.com> Date: Mon, 23 Jan 2017 08:04:25 -0800 Archived-At: Cc: draft-ietf-sidr-adverse-actions@ietf.org, Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, rfc-editor@rfc-editor.org Subject: [sidr] Document Action: 'Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)' to Informational RFC (draft-ietf-sidr-adverse-actions-04.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 16:04:26 -0000 The IESG has approved the following document: - 'Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)' (draft-ietf-sidr-adverse-actions-04.txt) as Informational RFC This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-adverse-actions/ Technical Summary This document analyzes actions by or against a CA or independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. Working Group Summary There was initially rough/loud discussion on this document, at WGLC more discussion around some wording choices ensued. Finally rough consensus for the intent and wording was reached.. Document Quality This document is an outline of some of the potential pitfalls around the CAs in use in the SIDR world. The document is of fine quality at this point in time. Personnel Document Shepherd: morrowc@ops-netman.net - Chris Morrow AD: aretana@cisco.com - Alvaro Retana From nobody Wed Jan 25 10:47:12 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D4D129AD4 for ; Wed, 25 Jan 2017 10:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 HvdHm6rlMFzz for ; Wed, 25 Jan 2017 10:47:09 -0800 (PST) Received: from mail.mikesoffice.com (v6.mikesoffice.com [IPv6:2001:470:1f05:274::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9196129ADF for ; Wed, 25 Jan 2017 10:47:09 -0800 (PST) Received: from localhost (unknown [IPv6:2001:470:1f05:274:3e97:eff:feba:52f]) by mail.mikesoffice.com (Postfix) with ESMTPSA id 38CA939005A; Wed, 25 Jan 2017 10:47:09 -0800 (PST) From: Michael Baer To: Randy Bush References: <191c277b0ab244bdb6e8c6c2223e7233@XCH-ALN-014.cisco.com> <31d3cc54874344d38e0a085301420c19@XCH-ALN-014.cisco.com> X-Face: "*g#dUT3; 8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.: (Randy Bush's message of "Sat, 21 Jan 2017 11:55:26 +0900") Message-ID: <87inp3vuxe.fsf@tislabs.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: sidr wg list Subject: Re: [sidr] EE cert to RTR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 18:47:11 -0000 >>>>> On Sat, 21 Jan 2017 11:55:26 +0900, Randy Bush said: >> https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-08 RB> dragon research labs software supports it. drl relying party cacheware RB> fully supports 6810-bis. and the drl CA gooey has the router cert RB> functions you need to create the router certs. RB> and i presume the two test bgpsec implementations have some way of RB> generating router certs which you can then use with any relying party RB> cacheware which supports 6810-bis. And the presumption is correct. Both the BGPsec for Bird and the BGP-Srx implementations can generate key pairs and I believe both implementations (although I can only speak about the BGPsec on BIRD implementation authoritatively) have support for the RPKI-RTR protocol for delivering public keys to the router. -Mike -- Michael Baer baerm@tislabs.com From nobody Thu Jan 26 12:10:29 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4F51298C1 for ; Thu, 26 Jan 2017 12:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 LMchXjTTsm8E for ; Thu, 26 Jan 2017 12:10:22 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0111.outbound.protection.outlook.com [23.103.200.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DA361299A5 for ; Thu, 26 Jan 2017 12:10:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SDodU9HhbpoL+fv7Ppslp+4hFuNzRqDfj5p8GJMHWgI=; b=uYb5DNEoFx77I2/0uEaQ5M2eyNGMbQ28MuXP5mEAkuv+ZHkqA84TEau5YdRmEaqLXlReaGOADBjEP0zHBC/uEWBSS/ALM+7snK8ZAhtFNYn67DmSXamCMVgs5WG9xkTtfck92XZPqWOeFprGZ+W2D7iR0pLLA843eQquxo/4RDM= Received: from BL2PR09MB0996.namprd09.prod.outlook.com (10.167.102.15) by BL2PR09MB0995.namprd09.prod.outlook.com (10.167.102.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Thu, 26 Jan 2017 20:10:19 +0000 Received: from BL2PR09MB0996.namprd09.prod.outlook.com ([10.167.102.15]) by BL2PR09MB0996.namprd09.prod.outlook.com ([10.167.102.15]) with mapi id 15.01.0860.023; Thu, 26 Jan 2017 20:10:18 +0000 From: "Borchert, Oliver (Fed)" To: sidr list Thread-Topic: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs Thread-Index: AQHSeBA2zrHhXkAXSUqZuVZbpiHo6g== Date: Thu, 26 Jan 2017 20:10:18 +0000 Message-ID: <06FD4D79-FBDD-44E0-9CF2-4B7A039A06A9@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.140.59] x-microsoft-exchange-diagnostics: 1; BL2PR09MB0995; 7:xNXXeugx8JE9ya4SAYTWw5KoUaUm9ehrpMrH24zgCFQQyvVpAu+PkjgI5ms7z5fiSimrA9gvT1KaFh6ZUQIeq8hcLiZk7yHufs5NUN11w7Zj2hMte6cDQ+eO1xZDnmXHkNUvV3cXo7YHZw45tFodXCxa3jIaRnbIAjYGrjDyi/zV4g3U/raP7Q51227Su/DoJKhRKotxymTUqOZz9QaVYeiYKaeKJlc0tEU5mfFveDzFflkSa4/AsmaSVXF7VEZBs4VhDyVf7iZbAtrYqbiW5h0NMuGw6VEqVBR3nGMb/lMMJiyxsMmJKbjWkMlb9ilXdDSmZ/EdiOEumtGKBZQEZ2vWlUK0RJWFGqU6c20QhahWiZVvMzkSOkHGdOcFmGj/y/Fxz+2yLQedlCmKioxppvyyyTisojIR98UzU7zlfPYBG5TJbdORu8gX4trJRUNiVvXbsTw0/T5HJo46+Bbd3A== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39450400003)(39850400002)(39860400002)(39410400002)(30584003)(189002)(199003)(40224003)(110136003)(53936002)(450100001)(102836003)(81166006)(189998001)(7736002)(8936002)(36756003)(6916009)(8676002)(5660300001)(107886002)(81156014)(305945005)(97736004)(83506001)(82746002)(4001350100001)(122556002)(230783001)(68736007)(83716003)(575784001)(5890100001)(86362001)(50986999)(54356999)(3280700002)(101416001)(2900100001)(99936001)(66066001)(3660700001)(229853002)(38730400001)(77096006)(6506006)(2906002)(6512007)(105586002)(6436002)(106356001)(33656002)(92566002)(6486002)(99286003)(106116001)(3846002)(6116002)(25786008)(104396002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR09MB0995; H:BL2PR09MB0996.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: a9fe60ae-7a93-4e4d-939b-08d4462759c2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401073); SRVR:BL2PR09MB0995; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558021)(20161123560025)(6072148); SRVR:BL2PR09MB0995; BCL:0; PCL:0; RULEID:; SRVR:BL2PR09MB0995; x-forefront-prvs: 019919A9E4 received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_003_06FD4D79FBDD44E09CF24B7A039A06A9nistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2017 20:10:18.7493 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR09MB0995 Archived-At: Subject: Re: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 20:10:26 -0000 --_003_06FD4D79FBDD44E09CF24B7A039A06A9nistgov_ Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 SGVyZSBpcyB0aGUgdXBkYXRlZCB2ZXJzaW9uIG9mIHRoZSBleGFtcGxlcy4gSSBtYWRlIHR3byBt YWluIG1vZGlmaWNhdGlvbnMgdG8gdGhlIHByZXZpb3VzIG9uZSwNCg0KKGEpIFRoZSBDZXJ0aWZp Y2F0ZSBpcyAxOCBtb250aCAoSmFuIDEsIDIwMTcg4oCTIEp1bHkgMSwgMjAxOCkNCg0KKGIpIFRo ZSBCR1BTRUMgQXR0cmlidXRlIHR5cGUgd2hpY2ggaW4gdGhlIHJlZmVyZW5jZSBpbXBsZW1lbnRh dGlvbnMgaXMgY3VycmVudGx5IGZvciANCkludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiB0aGUgUXVh Z2dhU1J4IGFuZCBCSVJEIGJncHNlYyBpbXBsZW1lbnRhdGlvbnMgc2V0IHRvIA0KMzAgKDB4MUUp IGFuZCBuZWVkcyB0byBiZSBkZWZpbmVkIGJ5IElBTkEgKHNlZSBiZ3BzZWMgcHJvdG9jb2wgZHJh ZnQpLg0KSSBtb2RpZmllZCB0aGUgdmFsdWVzIGluIHRoZSBleGFtcGxlIHRvIOKAnCoq4oCdIGFu ZCBhZGRlZCBhbiBleGNsYWltZXIuIA0KDQpBZ2FpbiwgZm9yIGJldHRlciByZWFkaW5nIEkgYXR0 YWNoZWQgdGhlIGV4YW1wbGUgYXMgdGV4dC9wZGYgaW4gY2FzZSB0aGUgZm9ybWF0dGluZyB3aXRo aW4gdGhlIGVtYWlsIGdldHMNCk1lc3NlZCB1cC4NCg0KLS0tLWV4YW1wbGUtLS0tZXhhbXBsZS0t LS1leGFtcGxlLS0tLQ0KDQpUb3BvbG9neToNCg0KQVMoNjQ0OTYpLS0tLUFTKDY1NTM2KS0tLS1B Uyg2NTUzNykNCg0KUHJlZml4IEFubm91bmNlbWVudDogQVMoNjQ0OTYpLCAxOTIuMC4yLjAvMjQN Cg0KRm9yIHRoaXMgZXhhbXBsZSB0aGUgRUNEU0EgYWxnb3JpdGhtIHdhcyBwcm92aWRlZCB3aXRo IGEgc3RhdGljIGsgdG8gDQptYWtlIHRoZSByZXN1bHQgZGV0ZXJtaW5pc3RpYy4gDQpUaGUgayB1 c2VkIGZvciBhbGwgc2lnbmF0dXJlIG9wZXJhdGlvbnMgd2FzIHRha2VuIGZyb20gUkZDIDY5Nzks IA0KY2hhcHRlciBBLjIuNSDigJxTaWduYXR1cmVzIFdpdGggU0hBLTI1NiwgbWVzc2FnZSAnc2Ft cGxlJ+KAnS4NCg0KICBrID0gQTZFM0M1N0REMDFBQkU5MDA4NjUzODM5ODM1NURENEMzQjE3QUE4 NzMzODJCMEYyNEQ2MTI5NDkzRDhBQUQ2MA0KDQpLZXlzIG9mIEFTNjQ0OTY6DQo9PT09PT09PT09 PT09PT09DQpza2k6IEFCNEQ5MTBGNTVDQUU3MUEyMTVFRjNDQUZFM0FDQzQ1QjVFRUMxNTQNCg0K cHJpdmF0ZSBrZXk6DQogIHggPSBEOEFBNERGQkUyNDc4Rjg2RTg4QTc0NTFCRjA3NTU2NTcwOUM1 NzVBQzFDMTM2RDA4MUM1NDAyNTRDQTQ0MEI5DQoNCnB1YmxpYyBrZXk6IA0KICBVeCA9IDczOTFC QUJCOTJBMENCM0JFMTBFNTlCMTlFQkZGQjIxNEUwNEE5MUUwQ0JBMUIxMzlBN0QzOEQ5MEY3N0U1 NUENCiAgVXkgPSBBMDVCOEU2OTU2NzhFMEZBMTY5MDRCNTVEOUQ0RjVDMERGQzU4ODk1RUU1MEJD NEY3NUQyMDVBMjVCRDM2RkY1DQoNClJvdXRlciBLZXkgQ2VydGlmaWNhdGUgZXhhbXBsZSB1c2lu ZyBPcGVuU1NMIDEuMC4xZS1maXBzIDExIEZlYiAyMDEzDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ2VydGlmaWNh dGU6DQogICAgRGF0YToNCiAgICAgICAgVmVyc2lvbjogMyAoMHgyKQ0KICAgICAgICBTZXJpYWwg TnVtYmVyOiAzODY1NTYxMiAoMHgyNGRkNjdjKQ0KICAgIFNpZ25hdHVyZSBBbGdvcml0aG06IGVj ZHNhLXdpdGgtU0hBMjU2DQogICAgICAgIElzc3VlcjogQ049Uk9VVEVSLTAwMDBGQkYwDQogICAg ICAgIFZhbGlkaXR5DQogICAgICAgICAgICBOb3QgQmVmb3JlOiBKYW4gIDEgMDU6MDA6MDAgMjAx NyBHTVQNCiAgICAgICAgICAgIE5vdCBBZnRlciA6IEp1bCAgMSAwNTowMDowMCAyMDE4IEdNVA0K ICAgICAgICBTdWJqZWN0OiBDTj1ST1VURVItMDAwMEZCRjANCiAgICAgICAgU3ViamVjdCBQdWJs aWMgS2V5IEluZm86DQogICAgICAgICAgICBQdWJsaWMgS2V5IEFsZ29yaXRobTogaWQtZWNQdWJs aWNLZXkNCiAgICAgICAgICAgICAgICBQdWJsaWMtS2V5OiAoMjU2IGJpdCkNCiAgICAgICAgICAg ICAgICBwdWI6IA0KICAgICAgICAgICAgICAgICAgICAwNDo3Mzo5MTpiYTpiYjo5MjphMDpjYjoz YjplMTowZTo1OTpiMTo5ZTpiZjoNCiAgICAgICAgICAgICAgICAgICAgZmI6MjE6NGU6MDQ6YTk6 MWU6MGM6YmE6MWI6MTM6OWE6N2Q6Mzg6ZDk6MGY6DQogICAgICAgICAgICAgICAgICAgIDc3OmU1 OjVhOmEwOjViOjhlOjY5OjU2Ojc4OmUwOmZhOjE2OjkwOjRiOjU1Og0KICAgICAgICAgICAgICAg ICAgICBkOTpkNDpmNTpjMDpkZjpjNTo4ODo5NTplZTo1MDpiYzo0Zjo3NTpkMjowNToNCiAgICAg ICAgICAgICAgICAgICAgYTI6NWI6ZDM6NmY6ZjUNCiAgICAgICAgICAgICAgICBBU04xIE9JRDog cHJpbWUyNTZ2MQ0KICAgICAgICBYNTA5djMgZXh0ZW5zaW9uczoNCiAgICAgICAgICAgIFg1MDl2 MyBLZXkgVXNhZ2U6IA0KICAgICAgICAgICAgICAgIERpZ2l0YWwgU2lnbmF0dXJlDQogICAgICAg ICAgICBYNTA5djMgU3ViamVjdCBLZXkgSWRlbnRpZmllcjogDQogICAgICAgICAgICAgICAgQUI6 NEQ6OTE6MEY6NTU6Q0E6RTc6MUE6MjE6NUU6RjM6Q0E6RkU6M0E6Q0M6NDU6QjU6RUU6QzE6NTQN CiAgICAgICAgICAgIFg1MDl2MyBFeHRlbmRlZCBLZXkgVXNhZ2U6IA0KICAgICAgICAgICAgICAg IDEuMy42LjEuNS41LjcuMy4zMA0KICAgICAgICAgICAgc2JncC1hdXRvbm9tb3VzU3lzTnVtOiBj cml0aWNhbA0KICAgICAgICAgICAgICAgIEF1dG9ub21vdXMgU3lzdGVtIE51bWJlcnM6DQogICAg ICAgICAgICAgICAgICA2NDQ5Ng0KICAgICAgICAgICAgICAgIFJvdXRpbmcgRG9tYWluIElkZW50 aWZpZXJzOg0KICAgICAgICAgICAgICAgICAgaW5oZXJpdA0KDQogICAgU2lnbmF0dXJlIEFsZ29y aXRobTogZWNkc2Etd2l0aC1TSEEyNTYNCiAgICAgICAgIDMwOjQ0OjAyOjIwOjA3OmI3OmI0OjZh OjVmOmE0OmYxOmNjOjY4OjM2OjM5OjAzOmE0OjgzOg0KICAgICAgICAgZWM6N2M6ODA6MDI6ZDI6 ZjY6MDg6OWQ6NDY6YjI6ZWM6MmE6N2I6ZTY6OTI6YjM6NmY6YjE6DQogICAgICAgICAwMjoyMDow MDo5MTowNTo0YTphMTpmNTpiMDoxODo5ZDoyNzoyNDplODpiNDoyMjpmZDpkMToNCiAgICAgICAg IDFjOmYwOjNkOmIxOjM4OjI0OjVkOjY0OjI5OjM1OjI4OjhkOmVlOjBjOjM4OjI5DQotLS0tLUJF R0lOIENFUlRJRklDQVRFLS0tLS0NCk1JSUJpRENDQVMrZ0F3SUJBZ0lFQWszV2ZEQUtCZ2dxaGtq T1BRUURBakFhTVJnd0ZnWURWUVFEREE5U1QxVlUNClJWSXRNREF3TUVaQ1JqQXdIaGNOTVRjd01U QXhNRFV3TURBd1doY05NVGd3TnpBeE1EVXdNREF3V2pBYU1SZ3cNCkZnWURWUVFEREE5U1QxVlVS Vkl0TURBd01FWkNSakF3V1RBVEJnY3Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkMNCkFBUnprYnE3 a3FETE8rRU9XYkdldi9zaFRnU3BIZ3k2R3hPYWZUalpEM2ZsV3FCYmptbFdlT0Q2RnBCTFZkblUN CjljRGZ4WWlWN2xDOFQzWFNCYUpiMDIvMW8yTXdZVEFMQmdOVkhROEVCQU1DQjRBd0hRWURWUjBP QkJZRUZLdE4NCmtROVZ5dWNhSVY3enl2NDZ6RVcxN3NGVU1CTUdBMVVkSlFRTU1Bb0dDQ3NHQVFV RkJ3TWVNQjRHQ0NzR0FRVUYNCkJ3RUlBUUgvQkE4d0RhQUhNQVVDQXdENzhLRUNCUUF3Q2dZSUtv Wkl6ajBFQXdJRFJ3QXdSQUlnQjdlMGFsK2sNCjhjeG9OamtEcElQc2ZJQUMwdllJblVheTdDcDc1 cEt6YjdFQ0lBQ1JCVXFoOWJBWW5TY2s2TFFpL2RFYzhEMngNCk9DUmRaQ2sxS0kzdUREZ3ANCi0t LS0tRU5EIENFUlRJRklDQVRFLS0tLS0NCg0KDQoNCktleXMgb2YgQVMoNjU2MzYpOg0KPT09PT09 PT09PT09PT09PT09DQpza2k6IDQ3RjIzQkYxQUIyRjhBOUQyNjg2NEVCQkQ4REYyNzExQzc0NDA2 RUMNCg0KcHJpdmF0ZSBrZXk6DQogIHggPSA2Q0IyRTkzMUIxMTJGMjQ1NTRCQ0RDQUFGRDk1NTNB OTUxOUE5QUYzM0MwMjNCNjA4NDZBMjFGQzk1NTgzMTcyDQoNCnB1YmxpYyBrZXk6IA0KICBVeCA9 IDI4RkM1RkU5QUZDRjVGNENBQjNGNUY4NUNCMjEyRkMxRTlEMEUwREJFQUVFNDI1QkQyRjBEMzE3 NUFBMEU5ODkNCiAgVXkgPSBFQTlCNjAzRTM4RjM1RkIzMjlERjQ5NTY0MUYyQkEwNDBGMUMzQUM2 MTM4MzA3RjI1N0NCQTZCOEI1ODhGNDFGDQoNClJvdXRlciBLZXkgQ2VydGlmaWNhdGUgZXhhbXBs ZSB1c2luZyBPcGVuU1NMIDEuMC4xZS1maXBzIDExIEZlYiAyMDEzDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ2Vy dGlmaWNhdGU6DQogICAgRGF0YToNCiAgICAgICAgVmVyc2lvbjogMyAoMHgyKQ0KICAgICAgICBT ZXJpYWwgTnVtYmVyOiAzMTY4MTg5OTQyICgweGJjZDZiZGY2KQ0KICAgIFNpZ25hdHVyZSBBbGdv cml0aG06IGVjZHNhLXdpdGgtU0hBMjU2DQogICAgICAgIElzc3VlcjogQ049Uk9VVEVSLTAwMDBG RkZGDQogICAgICAgIFZhbGlkaXR5DQogICAgICAgICAgICBOb3QgQmVmb3JlOiBKYW4gIDEgMDU6 MDA6MDAgMjAxNyBHTVQNCiAgICAgICAgICAgIE5vdCBBZnRlciA6IEp1bCAgMSAwNTowMDowMCAy MDE4IEdNVA0KICAgICAgICBTdWJqZWN0OiBDTj1ST1VURVItMDAwMEZGRkYNCiAgICAgICAgU3Vi amVjdCBQdWJsaWMgS2V5IEluZm86DQogICAgICAgICAgICBQdWJsaWMgS2V5IEFsZ29yaXRobTog aWQtZWNQdWJsaWNLZXkNCiAgICAgICAgICAgICAgICBQdWJsaWMtS2V5OiAoMjU2IGJpdCkNCiAg ICAgICAgICAgICAgICBwdWI6IA0KICAgICAgICAgICAgICAgICAgICAwNDoyODpmYzo1ZjplOTph ZjpjZjo1Zjo0YzphYjozZjo1Zjo4NTpjYjoyMToNCiAgICAgICAgICAgICAgICAgICAgMmY6YzE6 ZTk6ZDA6ZTA6ZGI6ZWE6ZWU6NDI6NWI6ZDI6ZjA6ZDM6MTc6NWE6DQogICAgICAgICAgICAgICAg ICAgIGEwOmU5Ojg5OmVhOjliOjYwOjNlOjM4OmYzOjVmOmIzOjI5OmRmOjQ5OjU2Og0KICAgICAg ICAgICAgICAgICAgICA0MTpmMjpiYTowNDowZjoxYzozYTpjNjoxMzo4MzowNzpmMjo1NzpjYjph NjoNCiAgICAgICAgICAgICAgICAgICAgYjg6YjU6ODg6ZjQ6MWYNCiAgICAgICAgICAgICAgICBB U04xIE9JRDogcHJpbWUyNTZ2MQ0KICAgICAgICBYNTA5djMgZXh0ZW5zaW9uczoNCiAgICAgICAg ICAgIFg1MDl2MyBLZXkgVXNhZ2U6IA0KICAgICAgICAgICAgICAgIERpZ2l0YWwgU2lnbmF0dXJl DQogICAgICAgICAgICBYNTA5djMgU3ViamVjdCBLZXkgSWRlbnRpZmllcjogDQogICAgICAgICAg ICAgICAgNDc6RjI6M0I6RjE6QUI6MkY6OEE6OUQ6MjY6ODY6NEU6QkI6RDg6REY6Mjc6MTE6Qzc6 NDQ6MDY6RUMNCiAgICAgICAgICAgIFg1MDl2MyBFeHRlbmRlZCBLZXkgVXNhZ2U6IA0KICAgICAg ICAgICAgICAgIDEuMy42LjEuNS41LjcuMy4zMA0KICAgICAgICAgICAgc2JncC1hdXRvbm9tb3Vz U3lzTnVtOiBjcml0aWNhbA0KICAgICAgICAgICAgICAgIEF1dG9ub21vdXMgU3lzdGVtIE51bWJl cnM6DQogICAgICAgICAgICAgICAgICA2NTUzNQ0KICAgICAgICAgICAgICAgIFJvdXRpbmcgRG9t YWluIElkZW50aWZpZXJzOg0KICAgICAgICAgICAgICAgICAgaW5oZXJpdA0KDQogICAgU2lnbmF0 dXJlIEFsZ29yaXRobTogZWNkc2Etd2l0aC1TSEEyNTYNCiAgICAgICAgIDMwOjQ1OjAyOjIxOjAw OmRmOjA0OmM1OjE3OjA0OmQwOmYyOmI5OmZhOmYzOmQ5OjZlOjNmOg0KICAgICAgICAgNmY6YTE6 NTg6ZDg6ZmU6NmM6MTg6ZTQ6Mzc6Y2E6MTk6N2M6Yzg6NzU6NDA6NTc6NmU6N2U6DQogICAgICAg ICA5ZDowMjoyMDoxMjo0NTplODphODo1ODo2YjowMDo3YjplNjphOTowZTpmMjpiNjo2Mjo1MDoN CiAgICAgICAgIDRiOjFjOjAxOjZmOjNiOjQxOjExOjY5Ojg4OjMwOjczOjlmOmQ3OjAyOjllOjY0 OjRmDQotLS0tLUJFR0lOIENFUlRJRklDQVRFLS0tLS0NCk1JSUJpakNDQVRDZ0F3SUJBZ0lGQUx6 V3ZmWXdDZ1lJS29aSXpqMEVBd0l3R2pFWU1CWUdBMVVFQXd3UFVrOVYNClZFVlNMVEF3TURCR1Jr WkdNQjRYRFRFM01ERXdNVEExTURBd01Gb1hEVEU0TURjd01UQTFNREF3TUZvd0dqRVkNCk1CWUdB MVVFQXd3UFVrOVZWRVZTTFRBd01EQkdSa1pHTUZrd0V3WUhLb1pJemowQ0FRWUlLb1pJemowREFR Y0QNClFnQUVLUHhmNmEvUFgweXJQMStGeXlFdndlblE0TnZxN2tKYjB2RFRGMXFnNllucW0yQStP UE5mc3luZlNWWkINCjhyb0VEeHc2eGhPREIvSlh5NmE0dFlqMEg2TmpNR0V3Q3dZRFZSMFBCQVFE QWdlQU1CMEdBMVVkRGdRV0JCUkgNCjhqdnhxeStLblNhR1RydlkzeWNSeDBRRzdEQVRCZ05WSFNV RUREQUtCZ2dyQmdFRkJRY0RIakFlQmdnckJnRUYNCkJRY0JDQUVCL3dRUE1BMmdCekFGQWdNQS8v K2hBZ1VBTUFvR0NDcUdTTTQ5QkFNQ0EwZ0FNRVVDSVFEZkJNVVgNCkJORHl1ZnJ6Mlc0L2I2Rlky UDVzR09RM3lobDh5SFZBVjI1K25RSWdFa1hvcUZockFIdm1xUTd5dG1KUVN4d0INCmJ6dEJFV21J TUhPZjF3S2VaRTg9DQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tDQoNCg0KDQpCR1BTZWMgVXBk YXRlIGZyb20gQVMoNjU1MzYpIHRvIEFTKDY1NTM3KToNCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NCkJpbmFyeSBGb3JtIG9mIEJHUFNlYyBVcGRhdGUgKFRDUC1E VU1QKToNCkZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGICBGRiBGRiBGRiBGRiBGRiBGRiBGRiBGRg0K MDEgMDAgMDIgMDAgMDAgMDAgRTkgNDAgIDAxIDAxIDAyIDgwIDA0IDA0IDAwIDAwDQowMCAwMCA4 MCAwRSAwRCAwMCAwMSAwMSAgMDQgQzYgMzMgNjQgNjQgMDAgMTggQzANCjAwIDAyIDkwICoqIDAw IENBIDAwIDBFICAwMSAwMCAwMCAwMSAwMCAwMCAwMSAwMA0KMDAgMDAgRkIgRjAgMDAgQkMgMDEg NDcgIEYyIDNCIEYxIEFCIDJGIDhBIDlEIDI2DQo4NiA0RSBCQiBEOCBERiAyNyAxMSBDNyAgNDQg MDYgRUMgMDAgNDYgMzAgNDQgMDINCjIwIDcyIDE0IEJDIDk2IDQ3IDE2IDBCICBCRCAzOSBGRiAy RiA4MCA1MyAzRiA1RA0KQzYgREQgRDcgMEQgREYgODYgQkIgODEgIDU2IDYxIEU4IDA1IEQ1IEQ0 IEU2IEYyDQo3QyAwMiAyMCAyRCBEQyAwMCAzQyA2NCAgQkUgN0IgMjkgQzkgRUIgREIgQzggQTQN Cjk3IEVEIDY2IDI4IDVFIEU5IDIyIDc2ICA4MyBFNiBDMSA3OCBDRSA4RCBFNiBEMw0KNTkgNUYg NDEgQUIgNEQgOTEgMEYgNTUgIENBIEU3IDFBIDIxIDVFIEYzIENBIEZFDQozQSBDQyA0NSBCNSBF RSBDMSA1NCAwMCAgNDcgMzAgNDUgMDIgMjAgNzIgMTQgQkMNCjk2IDQ3IDE2IDBCIEJEIDM5IEZG IDJGICA4MCA1MyAzRiA1RCBDNiBERCBENyAwRA0KREYgODYgQkIgODEgNTYgNjEgRTggMDUgIEQ1 IEQ0IEU2IEYyIDdDIDAyIDIxIDAwDQpDNiAxNyAxOSAzNCAwNyA0MyAwNiAzQiAgOEEgNUMgQ0Qg NTQgMTYgMzkgMEIgMzENCjIxIDFEIDNDIDUyIDQ4IDA3IDk1IDg3ICBEMCAxMyAxMyA3QiA0MSBD RCAyMyBFMg0KDQoqKiBUbyBiZSByZXBsYWNlZCB3aXRoIG9uZSBvY3RldCBoZXggdmFsdWUgc3Bl Y2lmaWVkIGJ5IElBTkEgZm9yDQogICB0aGUgQkdQU0VDX1BBVEggYXR0cmlidXRlLg0KDQoNClNp Z25hdHVyZSBGcm9tIEFTKDY0NDk2KSB0byBBUyg2NTUzNik6DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCkRpZ2VzdDogICAgMjEgMzMgRTUgQ0EgQTAgMjYgQkUgMDcg ICAzRCA5QyAxQiA0RSBGRSBCOSBCOSA3NyANCiAgICAgICAgICAgOUYgMjAgRjggRjUgREUgMjkg RkEgOTggICA0MCAwMCA5RiA2MCANClNpZ25hdHVyZTogMzAgNDUgMDIgMjAgNzIgMTQgQkMgOTYg ICA0NyAxNiAwQiBCRCAzOSBGRiAyRiA4MCANCiAgICAgICAgICAgNTMgM0YgNUQgQzYgREQgRDcg MEQgREYgICA4NiBCQiA4MSA1NiA2MSBFOCAwNSBENSANCiAgICAgICAgICAgRDQgRTYgRjIgN0Mg MDIgMjEgMDAgQzYgICAxNyAxOSAzNCAwNyA0MyAwNiAzQiA4QSANCiAgICAgICAgICAgNUMgQ0Qg NTQgMTYgMzkgMEIgMzEgMjEgICAxRCAzQyA1MiA0OCAwNyA5NSA4NyBEMCANCiAgICAgICAgICAg MTMgMTMgN0IgNDEgQ0QgMjMgRTIgDQoNClNpZ25hdHVyZSBGcm9tIEFTKDY1NTM2KSB0byBBUyg2 NTUzNyk6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRGlnZXN0OiAg ICA0NiA0QiA1NyBDRSBCMSAyRCAxOCBCMCAgIEZEIDFBIDFBIDM1IDk0IDE3IDNBIDRBIA0KICAg ICAgICAgICAwOSA4OCBFNSBGNCBFRCBFRCAyRiAzRCAgIDgzIDA4IDVBIEE4IA0KU2lnbmF0dXJl OiAzMCA0NCAwMiAyMCA3MiAxNCBCQyA5NiAgIDQ3IDE2IDBCIEJEIDM5IEZGIDJGIDgwIA0KICAg ICAgICAgICA1MyAzRiA1RCBDNiBERCBENyAwRCBERiAgIDg2IEJCIDgxIDU2IDYxIEU4IDA1IEQ1 IA0KICAgICAgICAgICBENCBFNiBGMiA3QyAwMiAyMCAyRCBEQyAgIDAwIDNDIDY0IEJFIDdCIDI5 IEM5IEVCIA0KICAgICAgICAgICBEQiBDOCBBNCA5NyBFRCA2NiAyOCA1RSAgIEU5IDIyIDc2IDgz IEU2IEMxIDc4IENFIA0KICAgICAgICAgICA4RCBFNiBEMyA1OSA1RiA0MSANCg0KDQpUaGUgaHVt YW4gcmVhZGFibGUgb3V0cHV0IGlzIHByb2R1Y2VkIHVzaW5nIGJncHNlYy1pbywgYSBiZ3BzZWMg DQp0cmFmZmljIGdlbmVyYXRvciB0aGF0IHVzZXMgYSB3aXJlc2hhcmsgbGlrZSBwcmludG91dC4N Cg0KU2VuZCBVcGRhdGUgTWVzc2FnZQ0KKy0tbWFya2VyOiBGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRg0KKy0tbGVuZ3RoOiAyNTYNCistLXR5cGU6ICAgMiAoVVBEQVRFKQ0KKy0td2l0 aGRyYXduX3JvdXRlc19sZW5ndGg6IDANCistLXRvdGFsX3BhdGhfYXR0cl9sZW5ndGg6IDIzMw0K ICAgKy0tT1JJR0lOOiBJTkNPTVBMRVRFICg0IGJ5dGVzKQ0KICAgfCAgKy0tRmxhZ3M6IDB4NDAg KFdlbGwtS25vd24sIFRyYW5zaXRpdmUsIENvbXBsZXRlKQ0KICAgfCAgKy0tVHlwZSBDb2RlOiBP UklHSU4gKDEpDQogICB8ICArLS1MZW5ndGg6IDEgYnl0ZQ0KICAgfCAgKy0tT3JpZ2luOiBJTkNP TVBMRVRFICgxKQ0KICAgKy0tTVVMVElfRVhJVF9ESVNDICg3IGJ5dGVzKQ0KICAgfCAgKy0tRmxh Z3M6IDB4ODAgKE9wdGlvbmFsLCBDb21wbGV0ZSkNCiAgIHwgICstLVR5cGUgQ29kZTogTVVMVElf RVhJVF9ESVNDICg0KQ0KICAgfCAgKy0tTGVuZ3RoOiA0IGJ5dGVzDQogICB8ICArLS1kYXRhOiAw MCAwMCAwMCAwMCANCiAgICstLU1QX1JFQUNIX05MUkkgKDE2IGJ5dGVzKQ0KICAgfCAgKy0tRmxh Z3M6IDB4ODAgKE9wdGlvbmFsLCBDb21wbGV0ZSkNCiAgIHwgICstLVR5cGUgQ29kZTogTVBfUkVB Q0hfTkxSSSAoMTQpDQogICB8ICArLS1MZW5ndGg6IDEzIGJ5dGVzDQogICB8ICArLS1kYXRhOiAw MCAwMSAwMSAwNCBDNiAzMyA2NCA2NCAgIDAwIDE4IEMwIDAwIDAyIA0KICAgKy0tQkdQU0VDIFBh dGggQXR0cmlidXRlICgyMDYgYnl0ZXMpDQogICAgICArLS1GbGFnczogMHg5MCAoT3B0aW9uYWws IENvbXBsZXRlLCBFeHRlbmRlZCBMZW5ndGgpDQogICAgICArLS1UeXBlIENvZGU6IEJHUFNFQyBQ YXRoIEF0dHJpYnV0ZSAoKiopDQogICAgICArLS1MZW5ndGg6IDIwMiBieXRlcw0KICAgICAgKy0t U2VjdXJlIFBhdGggKDE0IGJ5dGVzKQ0KICAgICAgfCAgKy0tTGVuZ3RoOiAxNCBieXRlcw0KICAg ICAgfCAgKy0tU2VjdXJlIFBhdGggU2VnbWVudDogKDYgYnl0ZXMpDQogICAgICB8ICB8ICArLS1w Q291bnQ6IDENCiAgICAgIHwgIHwgICstLUZsYWdzOiAwDQogICAgICB8ICB8ICArLS1BUyBudW1i ZXI6IDY1NTM2ICgxLjApDQogICAgICB8ICArLS1TZWN1cmUgUGF0aCBTZWdtZW50OiAoNiBieXRl cykNCiAgICAgIHwgICAgICstLXBDb3VudDogMQ0KICAgICAgfCAgICAgKy0tRmxhZ3M6IDANCiAg ICAgIHwgICAgICstLUFTIG51bWJlcjogNjQ0OTYgKDAuNjQ0OTYpDQogICAgICArLS1TaWduYXR1 cmUgQmxvY2sgKDE4OCBieXRlcykNCiAgICAgICAgICstLUxlbmd0aDogMTg4IGJ5dGVzDQogICAg ICAgICArLS1BbGdvIElEOiAxDQogICAgICAgICArLS1TaWduYXR1cmUgU2VnbWVudDogKDkyIGJ5 dGVzKQ0KICAgICAgICAgfCAgKy0tU0tJOiA0N0YyM0JGMUFCMkY4QTlEMjY4NjRFQkJEOERGMjcx MUM3NDQwNkVDDQogICAgICAgICB8ICArLS1MZW5ndGg6IDcwIGJ5dGVzDQogICAgICAgICB8ICAr LS1TaWduYXR1cmU6IDMwIDQ0IDAyIDIwIDcyIDE0IEJDIDk2ICA0NyAxNiAwQiBCRCAzOSBGRiAy RiA4MCANCiAgICAgICAgIHwgICAgICAgICAgICAgICAgNTMgM0YgNUQgQzYgREQgRDcgMEQgREYg IDg2IEJCIDgxIDU2IDYxIEU4IDA1IEQ1IA0KICAgICAgICAgfCAgICAgICAgICAgICAgICBENCBF NiBGMiA3QyAwMiAyMCAyRCBEQyAgMDAgM0MgNjQgQkUgN0IgMjkgQzkgRUIgDQogICAgICAgICB8 ICAgICAgICAgICAgICAgIERCIEM4IEE0IDk3IEVEIDY2IDI4IDVFICBFOSAyMiA3NiA4MyBFNiBD MSA3OCBDRSANCiAgICAgICAgIHwgICAgICAgICAgICAgICAgOEQgRTYgRDMgNTkgNUYgNDEgDQog ICAgICAgICArLS1TaWduYXR1cmUgU2VnbWVudDogKDkzIGJ5dGVzKQ0KICAgICAgICAgICAgKy0t U0tJOiBBQjREOTEwRjU1Q0FFNzFBMjE1RUYzQ0FGRTNBQ0M0NUI1RUVDMTU0DQogICAgICAgICAg ICArLS1MZW5ndGg6IDcxIGJ5dGVzDQogICAgICAgICAgICArLS1TaWduYXR1cmU6IDMwIDQ1IDAy IDIwIDcyIDE0IEJDIDk2ICA0NyAxNiAwQiBCRCAzOSBGRiAyRiA4MCANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgNTMgM0YgNUQgQzYgREQgRDcgMEQgREYgIDg2IEJCIDgxIDU2IDYxIEU4IDA1 IEQ1IA0KICAgICAgICAgICAgICAgICAgICAgICAgICBENCBFNiBGMiA3QyAwMiAyMSAwMCBDNiAg MTcgMTkgMzQgMDcgNDMgMDYgM0IgOEEgDQogICAgICAgICAgICAgICAgICAgICAgICAgIDVDIENE IDU0IDE2IDM5IDBCIDMxIDIxICAxRCAzQyA1MiA0OCAwNyA5NSA4NyBEMCANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgMTMgMTMgN0IgNDEgQ0QgMjMgRTIgDQoNCioqIFRvIGJlIHJlcGxhY2Vk IHdpdGggb25lIG9jdGV0IGhleCB2YWx1ZSBzcGVjaWZpZWQgYnkgSUFOQSBmb3INCiAgIHRoZSBC R1BTRUNfUEFUSCBhdHRyaWJ1dGUuDQoNCg0KLS0tLWV4YW1wbGUtLS0tZXhhbXBsZS0tLS1leGFt cGxlLS0tLQ0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCk9saXZlciBCb3JjaGVydCwgQ29tcHV0ZXIgU2NpZW50aXN0DQpO YXRpb25hbCBJbnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5DQooUGhvbmUpIDMw MS45NzUuNDg1NiAsIChGYXgpIDMwMS45NzUuNjIzOA0KDQoNCg0K --_003_06FD4D79FBDD44E09CF24B7A039A06A9nistgov_ Content-Type: application/pdf; name="draft-ietf-sidr-bgpsec-algs-examples-v2.pdf" Content-Description: draft-ietf-sidr-bgpsec-algs-examples-v2.pdf Content-Disposition: attachment; filename="draft-ietf-sidr-bgpsec-algs-examples-v2.pdf"; size=30322; creation-date="Thu, 26 Jan 2017 20:10:17 GMT"; modification-date="Thu, 26 Jan 2017 20:10:17 GMT" Content-ID: <749E3ADAC4DD1E4F9E78D504C6EF8F00@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtWNmW00YQfZ+vqLfAObjprXo7hwetCVkgwSbJAy+S3R4U vMWSWX4z+aGUZkZgBDMJQTozbsn2cd2+XXXrdv8Jv8CfYCU4zawUHEEbB0Yhk9Z5OEb4DXbwMGsF LFvg0C7p65w546TVht7gMPvwSL9jJb9YbiFd0Lc45wIWSxDi+os0Yv+w2MLDxUIA3a3h3mJ/2G/2 l+/CfVj8AcXiCtGH3/wfITRnXjiC93GgZP7intHamxf3Z3RdPSKq0aN9cf/+xX8GAnfO1dI0lPHi 4mMgPx/junkLyW63P+2WcRt3XYAzdA9AeMk4o/+HUk9Gi+CcWUQ9oqXcH6F72bQQ31bbwyY+oKcI RZbPE6g2l/tj073cwpuqhcNx/7pZxRW8obeggrarumYJr6Dbw2ScCYHMWOVGnG2rV/EK2DG2p00H q9jF47bZNS1BYDAdSYoz9FKNSFoQJa/g1NLk18RXtdlA21zuqu5EJbI/xCMxsd+1VzR1BHUH6+N+ C8/KDIy3/sGE/GhkKLgd8bN8WR2IEUgoaxD+mg/gWvitX6z5d8lMonkA29i21WWEb9qrxf7mbzbd yllkWno5QgZE3CNITKEytHnORZIWnnNnUDnlnULMc52pVNgkcVYpJ1NeSp0bIb32KndJkhs+GUrJ kSltx/z9EN+1sF9TGV5JxHRiJCUVsjFj1Xs0um4S+KKX438Rv7s1R5J29+I3WoX2VUMak+rcC14i ZklhRSIFFqXKkrJQSZZpTLEoMoHTSY40BIaPi+lwbF5XHRVU/Ej0L75u3o4aDk1oKNyL6+4C8Jay r08inZdpIbV1pTOFc4nVKNKSkyIatNxTcmKSiUwok3MnMtRcos4SrXnqJ8s+xT3zyvvR6hxO9aZX UiLkS6TsOhOIt892WiU1c+jGeg/wvKfEKi/SJE29THiWqrQQvECfCl+kZZlKoQuuEy8K+jARqVA+ sblyueeltQViMh0lyjNrzZgSgvmu1w2OqSuMR2NdwctEGM91Sprhc11ixvMyQ+c8JS7yNNOlxZwq PJGY5sqUJU4H03hGMNRo5Z7tT73sknxAFo9ds26WfWrf9FLqGM3uEp4e4m4+/xEENXURZ+vm0PY+ qIw1SC7UdBjJxRnxSe/s3c7XXtNh9J6hkuMucUbel2jv3RWghWYauR004cZxAl151VVfEuhuU0tt j/VG7zOB+mC/xmNL9iCAghf3+Fs5ocXUWjPp7Fju+6j9NY/HptrAk9O2jkeKT10XqbFew9CrlbFL AjOZ8UbPJP+k110BGQwJJIOnDBCXq7aa9W5yRgaF/MlkWaatZkJqHFXrFSf08rhtTz0f2ZNHz54+ XxTPZqSgvKR2MB0XzjOux61vAPBrtWlWTfdusraPXDFvhL5lwn3cJ/sO0kj2NQb4vtoBVQPHwDn9 9TJk4dufFmfT/7p2jMIxZ70fKuJ9Ox4YuMaTrHv1JDynzRiPG+H5N1t0d4WiUsyS2xzwnElBj2h+ qv+IS9qGfSYjptoNonbMCjPe2QyE3ECAn6+9QN9RHu/W++lECo1itLO/jYIex1nsszJtVrO4vP6I UE1Wo2gdo/332IkPfAzjdeAZRQ4kWyQSUDfdhKKFXjFtpbwlMwYYh1NN3myqXDDcMeX5bbI9BO1H roNVwYtQV6Gug5eh4mFZB1WHKAKPAX2oRfAx1OswHUCpGJnV8dHFObDhfl0HKYKOgZBWPgi6WfZg RR0EAa+CXQXlwsoHPiVA5ZiU9jaFH8D1o7UhYsCqJw7r4GIwPqAJ1oXIw5qQmuB50HVAnJBBVEx8 sg87xzXcEzMrHdYYljys1mGJwbngMURaWx7qZdDrYDGsZCC9nm6FjWPc3NoiB3D9WMmet5UKZk0w z3rE12kyHSIy7+T7HjHS5AFBMn8i4OnjPNABVLONpACvxXQseMs8v7Vv/o7cv1Zk57u46y1cO50c WyGZE97doTs30ftW8Lw/tZlQgKy0jE7ZxtuZgfNhzJvLpiMD+f486cPi//IP33btaQplbmRzdHJl YW0KZW5kb2JqCjUgMCBvYmoKMTUxMAplbmRvYmoKMiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFy ZW50IDMgMCBSIC9SZXNvdXJjZXMgNiAwIFIgL0NvbnRlbnRzIDQgMCBSIC9NZWRpYUJveCBbMCAw IDYxMiA3OTJdCj4+CmVuZG9iago2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9D b2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA4IDAgUgo+PiA+PgplbmRv YmoKOSAwIG9iago8PCAvTGVuZ3RoIDEwIDAgUiAvTiAxIC9BbHRlcm5hdGUgL0RldmljZUdyYXkg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBhVVdaBxVFD67c2cDEgcftA0ttIM/bQnp MolWE4u12026SRO362ZTmyrKdHY2O81kZpyZ3SahT6XgmxYE6augPsaCCLYqNi/2paXFkko1DwoR WowgKH1S8Dsz22R2QTLDnfnuueeee8537rmXqOtv3fPstEo054R+oZybPjl9Su26TWlSqJvw6Ebg 5UqlCcaO65j8b38e3qUUS+7sZ1vtY1v25KoZGNC6huZWA2OOKKURZWqG54dEXZcgHzwbeoxvAz85 WynngdeAldZcQHqqYDqmbxlqwdcX1JLv1iw76etW42xjy2fObrCv/OxG6w5mJ8fx74XPF0xnahJ4 H/CSoY8w7gO+27ROFGOcTnvhkXKsn842ZqdyLfnJmn90qiW/UG+MMs4SpZcW65U3gJ8AXnVOF4+3 9Ndn3XG200Mk9RhB/hTws8Ba3RzjPKnAFd8tsz7Lw6o5PAL8MvAlKxyrAMO+9EPQnGQ5sKDFep79 xFoie0Y/VgLeBnzItAu8FuyIiheW2OYg8LxjF3ktxC4um0EUL2IXP4X1ymisL6dDv8JznyaS99Ss o2PA4EQerfujLIc/cujZ0d56EXjJb5Q59j3Aa7o/UgCGzcxjVX2YeX4BeIBOpHQyyaXT+Brk0L+I NyCLmhHyyMdYDX2bCtBw0Hz0DGgVgHRaAColtEz0WCeeo1IVPZVmollBhNjK/ahvUH7Xp9SAtE7r kNaBXqNfIsk8/Upz6OchbWBspsNuHl44tAgP2BO2+aBl0xXbhSaeRzsoJsQrYlAMkSpeFYfFITEM 6ZA4GM2JvU/6zn4+2LD0LtZN+r4MDkKsZ8MzB6xwNAE8+AfrzkaaCbYu7mjs87yP3j/vv2MZtz74 s429APoxJ7/BogtrJiXmXj/3TU/CQ3VFfPXWne7r5+h4MktR3qqdWZLX5PvyCr735NWkDflneRXv vbZcPcoL/5O5zSFGO5LNQc48m1G0ccYbwCG4qUVz9rdZTLLptmK0YMlClJ2ruP/LCfPDPLexUnMu 7vC8tz9jNs33ig+LdL5Pu6yta59oP2p/aCvax0C/Sx9KX0rfSlekq9INUqVr0rL0nfS99Ln0NXpf QLosXenYSXHsG7sHfsZ71mjtMGaGsxQQ88LazApLH/F3BmOb+TOh1V4Dnbt/Yy3liLJTeUYZVnYr zykTSq9yQDmsbFcG0PqVUWUvRnZusGRjPc6AhX+SZ4umI67iPLFXdbDnw0sd76ZfXMPWhjXYST0O ntnapg6vEVe/FVVjvDtdnAY6TSFii84ich86nB8nqv7O2VyTODVSb+KUsMQu0S/GWjWYEwdQheNt 9TjIVZoZyQxncqRmejNDmf7MMcZRrNH5ktmL0SF8RxLeM8sx/5s1xGcY7x3mqAlso4dbKzTncd8R 5V1vwbdm6qE6oGkvqTlcr6Y65hjZPlW3bTUaClTfDEy/aVazxHc3zyP66/XoTk5tu2E0/GYso1Tq JtF/t4+TNAplbmRzdHJlYW0KZW5kb2JqCjEwIDAgb2JqCjExMTYKZW5kb2JqCjcgMCBvYmoKWyAv SUNDQmFzZWQgOSAwIFIgXQplbmRvYmoKMTIgMCBvYmoKPDwgL0xlbmd0aCAxMyAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBrVhbU+JIGH33V/TjTE3Z9v1WNQ/dnUSzCi4QcJya lyQERBBQQNRfvw3jrlYcnd3aBCqQ7oacnO/W37kFHXALJAGKQamx4oAJBQTlkCCFwV0FLsAcHPkV BuUKILAqw3IElVBEMhEGEDh8uQz/gykPv5X6oLwBLgtLEUIYZCXA+Ofq8MmBZAQKLiTIbsBRlmEQ lozAJ/Dq+MaRvqegtymuq3INTqtHkA6r+XoymlR3Bnw+yK5BnO3hvwB4Hw/4GA+XkEtODt7Hs4Nm nWGR0digxHBuvDWxNNgagg2PTUJ3I0lsqDXeG8aN4yaOjQ+zrGG8kkCmqfwA7zN/8cO6mg+r4Z7A /iofV4E78N+4+40tlYQMk2DBd2254w5DCgXEkIeXDN8papYShQikFIkPKFkV4+Vhvlkv5oubxWbV e1y1NzcGlHeT9aTMZ83SorCEhOnfsGL/QQMCnHV1AwKkorpbmYbZoQRiIfkH7OyMBIBgTIuGmWAS IsV/R0V3sVlP5mMQLW7yyfxVsDfOhSAhKzH2Wy4m86sq+EbDbGgMNSG/YqM3Gc/z9SYkXTsbL8Kd r4J3VuVwlR9uw8Vh78QSLpp1DI0EVAzT98igyDBmEDEEGSRNEd7MiNzwkcmZGWFTlkYoQ4Wh2iC6 G1S0YefVBEPJtXoPY1UaWRoVABIzJGYkDFJGDw0TpiAmzJLcyMJUwmhiCmrEyBS4aYxUQCHVuxXk mUG0rx7csNzk2Iy4KZDBe7BEGsJMpXb8kvAQQzNsHCMP6VeLd6sGLs0IGTrcsUPVDg4fGhHgaEO5 Icqooakqg8r9rN7FxUFjJVgLATnmuGbkw93h4uO0DXzczdIk9TaL96PNxqVWGDJKRS1ht9LUTSLv be/L2G5TZ8dpbKf0YhTZUzce315Nr8//7HQie23zVne8TcaX0SBcR1b3MjzoNxytWkDKSZ2k7iBd tyK7bcXffffabk+uynYrK7etzD60ov52N3exHxtv20+vxp5BNwsSI4zDFrAOss5MHfRFZjM3Lp8Z Td0Luy3ntm3fNEgSdiNK19zN2u7TtLiV09vo7PxLfH5RHFf3R6urbNxbnowfxfHDeT7Krr9HdDS7 uHXF9c3sojqPRLJ0Z4PhvGFzY8QwxKgesLqMRg+Xk4GceZXRbz2X/1EgcoQXpLW9zOyZG7cHJx0V O9vyjgV36ASf7KJz5y7j5HTdbppJLiAi9Y3XtKMHj5syTwfy6fGeiaf4AstV0m+51rHF/eEfnU6r ZRfH3q+ObaefuG2rajn2z3XTICWC+k3Nd9s4tZ2TI2fVNsrtScv2vd1GUp3G3nXs1o8v09PF9/Tp GsUh+qPu1m67Nh07WaF89mXaNEjFQ2tVr8WqfFi0r6fRMv1zNUqtR/eX6byfP0q/lHx5+lTI2Ifh ruvfXunCXs575VScdSZHw7hUEXloGCRGCEpVj+5z3x1+91N8mtJNFI2XzSZnjHHoGmqpeV8E4nb0 tjA02htiLDkUuL77CA3pCixGwPZ+fAqtLBU/PpumH1ojyGn9sb++OZotxJggDhmvtwqr6cQAJhNC XYKtI4myOiJCCRY7F6koCRkfe8kYErFvmAgS9AgqWc3+y7vJfb6uwLR6fGH+4N/JEx/LAZhwBIl+ u5l7AF+B8I7EmmKHMUlIIIo5H3lrk0hzTq3mWFttE0o9ClwJpJiwBCc+zCqKJWk4HIkKUOvRuNwU s0m5Z6bhbh8TzWE41WwBQH/HDVGJ50kcHt8nPGHeOho+FQ+UBbI8jnWEYhS52MYxI9xFJEFRIIVb i2KtdMPcUBz0J1YvnwHrY8AaWx2sQ2OqEsoTR4mOEqa5YDghziKGEuyp9QJTRVHwey69s8Ipx5VK wqKmsVINwx64th/ZNcXV3V688dXdTvwqdy5fPeQ3y1kFNqtdx3y+rOa93lmQWBDE1eFoslzt5Lak KgBBmDYNlDOoVL173ifj/3lqGqjQUKF6NX1F40vWaETUDI4SRNRfCmFRvs4bv5vWUNRz4k8RB4BB kJAmi7kBFPz4hB7Ij88Nk8swgyGh1dz179v3gm6Sz561rAACCxX22pqRPZqiHIpiOAoV81WdOPj/ Ki5mREMm38Y7AP9SWmlUGMWMMUg1f5Mqf7KUrlabnZLt21+75/0s7h4GqRwl4WjaVFxD+q7CM8hn k+Fk/fhiis5fphRt6gplbmRzdHJlYW0KZW5kb2JqCjEzIDAgb2JqCjE2NDEKZW5kb2JqCjExIDAg b2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAxNCAwIFIgL0NvbnRl bnRzIDEyIDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKMTQgMCBvYmoKPDwg L1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9u dCA8PCAvVFQxIDggMCBSCj4+ID4+CmVuZG9iagoxNiAwIG9iago8PCAvTGVuZ3RoIDE3IDAgUiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAG1mUtT4zoThvfzK7QcikJIsizJXTULO3ZC huOQkATIFBvbsU0YEg+5EMKvP+0cbl9mArPQZ1zgW5Enb3erX8n3pEfuiRa4U+YyTxKpDFFSU096 nMxzcklm5Lix4CRbEEYWGT7OqFFGaKnwAiNHb6f4f7jnMSqN/pJNSTDARxljnAwywvl/T+Nfl3Cp JRWOIIMpOR4MOMFHCvKVvNs61ZIEeVHNcyDfkxnBR5gLjOFOBOOatOLBwZfBLYkG2+/wRrEfinwC ZTzK3S8fM/nFMp8TZFrd7TKZLRN5ZfpigcllkjLl7YHqr9LbPFsCaXS+nZ8NB9H5EerNmrgdvHHY CJjLDfWM3hOwZw7SXaV3k4yc5hvSnhUVWA6Q6zjUY2qPGHXyvAPw78pqPlneTIFMxkd59t8tRHun jJUISUONkB9AvYEd4ccDuf4qXEXSyfL64B2LlSgph2rp7InSS3X9WqVAbIdGG6oU/0SFmoBJEAaK DNwCcg+SArKiPpYZJCk422PjQpaC4NYTyHOoa/4CUiAVr/HGDHIG4xTyBPIcpAA3hbGAAi86wDW4 iW1IxQyV3t9QJgjngfFqOC8FxcDJwUFxnVrQ1AGBXwCV9cBV1imFQyXXf6Gl5FAISBPAyLMCeAZO ApkC7oBxgOn6rqvrgCf2KR1DHeejMf2lKFIDqQsGxZPAC8t1qVyHCvezuvT7HU7O2iGQX/PJNMdB 4oFbLlOlDOVa7InaFTqAB4fkj8t8tphUswXY1sE4lHkfDE/PBHUDGS6SEnu/bQE8g5ZkXz99SYZw Uk6WyR3pT8pZslzNc8s6aC6oJ/Z105riWYiXxrrtqON8tpwUk3xuXRUtNDXyo8ZaM0kNTQFOAE0O fgCiCcYHLwShwCiQEQQBhAbCJggNnENDg8SSVxA1LEdRS0G1+qjnPusX1ak8zsdbS/KSUXadkXY1 Veaz2ubUoYpy6uKPxmOH2ZYEHbxiHzXgRVr+OkpWy2pWTavVor9ZdFZojjI0SZMsubOd4kZT9yOD X2eU/0pDEGeZTwkipfkcBx671t4wQaXzeU9Vruu4lpUwHAOOhm//vKKW4rxaLSezkoTVNJnMSPu1 2O1r4Qgq9Oc9cTK7yTE3bKuhBOXen8rldbAl76x7no0XydEaffxR/8THlmg7MbSmnO9riMRhIHHW KWovinNPNFNoYjK3Nn54gOawdjYeFEntucYeKPRfhfXk9XBy7uzp2UQVkHBwDYzRu+SgMuAGcgkO WqoEuAc6g8yAdkGy2mchos5tI+KsrF4x2MfojbcaMuCi1jM3kJgaWaW1qhrdtYLEA5Zv9VSg0BEy 64yC48LFXscq09qaMg4oqJMCulZsYQrttQHMAu2AV8AYwy7AQ5UlyMJyKnqOotrsNuGjeguiVrtD GtH5oN1sN/xBtL1quTI9l1PN5M44FbfbweS2gR/aKP11O/DLdtP/5+nyoRitG+WofVr9aD/dsgjv rVu30SgORi2fD/F83R3+9C5si6QUVWK3GC6ii/4/A38dh0Hr/OePVhzIq3AQOXEYreOBz+MQ7zWr +pqMw+z9tS20bUiDjV7u9uJdZX6Dbv5cR+vRybOiDb/3qm7o97LQNqSnqHR3S7ZX+tFp97FQyXH3 im3mXX7Y3Gyih3U+68nOw73++T1lD+Ggye9LNZrdT4V/eNbtFIvNrOhf/AjsQuJCHxonvdu3zbyK wse1erw5C4Pj71cblcjl6JadqM5t3IrWjfUovDhn3cDvhX6Z+3HA6pwch2XvMgjOT2xDCkWFt1u4 5vbh8X5zeDrrJ63B/GHkbLLzR9Zr6dAfBGXn4qQ/jMLQPw3Kch6UUTPAEJ/c+vnLuW1Iyan4bXUT PzRo+FFwvO51Y1+UwZPf9MvYPz4+vPHLoR/7VavRuG/1Y+kFftzwWenH0bDR7oVFEA+vbEO66JGd 3eoOOuFmVcyfxKU8TlVzJLruonXWczY3d2ZzcuFfCPdw1muX0c+r6r55M/dPHqb3Pb1ZTr/3+o9r 6zmpOa6V71qG9GkZRJfTdnxyVvD1af4jMt/sDtCCGZd6u5PGbSeIOuHv3cGqgxZcutSY3eEiaHX7 eUaGv8bJMifFvJoSv3/9tbbR6vqALKvXU319YHk1QXCFC+xsV5Bvf79Zzl6ucW4ndseBYDJL5hvS rOZTUhXkfxW7/jpodI/CYdz9P8iDb2KU3O3nzSb54/7nq/gewW4aCYYzYLVbPPiKCF/rMLH9jQeM RB6RDBeL8Qbughi8Krd7ffutsHr/AucO9vMKZW5kc3RyZWFtCmVuZG9iagoxNyAwIG9iagoxNzA2 CmVuZG9iagoxNSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMg MTggMCBSIC9Db250ZW50cyAxNiAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2Jq CjE4IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEg NyAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA4IDAgUgo+PiA+PgplbmRvYmoKMjAgMCBvYmoKPDwgL0xl bmd0aCAyMSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBxVhdU9tGFH3nV5zH kJbNar+XN1uS2z60k0yc6QszjDAC3IBNbNE0/75nDSZiQ5M87DQeDZZkYZ+9955zz90PeIMP8ArB CB+rYGFcgNNWKBkqbHr8iRVe1dsKiy0ktgs+LkVwQXnjeEPi6PMlv0c5HYTR7mBxg+mcj0opK8wX qKr7p/luoZSSwvAH5jd4NZ9X4NkFXkh+n0Tg3xaySef8Xx6QBrWD1nAmHfygCqjl4cH8L7Tz3Ro+ o/hvUPgGKC5bx3jwJSiFKPHyZfrherLD1RIUse0APz05xCOogxKgrBS6Cs+AkphNMdshmNYJjfHA TEHzboXJFGqGMEFsmJTSoBwLhEl+GqngYFpMp2gCmhmUT0mvCcowZQ4tQUrWFzT/8o4qDSpIUVmb gVIylXdlwBhFAiQo1u0UmDbQETPiZJgkrIaewTalQUUrpNcZKBZz06DxqcoZKQaOUSMdYB1chTZA WjQ8DFrHnBYGpWUUMaoMlGd+SGAJRVC7XOk6sQ3TFp7VFFFHtMzuFHXAxJQGpYyIVYYperQNnIMK sC3aSOmAd0DQKTJ1BU8haBGadNno0ph0FEHlimAj7AxmxzHTIFIHWDkWSRta1tcEiiLXYqbTnVlb GpSlVhufRUpPUNcwFlOLtk2RsTuhTBWfCGcfkrsnQ2lQLgrnckUYE27MtzHhkrLvyVAaFLuaDSaL 1JhwY76NCYcHMiSJLw0qRmFlTj4GoWLpRGhmzcPopJhU8qTgtkbdpHRSuShZFC9dFQZlKiOMytnH Mq6okjWsgqEmeUSLQEFv2IB1OqgL5AHRKfKxtEwZY4TWOfvYhudrnPU0J7fX3aI/x8flcIX1qsd6 MfQDrvp/8Hd3fddje9svlhdLPnL2Cb9N/pjgYr0pbBqMjULZvD8DGK56TH95/batT19P5r+iG4bN 8uxu6MUodyW8lJVGVNTEp8347fJy1Q13dHCzzfoGk7cnL5wx0Z0cYljfX1qreXlcOCC2ikLGvA0f fd+rdGi0EZJl+jQ0zfKy3w7HzFESarrK1iahnrDzsRHTerLCoSnsNSrWN4Wcriamw3uUjpYJIupc DRK0h1ekQaHTC5jRDrSpC8/o6QI/NTvrx8+dxChuJUyndVqEPIWPFXX8bENJ7oqg9v5qLPe0V6XD 5oPwLpeGfcz4vrdz4+6SrBYFdW+2xtpPr1UaYdTChbxLjxDuvd241SS0eL4RsA8URuhkEE7mWR4h fK7vJMYQ4XNdgU2hNEKlhVV5/x4hfK4JjblQQl6d1cIYlWnIIxlG8nqvp2N59eXl1bkgtMs79Q9R Vxe0UD5mkRmpK2c9M4X1yaFPqzRXcGyfSiZwxtNJOrRFpLGhR53AlC/xGEQVn2nO+xqSESEk/Z9x 0uIMQSMzS9K/GzAkZw62hTCuqBLq6istqir3yo8VdS+vaUBOyr/36/+rvHoVhNRfk4aHafmHyas3 SkSbz9X7tPI9l9f9WMt9G5ksLQfbbK4tLF7eehH8Vzr7fo5GNuTi85ibTbmlEXrFTb9sOhqFcD9U 43HgHdmMEtIaKi88WfbUns1pnK/ubroVHX533p1d09jfDbd3A5Zb3G7W53fJ9N9tl6tLnF3ebvvF 0XL9M7qHi9JNKGglnMob+bDpLi6WC1z2q37TDesN/X43EFW/JZKPy02/veo273G9fN8T9HI1cA17 53+QNl0L7A0Gp4Q1OU3f9qtzvLs974Yev/fbbXfZl86b98KQQE/z9tPR0Q2X3G+Ouav29VfhQg5R CR1yqhHPdb+6HK6Ooex4B/S7Qv+NDewovdDcc/0iBMOn2z6NFgonL969bibz9uSw8HKjUkJVOXG5 3DQIn2+6j6vTDaut357u1z/ewyiyeu1FpXPiEsGwHrrr09tuuDpN8+4jAKX15yC8+RffnCPaCmVu ZHN0cmVhbQplbmRvYmoKMjEgMCBvYmoKMTQzNgplbmRvYmoKMTkgMCBvYmoKPDwgL1R5cGUgL1Bh Z2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDIyIDAgUiAvQ29udGVudHMgMjAgMCBSIC9NZWRp YUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iagoyMiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYg L1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIK Pj4gPj4KZW5kb2JqCjI0IDAgb2JqCjw8IC9MZW5ndGggMjUgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+CnN0cmVhbQp4AcVZXVMTSRR951fcR2Wl7e7bn3mbTzclAspsuQ9WUSGMGDckSAbFqv3x e4dOQkhmVre2KakpjNbgnDl97jn3Xr7AW/gCVtLFpEHUoIwDoyyzaCzc1PAeZvAyWwgYL4DDYky3 c+aMk1YZ+gcOBw9/pf8HpUVmlNobX0Fa0a2ccwHVGIQId9OfGqTXknFtoLqCl1UlgG75CM8A4LeD g+N3w1fDowEMj7LjNyeHRVXAh2cKzr839eLD8+d71WcoqnvcD0/uBwI/AGIM81bv7QD5+x5LOR1d LgbA7xQnEO/r6fTg9Wz+bfYCqpvRbDFpJl/rF5DNr66ndVMTOqg+70VE5wRzHvvQVd+va3r4RT2A QBphFAHEf6HoR2flDXNC7p5VoOiwnl02nwZ0hO0JxT0e5EKQEvve//hmcjmZbSklOgHIpSFJu10C SKxv/jishmfFn8PqLB+eZnQA9mmUilwJpo3t42KtVNcq9fi6mcxno+m2NuPJAql8mXJ6l5Ugiw1t 7nKkYtcxciuY4qqPnZVIlzbSlmlMKpxhKHsr5GLUjMhDyKNWV+QqEVwwqcTuy7cCPTl7VyTZ72dH h++GrT+YtT7jkiCEYUL7Pj38hD6jOjsKFIxbt0vKrj63KWrlGZkcpZn3HXm35aEYDie2PgxnXvSG 3IM+KaPpUpAZQKQ2oL2gla1wkAXxSoibcSisZg47PJ7Em746OS0yOBk1nyBpmpvJ+W1Tk4glfzIV e86spnZkuzEJvclaxb7bZV9AcdfUs4v6AoLlRDc6yTXrSoGAb8N1+7jb33+k7r3/30SR9XGmXUep BVAr85VcLuUdt7gkaqa57Tuz03p8S43svYjI/56ok0SpOVOyo8iIhK0qf5oUkkYzVKqThgBgk4nT +vKqnjUDqqaHWorrwNJxGirkrgMHRgKm62x+28IQkR2XRgwmXHch05PDw1flHNlvUdDc4/2/v3hy CrPbq/P6ZgBGazRtNjP+qDYjTFpIumSc7LvL0H6JKhA982j6yAmW8VSqQK2Y0701Eh7+VKowntmu YSaUQ3j2piqUoo7hwzPeztPexFeGU8z47gqh7D2dXM5GTeuc6XQ+/quVp3Pr3jGuU6D3zHT0r8RJ oGUVIWsIkd1CCcW07K6SgCCZXs5hmLdGFffdlfRMqY657v7d24XIw0lsmLZfZml0WSilGJqOuS7g WXrG6+EAlC0lpqVIUlm6xOfSOKOKNM1dXkorRGaV4qbIYhOmPZOuY9TbBLgSjOVP0nIoq1jbznS5 KsFYkrSqoAEgB0pm+gHJ220bNSFpBlTdxCHQRMZTSHNAD2UJsgQa4WNz5jwTsrfCCO/jL42AJei8 nQTyHHILnL6XAM5AmgLlKi3vjIDCAdeQ69h4NVeMY3eCBn4f480VFAZK2mNmS5Yl4c3uZxfM2jEm LcCmtHiEzEORRscrHPO6uwPuxJtC5iBR4C0UORgDZD66ACg80CLBGnDYvlEmwNLoVUTHi8ic7Q7h Lrwub9HkCDTg6xKUuJ8CI65QtHLM+u5gJkC9LrgcmMkF47qyNsis6JhK17prIbUumKQq94KXWmdJ YUUihS5KzJKywCTLlE51UWRCq9gArWMGeys6cLZ2wbCcXUROTe2R6d6k2Dq2YIL6F5qg4Y7Rrzc6 O8/1sW58+NUmaCQydL2dwQbS8HHbBGmVw1sDB0Eh4wEpgCwoBFqeIHl4EttUDDpGa+Gf5zeDLAfq xikBKfsoBFGAFISXsjADLYGW7gTZa3AW8uihaDQyKXsbiR1+BQJdlCJkfwRckkOHbVhEHzQOmVDb jcX+PlRzOK/pF3LX09GYtkvfJrQSm89qmI+buoFP9R18HU1va1hc1+PJxwndcv4dhslRAh/nNw/e 8/YfatICXgplbmRzdHJlYW0KZW5kb2JqCjI1IDAgb2JqCjE0MTgKZW5kb2JqCjIzIDAgb2JqCjw8 IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAyNiAwIFIgL0NvbnRlbnRzIDI0 IDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKMjYgMCBvYmoKPDwgL1Byb2NT ZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAv VFQxIDggMCBSCj4+ID4+CmVuZG9iagoyOCAwIG9iago8PCAvTGVuZ3RoIDI5IDAgUiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFFjr0KwkAQhPs8xZRaeNm7XO6nNCFomeCCpegRUSFC kvP9XbCwmtmZj2VmDJjhDVy0ioxxsC7A1Cp6by2WEWe8UbarRlpBWJPgpIILxlsnAWH3P+VPFY1W VdBFmtCwoESkwQla/2jRGpWLQZGTYkLJrCHujg2A/BjRHPpT1176PR9xzXl53j55VNuCX+hYBg9f Rxop8AplbmRzdHJlYW0KZW5kb2JqCjI5IDAgb2JqCjE1MQplbmRvYmoKMjcgMCBvYmoKPDwgL1R5 cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDMwIDAgUiAvQ29udGVudHMgMjggMCBS IC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iagozMCAwIG9iago8PCAvUHJvY1NldCBb IC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEg OCAwIFIKPj4gPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9NZWRpYUJveCBbMCAw IDYxMiA3OTJdIC9Db3VudCA2IC9LaWRzIFsgMiAwIFIgMTEgMCBSIDE1IDAgUgoxOSAwIFIgMjMg MCBSIDI3IDAgUiBdID4+CmVuZG9iagozMSAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFnZXMg MyAwIFIgPj4KZW5kb2JqCjggMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBl IC9CYXNlRm9udCAvQVBIV1haK01vbmFjbyAvRm9udERlc2NyaXB0b3IKMzIgMCBSIC9FbmNvZGlu ZyAvTWFjUm9tYW5FbmNvZGluZyAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAyMTEgL1dpZHRocyBb IDYwMAowIDAgMCAwIDAgMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDAgMCA2MDAgMCAwIDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAwIDAgMCAwIDYwMCAw CjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgMCA2MDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2MDAg NjAwIF0gPj4KZW5kb2JqCjMyIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5h bWUgL0FQSFdYWitNb25hY28gL0ZsYWdzIDMyIC9Gb250QkJveCBbLTYxMCAtNDIxIDgwNCAxMjIz XQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDEwMDAgL0Rlc2NlbnQgLTI1MCAvQ2FwSGVpZ2h0IDc4 MCAvU3RlbVYgOTggL0xlYWRpbmcKODMgL1hIZWlnaHQgNTYxIC9TdGVtSCA3NiAvTWF4V2lkdGgg NjA2IC9Gb250RmlsZTIgMzMgMCBSID4+CmVuZG9iagozMyAwIG9iago8PCAvTGVuZ3RoIDM0IDAg UiAvTGVuZ3RoMSAyMzk3NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNfHd8VFXa /zm336l3WqYlmZlMCiSEBEILhGQoSSiCiCCENRJK6GioCiKCyqIRFlaKKE2lCIIaAmIoCovICuoq FlTQVRewoCjuIlIyk9/33EkQsrvv+3n/+03y3HvPPbec8vTnOXf61BmVxEzmEZ4MGDaiagzRf0Pu I0TKHTV5RFW8rJ0hhM4bNXN6MF6WVhHCXxpTNXZyvGxYSojoGTtpVuP9DoGQHsvHVY4YHa8n9dh3 GIcT8TJth33quMnT8R72s27B8wsm3TOqsd7O7ntm8oj7Gt9PPkc5ePeIyZXsakKGDMUmWHXPtOl6 kdyB9pCDVVMrG6+nqBcLCcXZW0kVMZH+RCQc0fBXQIj8Hep41LJ6jpDdBw5Lw60Fv1Kboj/urn+8 OY8dvLvO1e5aoP456R71LRRV/XpWgfsUEiNkm3DyWiA6Xbrneg2rZb9b60jbrEgop/+D/V9u/fJY IWdizorcie9NfG/FhYlSTtfcru91fb/rha5iHZ1Qm90h8Br9lV4iIRKgF+mZ2pTAgG5+Og0PvaBv K+h0UgWYB/gKIJAgtksBFwCYOGxrABz9JeJW2gZuU1wBszEvIEt5AVVpE+C5NoE6+sbuVG/gIKCO 5tTqu0Ns181MD9B9ZD7e/Rrdp1Ds9zeW99V2nh/YT/fSPWQgTu+pDbTHzXW16fOxe7W2cydU7kYF u+eV2kAPFHfSXfq1u2pTW+OiHbWp7JaaXRnzA0pkH92MoVHjXa6jmbXZ2YFuRppCRtI0PCLUuE8m YYHuDpwNhAOnO9cJNOIPfBXuE3gdV+8JFwXqwh0Cm3C8MXtbYMNA1NcGnhup756N79aH6yhOrgvj 5O7A6nBxYGH8cEG4S+Du+DWj4rvb4/f3iteXhksDPcJ1Cm7uzs7UBlqOrKNptYEW8avT4yfT2C5i DKSEewRCgCS93CUw2KN61KX3yksr5KW3yksj8tJCeWkbeWmuvDRLXpopL02WnYpd0RSLYlIMiqJI iqBwClGcdQ1fRbIYWjklje0kkA8lgn6sAUEpw1JsMcMKR/qQWmfQWVzR07OHUNqwYHHCzCJPkb3Q ll/S8z9sKvSTFT2zfv95fj+kfQfM2o/Bn0RkbM275cD3cqCPzC7oeztqluo1S1nN0u/lpfEaT1LN yr63D615Iamspi07aEgq61uz7vbgnUP30C10c3HPPfR5tisbuoffSLcUD2Tn+Y09y65fhpdtwWUk m+3YZetJgF1GAvx6dhmGWH8cSaXPs+vy2A7XeSMkVb8u1Ru54bodIwPFPXcEsME17ggZqV8z0h2/ RtGftWNgNq7JxgbXtJ1HBurXDGw7T2/WCPa6HeEwLumMDS6hx0lYvyRMj+uv4uOP0a/JiF9jebTp Gsuj/3ZN/n+85vex/69Hld13dn1g4oriynBxRbi4ElBR8/jMcZ6aeSODwR0TH2AVwRo+vWLkqHFs P6Ky5oFwZc+aieGewR1d9fuaVa9g1V3DPXeQFcWDhu5YEansWds10rU4PKJn2c7WA/qPveldj11/ V/8B/+FdA9jD+rN3tdbva/ausay6NXvXWPausexdrSOt9XcVj7+9+3/r9rTpM6ZNR+W0adMgffqT AIghB9BaKCcBQhqOA75m+1j/hq8lSJ7YIlDEZOImr4M6GMR/q8le/JWSOfhbTY4B2N9espNOoIca 6tgZoZD8mVymO3HMkZkNDaQX2YVrtoEFtyZzqZNYySEawJk1XAAyI0TmktW0N90R60mMpBMZwpkb ppBCcpQc5f+G2nLyAFlMVpC1ZDu10QgtoUvpkYZb8M79dAo9Lhxr2Ir3BEgOWvWU3pZDuOZWOgVi JIA39sETnqR1/HRhUcOohocaqhveJ07U3IrzE9ALvB1/u8iH5DPOwB3jN/DHYq/ETjfc3jCtYW4D uAf7Qx+m6+1YjndsILv1UThK/oF+rqK/8JX8NqFEGNiQ3TAWb2gANwmSbPShlAwmd5CpZAaZjfv2 klPkNLlMrtIAzaCtaQ86mM5Gbz7hAlw3rh+fwZfwtfwxISDkCJXC/dLk6FexaQ2WhhrI1zy0YBCp JPegFXPJgxhhNqJ78X6CUXHTTDxrKN1At9LvOcK5uVZcLteb689VcpO5K7yTH8QP5kcIi+TaWMvY 2tjlBrmhtOGphmd17idgpBTiJckkg7QkuaQDKcLbbtXbPpyMImPIJPR+JllAlpNV6Md+/P0Ff2/j 713yPnp1gfwT/bqCniloTbx3HdC/IXQUnUHn0Vq6j/6VHqcf09P0e3qZ68ut4rZx+7kLvMJP4qfz i/ht/DH+M/5r/F3m6zECASFDuEO8rV6MrYq9Ffu54S+YtRZo21gymTxClpGtmLG95E1yhBwnH2Ae zqENF8ivlKdWqqENHrQij7ajnfBXRPvQO2gZHUcnozVz6Hy6nK5Gm2rpMbTpF07kPFwfbhG3nHuB O8l9jTZl8EWYixK0awN/DW0pxF8R5mSy8IhQLWwUjonTxR8lTX5E/hq0cYy8Rg41EYi+30Y2yIfQ zrWYpVqM0DbyNDBgnz5jk6DZHCHn0b4AnUoTaQnXgZyiQXI356OP08O0P5fC6fNI7+MVUAj7HSN1 9F2uXFxDrnKT6a0cB/w+ziXjSQuAwRuufVu/mk+tPxV7hH+ofkB0tagA/2aRx8kX/BNCgGwnD2Hk MgmJtG2Tm9M6u1VWZssWGelpqeGUUDCQnJTo93k97gSX02G3aVaL2WQ0qIosiQLPUdKqOFxSEaxJ r6gR0sO9emWzcngEToy44URFTRCnSm6+pibI7huBqpuujODKMc2ujMSvjFy/kmrBAlKQ3SpYHA7W vNszHKyjw24biuPFPcNlwZrz+nE//VhI1wtmFEIh3BEs9ozrGayhFcHimpKZ46ohy7Nb0T0RDKMh uxXZg2EgRvbkGtJjxAPg+6QHu6K4xhfuWVzjDeMYdXxa8YjRNQNuG1rc0x8KlWW3qqE9RoVH1pBw 9xprVuPt+pNr5B41Ug88Oji+Bh0gjwd3tDpYvahOIyMrskyjw6NH3Dm0hh+BRxTX2LJq3OGeNe7Z ZzzZrero5kFDa9QedZQMgmz2Nczb4Z3XE4Ku6criRY1Xn8XVNVxayYjK6pKaSMXjmAVWrGClEYtQ op4cvJ81mnUg3pW4GEurmBCsUcPdw+OqJ1Rg5H3VNWTgrFCtzxfZA7bmKw5WDxoaDtUU+cNlI3om 7nCS6oGzdnojQe/NNdmt9njmdglh4PZkd8vuxvZdQp658f23D8fPf3CQ7T1zD3+Ffd+B18eOsqaF e6PpNcFRQTRgaBjt78Q2lZ1I9ahOGGL8yih6Ph4jUlGtdUanasQ0LRys/hX6d0X4/I83nxnReEZK 034lrJJN+XW0qaEjmo5rsrJqMjMx85ilSkwWmlaon2if3WpmjT9cpQVr/JD4ZMBQ3FXWOQeDHQqx iXu8DroOCjXzbhsaLwfJSH8tieRkldVwFazmYFONazCrmddUc/32ijBwchdTL4mrRkm//m/VEhzF 4zrX0IT/obpSr4e106pvHVEHDN1B6Z/K6qCV1pGeSXtgM/HD78quI3kM6cf3RP9RaNcKJzJDOGrf KliCcS/BaJcFq4PVvUdXB0uC44DWQpq+R0VldVkOun770PHYDhoaqomU+a8fVpaVdcZzOrDn4BZc Xl2GJ0xofAL2+qmcKC7q2Kov01QGDL1taM28nv4a6IaYVBDSQQzrQdAQ0LqOdLreUrT4gfGexjbn o82dMlHfOf4UKL3z8Iiy6mr2zNsZfh6srvZXM9KPl0EzzU9EGk/UEXYJo4U6Om8A7sUuHPKzE+FQ OIRmlfXEq7q0gm7dSNzCu2QZgAjv0v3YM1gL2Agoxbkt2J/G/g3sQ/Fz+jUrcPxnQC6AXT8GwO5Z AGD3seux1+/Zjv1MwGrA2wA8Ty/PxZ7V3Q1gzzgF6ARg59m9NY179i5Wz97F6lg7EhvL7bCfDWDX szYsBrB2TAU8BHi+8Zi9ex2Ave9dwCwAu4edHwJg97F7rgJYnysASwDsXU4Aa1cQgP5xLux3MQBi x219Ak+ARKeiHMRZhvC//zgY0gK0GAmGkAK8NUDTM8EzYoEuqBEbsRMHdDKXfkNC421u4oFO4iN+ kkiSoJsE8NwQSSFhkkrSSDp0lRbQVjJJFmkFXas19L/c6y9sg6O20JnakfbQZjpCq8wnnUkX+Ce6 QisrggToRrqTHqQnKSYl0NJ6kd7QE/virluuP+P//4N+8LywXyf8DYSG8Q96F62Gg+EEvcq14C7w t/BfCQ8JH4kl4nfSaLmDfFJxKoXKJXWLwWeYbThsqDfOMe4yXjAVmrabPjI/Yv7GMsnylnWXdqcW s7W2VdsF+0+OCY5PYQ8XOP/hmuo6lzDTLbjv9AQ9T3g+8nb31nl/9K30c/55ic7EZxIvJ/0juU9y XSAYeCmYGzwYkkKpoftCzAZYBn/WZNgaPGa/OKLKUhIVxCSeq6MbInagj0GQk3jiU0UpiaNeZS9t RSnxZPXXLhb0ixb01y6xHSkq0KIFUbZpk9uS2kJyyBbiJ0fTuZMrYwPpS5K28loiGw1K90OLtMHG 4YknYqSXOI5Q/i5OFHI+OhHNzydF59vk0jAf4rb9cTwdzH8NK4eS/bFFQi7sHhuJRDIlg2SUrJLm Mri0YmOxtYwrkwzE5lDTFM2WRuzKbPPtgtfeaY7eyH7nz+OZReepPT8fTy6nqYRr385O0lySwLmc dsEt5MZ+iD1y+jR0T9fx2Ifbt9Ps47FFTG0/+dNP9CR129c4/hV79JNPYo/+06n3gaxFe2x6e3pG WqsG1ahaVc1n8Gl9jH2sd3B3SEONQ60mRTWjPRraZUeLZhOvfdKIeJuiN7cJPkO7y8kRsX2HVHv7 dlxqxlrqonNOn449EvvhOM1+8cXYh8elyfbY97H0n36Kpce+t612/pPe98kn9L5/OTA+G7llQgup EOPzfKREo8QgC4KomE2awaZSELXVIkkt7KJoNZo4roWd541WC88Jgs1khCKpmImt0ixUqgrBeZsE fmAx1dH2r6iqrYUC5bb9bpFH4+MDWtDvIpvoiwU2jCgDzP3FgnoU3Si68xdaWmcttDxwGHuPfkCb LrSzywm7Kz+fOsSMbNpR5PP4NLeZymkOTnbFzpbTvNi75dTv2u+jobti79B2d8W+9HHL6B9ef27l qvWv0TtjG19bv2rlc6/HNqHfpZAKC2DRGkl6xGmoJHISlSoFA6k08EmqUCmZtBOssWdIkb7D/LtC trAt1D5ky7MJC2I5a2I59PgabnJ8T4/HcnQc3RLrz6fSDIxnRsRFQ2S4sbdopLco4ijLVMVrb9u3 aRrhHS46f5GhbPtCrn1Kevt2HfLaQle3ULqlV9/s8qEjuw2aXbEp1n+Oo3Ryv/EFxcP/PPfuN6oZ Vz7NZfA/cIdAB76IiSYRzicSr/DadvboM9o3JKdftE2uo33IdRqGRsbq1Yx23mg4zqvUjf56Iyap ihjVu3ivqak5DKna5Iq/t0LixvSoGNG9+4iKnIoePYcP79mjIo6/oYbjwovAF54URXwcpUkgdB4u tg95nsN7OIH3iZxXqKO37ljlyfLqDdKn2lNU0E+L2vIXiq2zHtAOt8l1h2nep6/yp3bkMLcEe0op nr0AzzZCYiRTZ2SL1+y1JLgTPKlcK7mVkktzua5yV6UnjXB95P7KIHob9wd5uDKKjuAmyHcr403j EqbSqdws+QFlGbdGWKMsM2y27Ex8I/Ej5aThY9MX9o8Tf1bOGi4qFxOzmx6dRtO4Caax5rGW/Zad tp2e/f437ZYeIABTD7vb5HTj9WaT4NO6E9HXXTLrJUfSQN4XdAx8UKWqN7DrE31Ky/udB0frd97m ZpyoiO0XKq2zLHpfPT1mRXI9idTuF5MqqFeGs83jtlJzhFrMNqOjAiLfV0E8ii9CLJwWoXaDVkEJ 8/nQLK2A/WfNn0/LSTkNEhtcK/qWh6shnMLZnAkqTaZ5be22dtwYqtKE2LnYb7HLse+pO4Pz5t0b ef4lhZsd/SGrqvj1Z6TCWI/YwtgfYz3guZ5NZ9HXrs3le5d3iy2One62ktPqa3v3hrOBfwZ4th80 Mhb83UweihQZqIHzU0gF3i/A+OZKxDvEWXQBfZI+yW2mm7lLok0C+5ckngpCD3AMWRQoLwsGcw+j yWSoow/sVNSRZranMgfW8MArRKCC17KXBik4OhML5f0uuQvO6FQH2ivCCDbiCplSnmazULl9h455 tpAr1J7rNGhd9aln99IZ9YNXCy/1uKvNlvLlVx/XcR0+JSJEgEdhsi9ye0u1ZeJWD58upkvpcrpS 4ugdGuIoC01InJA0IXlCYFJohnivdK88yz8ncU7S7OTZgVmhVZ6nEp9PPuL/XvV7lWCiXRXFFEeC JaiKfEqiz2ipo/t3JojhlDq6L2Ik1GQc6JtPfGkoh151zKfe1LLlcSo/o6PERVAX6855xs7A5kh8 1yYXSKG5vSazJ83sNkaoyWuJUEw4phoTXd6Stm9XCB8HuEO79HAK630hZjmZupySlUMxJETqB3dY NXhC8NPiZ0bnL55w79zowFlvj3qwZmrFH6ok7ty27k/uHzIpdGFe4ejJvnCHTQXZt26+a/znL065 687t92J+/wx664txSifHI9P62IYE7kiZYDsqvGs+Gv5EOGn+KPyT+SqcBkoSuIilndhZbmfpKxe7 hjknktGu+8n98gzXDG81ecT1iPdp8rS8wrWNbHRt9NYpb5I36VHXKfGU65x4Tk6WqORSkxJc3iSR ktQk1eV0m5IgUDCOu1Q1tdSOg1q3yGMXMaWarQN9M6WBIV8LYx0d/qprPvFmNA3oxTM6jbERBYnN tOfnePRRZUOaDyHBBDVwhU4p79g+Ia9tB4xcKNw+fhBOAfrkBcFiJTkZ8puEUtL/fHbL00e/iP02 dskbL/1p2abXX19H/Z9MfWphdWnstQbS5+XEw9P3LVu+d/XLE0csKN9R+uWSCXt7t5i+buTJ2Bld neWYbiqsBY0YQCVjIoEvTfQp099N3Edm+pSw3MyZzOaREJoCL3PmHgo0o4cibmISBDPhZNlqMAkc GSkarDxnteQcPlGgfVQQdRdotvwcdIgUMdnjLpBFLUt4QPsIomLqFDJ1CvSj9lQnAxtvo9wb0cnc sn00EPt6XyyP1q7hD9UXron1h49wSxQRPczzWszzrWijj1RH2uUbu7iquCq+WhZ9njRXK0+Jdoc2 0TrbOttTbV1t3axss25O2C0fcV21akar4uU0h6+OvrZLFM082Pq+nRwVHGym3GYzx/Ol7oGqL1EQ R1Iy3+r1X58oILw+VTMxRdDxzjMKwHSdtzXOULmD0bEtL0gwH0I4JaM9Y2GFwPnU0H6+Mjo4CFfY hCdil1auPDf4g7KyF+6KNcTq+Azu+51Qbb47v/Knhb3fbt3ljk13/Pkoi0eOaZQdHtgQb0b6dHF3 8HdJ7mvp7+6b3DdlNBlNZ5AZdAVZQTcrb0pvKu+bTpvsfmuWMcufFcj3D0q4MzDeOiZtgfCO8RR3 SvjCeibNSoJeh0tHSvWe4MtBLhg0uBimaqKX9T9sMDuSntPkoJwr87Ivg4Th1AjnwiUzMDw6PC+s hEs94AgRg2YOmnPNvNmbXkfdO5qkRXTmO+UeDFF5v2hcYGB0yiEfMfFM2QQHaKJ2Eo4z/bZuF/gA Z6P6MOFQcjkTaGqvj+fN+mxq7Oy3sQuxf8Efmrp2+eZl75+hk/uuGrLs0cWv7OA+nbhw5oeLvojt ga92OH2EvtF6/62xh2KnopPK9kz+0+4Pn1z1Fx1PNgKXHwCeeMimSLHCd+I7ufqqE9Q50hx5jjJH naM9Jj0lPSU/pazSjvAnpZPyOemc7JRUVbQ7NIuBWHwmh6aNtOOEQxN5ooLr74ukmYwCQYUqCkB9 zcSZfD73wAcppf8gBs3AGbzesqZBuVgOjvlNuS5DoS9EC5gUhVYIIcqYJyNz2VKwULNAf6DlIehM 9iKuQ0doZYyqJSu1cEmUFvXZ2+m5zt1z60/xn3VZkRoeN7qizeMb/k61Pif6ls3YN6fP3L+1afPE 4i27lz+OfvNkAXDnDvBBH2zPPKpEXoDhBQnXmwwjQ7KG5YyWtqa8637L/1biF+6zra6QK/QKd02y y6poUD0ZtjRfuj89I5/v6S9JLEkqSStJ75lRklWSM8g/KHFQ+qCMwVmDcyr9lYkTAhPClemVGRNb TG45Omt0zqQ2k9tOzJtumOKfkjglfUrG7BZzWs5pM6ftnLxHDNVtVlufN+8he+gebo/vM+3Ttp/m nU08m3S2zdm2l7Iu5RT6SQurkB2CD2R/rSxmM3wMJphJCy4z2W/lclOTnzPOLM0d6PC1T31OmFma OdDrbVdH/TsaBdP5mRc9cXWFHTTp33G9BRIKTBQCiGa0BjlCK2UiB/LGrYueMFMSgZu6UGIY6JYF bOM8NoO+nVL66MX90+pGt/7DwkHLxly8+OtFTlxc+si4qhkjJwmxyy/dO3n78ZZ8sbftGzNWn7r9 uYru98+6u8d9L03a8tu32xpo94lLC/ve/8deJXP6nXl7x/il1WMr3w8y+ma64RjMEaPvo5Eh6cnt 3T2SByZPIBPobDKbriFr6AvKVsc+6RX35ynnUtksXUt1iCnUbvWnpSlpxjR/B6Wdv31gjHGG74jy pvqG8U3/B9xJ9X3refVcmsPBu4g3TuwVwWcYsWuMymsNYpzmzToth7PCXcL9wuXhieH7w4+Hl4c3 htWwbPZlOMAKlshU9qbv2vO7NnM+PwcUbsuHbqiPLSPx87oto5M4BJUFGhwbZQJGyBQ78EEMpd1G Ie+vjyq/JU7j1P8t1ag59kLs8ziNx5Y10TjfaeLCGR8t+pyWxvJjz8bmxLrm7OtP50K5XVZWd/fi 3R+u1Gmci9sBwhzo2G7SIuIyVdllZg247rKqVTxv9XoaTQIo6+e1eKtvNgz4/2Qk9GhuLPCV180G zB0NCAt4NyhNJpl7CE8P1HL3yHX0ACwREf4BmYOa1UpXmQrgFGD2yyVmGEHPYyAsuHZIKLx2iHev Xh3bwFQ84EMIvOpF8CqZmGiHyCqJqCKXY1xiWGJcYlpvWG9cbzpgOGA8YDK04FsKOYZ001gylo7j xvIThEelBfIjymNqtWEFeVpcoTytPmVYadrGbeLfko7IJ8hn4llyTvyV/EavCJfFoKzwPJFUo5GI IicrJiMKBqNRlJFVIKniZiPHB3mjKKbaBQRWjIS0tFPKGRWe4yR0sibSVQ0oVPmJioIA/4cCY4kX jUIXYaJwv7BN2CdIwi9GYxfjROP9xm3GfUbJ+Mt79GcKj0mpuctK3YaaebHc0y9afr7cw7QcZjZr 7C9aztRKiFVmUy2E3czM5gcOZ0ENAqPMZ2xSLChYiO3hwws1BQXsDuusE/Q9JQ8GGPOXdAzxGfLp Q/Tv79KvP54Q/XsufXNfqwxJu3KBDl7N9VuzhvHI7RjvThhvG/GDAi9E7nlYXC6udG4UNzqPGI44 j7hOGE44T7i+NZx1nnVdU66pmlExqtzD/OvOz5J/SL6WIg5UUpIMaU6/I8XpMAjuxKRexN+LpvWy OmjAccDxpeNnh+CAS4IjijtPmhDMM6/I8CemMgWma0Z6zuFoOXMSnfn1IvQiRkhTgJ8a0/4aNWpo f7pK3ZkPK+muNCHNmp6S7lTdhbyXdxfSZC1YSMPGYCGfIDsKIZucDo/oK6QBS1IhCZlSC6nRwOws GFvYQQtv/DGza0o51K1gIxuM78J8nq6YZ1GbzvpaQ3PfTnOobc+dHSZU7nn4nrc+f/mjscNz5u9b fOCZpwbV7Mfg3f7cuIHLZnXo8+mksYfG8YOzhs8ouXvStYwnJ/R/uB/r5kzwuIhUBO/o4kjBryLQ xCRzU8kU0xTzVO8rwivKu+pP/E+q2loxnzaZrPkG3nuaEHc+p8JchUvV78iTvL6uy+LGB+PvBegL Kep3Pl+DuoyNPkBBLYFXXelCmi1NSU/gHVlwNGHjFN1ZxC5bWd8bu6/bnDC9pHBKKnN9pebFdRCJ ub/ApzoKkZeqd8f+9sIW2rau+qVn19/319lzD9+77jl7tzfo/H/9Qucd6VZXvjH2xt7XYgfXlzO6 BfUKc4BHBtj40yI5b1j/Lh6XfxZPy6ctP9tlXqCPWx63c1mK6TRx9WK4oOVJK9wuYyqwwJ2Qc/hX oLz2KxhTESZf704y71DSLZhve7pZ1bKog8fGKpuyiE103tiZpolsm8BcZlI4AxMHnxmbudW0Kvbb nIcvxDYvfPflvkM37ntS0nbEnv71u9izr217gvJnvrwwH2wHc/Q22m9D+41k9O4B5qVmTmE0vttg UFVOlFjWFpgAgeVSE/FRTlmqPqPWqAdVQZ0gFhGfWTKm8pwXlk94xxNxhhf3hPa7eKY8biXG9eS4 O5SWp0FHZnoyA8FWv5fvEF3OtY5+sG2bpK2J/rI6+jXaBCTQaVMlpZEWkpihKLJMeCGDY+O3VH5G rpEPyoI8gfMZBRUD6TXsj+NIoxu2H3t3o4Ief3HcumAvPc0Pjs7g+kV3Nr6vww14mkieifTeLexW 3lM/V38AZkqSi35up1lKYq9bfbTIR3N8NOCjPh9pQlhPUYKOrkXEv9brSU0kvmSGtEk3IS2G5Ay8 hKQoekbHWkbt+DVOt+bi1Tjuum7A3YRmuKvb0P8NdYG5tnB72M8bHzsUO74d2PtqHHtnfXM52GY1 raS5B+nDF3/H3/31sZEivchED/o/F+PN7CkjfGABgc9QDaUGkQPLV0QlVZYln5lj+Oo1dX3gxjlm /i/m7i4qyJ8Jo4j5u/PgTGQORTgWbXOPcYVHj0YPSVp0NLfmygXus2hG/H2M9wb19/WKZAgiRwxG syQLGZLIGWiGkSjSOUUFXp0j5ABIzGv6Qxy3ynV/K/yMupiIFlx3p+LF7ZkVGces7XRwbBs/PbYN 7F74bM2aaxmN/bwbPsP9eK+NlEeSf7BdteHZCtEor6gZRgPH52tIJ0g1GUsdUPRza4nDDhv2jDbz BOtco81ng8DSyVQTrJZ0MU2wyoVUMvOFRGcyuqdDt9WhUereVWia4ZS7Ty7r92Df2AYuY8o762tT Xp9WsPhbfsiaeuXyyRnxMVmLMXkHbTOQrZHQOemKxHUVuooL5YXKSmWrsEc+JXwnXFIMBln3SdXR XZESOy+BwSipdkyRlAorRVFVXoBU5jgkFspILRR4VXyYyBosugq5ShZln4lnBINYVi5koNc47GV9 QssZ4cC3eQli+QyTP0wgM/BC7uZAGkMOa2IW/H84EB9gEncKLDo22zRPpWFqW3uM63Yi+iF3fzS6 ChMuc1eigfrjvLv+e+DXKfQthL6JpPVOMBPku9ZENDAT4pMFkfEPaf+NzOMbvB7tKWqTy7gFvNOh +r3HGIO42jiPnfC8FXienXoiA0XeICbwXsEnpkEzyhQ7CZ3EWZbHLKuFP4urTGvNqy3bhE3idvM2 yz5hl7jfvN9ymH/b/LYl8RHz4xbOa6FW5M1kC3OFPwmPWiSiaca6hgsRC69ZLC3txVCBRKMZXr5d Ebu9J0IJgtkCuWr7UeQ5BY6z3IiPKKJZ4S1EWCKvlzm5ZYli/NRQNA8qUh09HDHME5YKzwg1ggBn w+GIRkq1T21FS8h68jKQW4Df8NvdpdTrmPhgXMrNjJZ7Ln4z0wvnIZSki99oM6ElMe1H15POYFai BQUF0IgwKzOzPHEtKX5AO3WKe4umQr6HbZgYRogdwzIf5jPC7lMb3qZj6Jgje0Wx1YVj/8oQRUmr 5/jYlQv8F48+Gi3jnn/00Zv5gYUsjLRcZHpSeNq0QRBWCFv5TcI2816zaGrJfEBCS7vRaBJMmEgo h5AVcyKp0CoV/YxRZiPQstSg+jTesgRY0LIUKqD1OgthHS04zGR6PxwWHNb1HuAcPCvsUGYqoKBl 6YZFeQjdoe68DMZaaIabdtq7m0srEMW9e6Pn+gqSdu23p58WVPTk8oZnWR/i9lXc9+4GRZVtMm+y veB4wf0D/UE8I58xXqVXxV/lX42/OX5zWx6xPK497nwk4QnLWm2t84mENyxva28730j4gPtc+MDy ufa584MEe0fFni/xpnyiWvNUn9eVx3s9E1fEJy1ueuomkc4bMqnbbITi4aYuSG2mgjhEHFkMEOIJ HDaaYs+iTgEbppXpG51ziDe4w9NgNmkcc5Bodm5M3P+NtLVGf/gTb7zxBCCnyevd5AVfQ/vSAfjr i9zAGvy9grGoAb3cDXoxkQQyPtJir/Fz549OnhNpCyWhF2/qZbFwUO4Ve15QOYhc5BUeeGG4rm7t IlSTS+VMNwEXaFJPEkWnIV1Lk9KsRtYH0V5IbaolizhkVyE6ovclaz74A2VSQLe1OYHpJrqJHQrT 2cfoQz+dnL4m9v3PA4fs2z3y5VhsFtchekzSJv7twRWx2OOrR+ye8Mc1bA5j/YW3dRs5lQ6JbBUI AnUefrH/4aSHQ4vDK80rPev8TyQ9EVoXfoFsNm+wbHa/4NmWvC142PI3/6GkQ6G/hT+0nNJOOT/3 f5j0Yejz8I/krOWsdtb5c8KP7h89Fy1X/ReTMkSLCUEMKWQKi3BrirzEywbFoGqCJmrInBtNR3Gj +eVkOV2uLjcsN27zbUrdqX5i+NH0o/ln21eOS+Sa7V+OpLsQMExJFKV0l5wPQh8fCRgD+cSbb4fX yKim5AVd1OVLT8wLWqnVm9aIN/EQi25M6+qfdkl3/urGjo5HPTAP6WqaOc2dzitICEA4M9WRkkV9 tsQskmzCJuhBEYFpBAec3izq17BJsgSyiMkYSsDOA14fj7c0Tg0zBtgvbgbQKWIy14W6mNEO7wjX Ph6LgTZJdbxjprvGcedK7q6ZaM/5S82ayKsfz4GRbwMiunvvjH3RiIZJ04e1Wj1g8xLnQfrEt3Qg fSfWM7ZgV+zVK+ITTXjYhJeYVxbP2AV8tMIyuBi5/4+mzYbD6mHDYdNhx8fqx4aPHWfUM4YzjrNO s2qie8yvWr6xnoMxKmIkTarZ7BbbKCav12z3aja7yWK1ptpNJkR4ibcXbyUZNg0SnbOYzVQxwYHm yhsORrR2iZkOMFOzz++lqSy+x3l9w2CMsiDNdeEH/aLcE2Ve97gABNaD22rwJzVF+VjonDnt4h47 FgULim5DugPkYDe6QPAiiMCp2rKI0WS3JcieQkS9bjDAGF0wf/510oAbCuIzI9Roe9Hhx+j6tw+O L7l/Ov3LhVjlMeofXp67/viT3LIoMhNu3zJi2O4lkWgWt2xNu0mzu05mSnyTP5zFPd6LPHyL+RbP ME+ldbZ5eqAquNC0SXkr/Vy6UbEqmpwih9P9acG+Qpk4zDzGPyb4mlYbPqVZYO271TDP4lpJyYHE oIE3JyQGAql2g8EUSDQZhATeeTrimGBPyLfx9HSETLDz+amqXiV7nQ/LeYhuePMsMPUyhsV1xH4X 40zxTJyvn0eWXQ3xldX7YLj9fswqG/2hRHcVwxtaIGsWqJK6htGkSbVLz+FS4bsLNdprcCUFeEQ+ WMxj7YXDA1f2m/DEmLGxC/+i3ObV256bv3728P4jBjbErsa+vPP50OtTi2YW37Z4cJcuz/788s+5 L3Z/tGL43PY5XXLX/LgrFmOZq/R63EMmBTtExDVqXmF2jwJa7rJLkqEz4SBivof7mWsAs/QqXeLy +rpKyuQyGt2khXI0liNMjrUWK7dtg9oCHRu2MNOxXaQqkvGV5azzEhJcfrWIWYqRclK+TTUaWprN Jp+bcqkuuO4SrgtKKNm6lNSVbUjHRiPRaU1X0gSgnqwZCqlo5+ADsIBZ8k5smvgwyJyUO/JszsZg BOSnro+2plDPezw+eNjiHnvnv7/uib9PhS4gHl3W7/YdF/nt9cbPfp0z6VPqQ7tDoFXml1LIkUjq TvlD+VuFb0EyuEw+Q8yQWiizyL0iM8/gS1JkIsliXcOwSIXMc0F4PriW0E0J8nN5pqSKMh93GWEA FRwSzghTtQu9n25D2vUPoIRfjHKW3EW+X94m75N/kGX5F0HQhFShnTAdycy7hDOCInjVRidSkw+p yYUUdyL9m/MI7iL2D3dRXJVgPiKAuyP/w6FYyruxwMf0trh3CGrE4XVr0Wek5wg72FzRhyM1C3ja m5Twt8jFSonaW3tcftSE9CSXmmgaptypihqks+bQnPcL94uST/baEpwt5ExbujPf1sFZIt+i9NZ6 20qcJa4yZZhWZhvsGi+Nk+eSB3h2wyx5mmmKdR6ZLy1Rl1iXaPNcK/kV6mb+ZellebP6sull8wFp v/yKcsD0mvkd6R35TeWw+o7pHfPH/ClEKz5WPzedNH/Ln5POKt+qV6WrpggsAKaqGu2lmmaTpQAi lXV056v2EpfLCZ8Kq2tpL7FaIfD5lnbkjCBer8jghi7NShSbU5FNqlWTeKLILm0v/ZRY6WcRl2aJ WAZYlljWW162HLC8Z1EsPreL1RLUqu8h8uFNYJPCmKlO9qAKBMaYyso0VwZgqAXQXdkP9D4zS0QE hKXFXD/CwdT4ufipxsmaOmVKHp/ncOd1dDRudWVW5t/fVTfBIjo31O11iKYZ6/YfeMslOiBU6m9d u5bfUd9y5ZP8iSsXhMR1666duZG+jWRP5OGO4sPi08bN4l+hA4vUrXbgOwgdRSTSC33VvoZxmKFH xb9yfxVPSt8ol7jLqo2jEswMKglIDJIF1Uhk3iDJcdcoagzM+hJghTGPKTwnzC1qkGF+IdEwoA5X l6jr1ZdVUfWZNTZYJsY8WCpJeWNsCLkkTEjEtwvFfnqAqNH7acVPH4wp0IKh0uv/YXhkP6BHYmPO 0pY098PYGHrse9i8WdzZ6PecO5pZf4SbyPRgisxCIjyl0++2yB0ClgUsEzYJJ+lJ+Xt6TobvlvBW 0SrN4+bxS8Ql0lJuKb9eXC9t5rZKFmj4qXaYmxQpadD1ZQR9YaVTXhJFJMeAOUIdI6ICDOsWUWkQ oXAlwrxH3XYHOVBpvI8XfTDlfB4wL58XkhQ4YcsnHnhnWIfB/JFSouMCMy3ZQXzeQ7pdmUdtHBdr exZLIoa+F8vj/sZ3j67ixtW/Hm2r9202+nY7+qaSURF3L24oN467jxPgpZbRbjicZYlDBKRmlyjE vVoRl0qwtpGTBalIge8I4srQyGb76YH4MzrSAleZGzpagKY2eqJZq/LaU+ZhoCHXbO7raAd+ZzTI /bxNOAoHQ8dtentKGyqxzoF5lwMRK0+QJGhAKhP1CvFgAEtl0i1b5ArhQaVC4Wrm/Gex3q+Fu4TJ yCwNktORO4+4zsoXZZ48Jmz1va6eDAhmlQYiyXya4krwJBsT/JhXzW4P2OFdJpon2VrsCRsNssNu SO7MG4kjwZ5id4xPCGjWGVV2avel+LOrwAi8of5z4zSqZ/bokgvSmZGn7tsoKjjPivEuKw9cD1DC 3cEUHZ83CdifniT42xCv6s8kiWJyG1jwnsxGrR8eqt6DZkXsgSDlgjS5jxDgXH0oFF+0FnOdRVjK j67+pDGXCKJudsTikJAEmeQOp/M2FgyOx4j4WYN/Hr3oy+WXX20/UQvuyzyUYB41ePvZBwYM+eDa oj/989Ih2mYHwhT1PxybeydyFb/0xS6d3bwVZg5HFjdcEP6AnEobcnFfi/R9TNzuPuE+J56Xr4hX IYt2qodVTmDjyfvTFIed8H6X0ePQiL8zj/wFFwbS6NGHyxewOQJajvUZK2f1JrduHLpGD6Ousxec h9Ze1BjHZUFGNkoJPjZKCSqGxSd42lC37MokXtHfptkoJSZRhHb9fcREzt6HJNn/fZT0eDl0HHh2 UzLSM2ABeymLpcUDlbT0jp9GL/pqxeVX203Sgnv3Vg7e+u3cAUOO8yP1AYq9xwZI6l/fMRbyUfWb 57dgdBg/2AhcK0W8zEPWRvqPNk43LvdsI5uM+zzSbqFWqdV2O3Y53+HfUU7xpxRVVGAimjwWl+lZ o9ESVmXPs4S4OnMw+6vwLJ/Pnp0jHZA4yettPeBG3GIMP+6lj8JLz7BKH51Eq5NXhDQtzcnbM4lV wQaGcSZMZEsTFjUiyXUfPWl00bPwoR0O7o5C6b6tW2LXnqB9z734lzeeHrNr5GvHus5cHyxaTdWt MTqg286yyhNTnoz9ZOvA8GEq+hsBPtiRmf1KpPsZ+ZLMVQt71bfVz5J+UsVAJBF05XQQPiHR4bTZ LcUGK0kIG2S7IRHEZLUHNJsv6M1+kBFQoLQ9ejmTiTmPTkMMGxjt4F87o3sjYRw0YYLbzzDBL3jb ELfqzSQ+MbEN8cgJTT1topekZMol08Q+QhLn6EOTHTdhArxszaiFuUC89AZaWXATrez7T4RCf7lS Sz+9iU4eavhKuAV44AKdvBq5tcQ12LXXxC9M2ihsVLaaWHDmFduxhFNGZDnQfMgJlyPBY7UETO6E UlhcnB9D5AhzRs+zruIqEzX5AtZnc6QihgrJ7W9mM2eux4rBUtkgMYbDxICOEi29SbzdhuCNkm7n rRglI4gmUU3IJEma6ADpmEA6SbKfjVoWjduuN+JIOovjgI/Yba6QruV2BJdm+WWSUPDlX5/8acmj F1f+9Zf62Ih1lbtORr1c9h+rpmzqM2Elda9/ivrWxs7EPm0x/WDFffR5/2PPbYrTyPOQK48iidNN KiNJqkY1o2YKGoOmDlqJNlh7RTmsqJJMTRYnpEtdJNkFWWhppBBY6AINJDiMDifnHODlWnu0i1o9 evwOMyVZlCdOD6ykJ8YwhohE3PZ5LDnuOq4nQcpABq6/fHn08e0P/fHPVWWP9qP7YsV85ep2X3z0 qH9HbvcVtb1W1zOHKHActkYE8iMFqwuuRNI3tzgjf5P8qyw8Jrym1rrfUT/L/ln9IfmHwA9B2M9g fa34YsVR13A1kudJ8PKJqWGsRGllTG1pLU5ngqQVED8xnGBNSQ04xlt9ud7ilnH8z7kJ/+MSM04A MEvO6wSg4z+6q/etExhi24yspJDTJajBUCCUHOIlJT1LaNmGJLlSMqnTkaG2zCSZYqs2JORMzCQt 5PRMPU9UTxPNysqcj19crGTDPdGatuojZHPhPrR1+CYyYd7oZnSSZ9OQQXM9E6tDR/if/ge6sdpa xE4fe/v9W7+dNHhVTk7KfyKj+nOxbx6IrNg+bn+H2zvk5S2sgunyu+yheiywELzGTZZHcg/LGGnJ EVD4BDcljs6S7LYYGAWZzVXGpUbO6PNy7gDNAR/1epq4Z5N4gbzUWQuSLIugk+iUkgCeZFQRheYl Wzrimm2Alw6IFRBGZuMYYZxFl+DoIzrFhD7ElSDwN4he3V3PcCyBJb7AA4FIIchEtq3eO+AfU4av DXjtewO3txn5dW+pf9Q//4kRxe3v3Rtdyi18dmz3vYuiepyCI+ug3rwJ2pCxEqYw4rCdNULTShd4 SRLTZWJQzsIp/gvyIL4TA9x3xOusPKrLhX5nomcuRq9rVvrSBt1WRiSQNmaKQ86l049ix+gF2jF6 4Y70jDvuyEi/gz+0ur5wtXihqLAQ/4UM37fHWvO79DUHSeT+iMtgoW9avxO/s/BeuEd5/1kXVWAG 1UUMRoPEhzWr/SySXX7BVw2I0RegddSxW890Tj6whw5pStT9hkU/+iGBvTHOg4Tnfwv0ZLJADxby MFYE/9kUB8ttaYrzaEypubEr29dMLH+odyydW/7H1zfdSxcOzsgYzCDW56XW3Z4+wN+1uj4zduaL CvnQ9a4BF9jqrs3AIQPZHZknS0OlmSK/QHxSfFJ6XnxeOimeEy9LyifSRwr3lkRXiU9J3CfStxJE WrW4Td6m7JNek9+G6Vwvq4pkkDmX6JSWS3BqCrIcsCtgXIgQiaftAi+oPGSxKEhYO2tQoG4a8B0K g4njVd4QoExVMBlz3vk7UjLcBTaNxYTcUIqZcz4/500Z0SBNhacGOwUeCUQcyJSpyLGaMrUpKBSi tnf3ct7L0e+49AYS/Rq6iIETo9eiW7ihUXzpBS+YBVz6O/oqkx6RENwFQCMSRyOgD/8dEcQAvRUr yb9ksSpEUzrvOBFXMhhxaD9qP17HJ+jnehopCyzTv8ZqOYWWi7VrrvYDg2xaGzEHeR6nI1Us39uf 4g+34lsJrVJahUfLo5XR1tHaRN9E/8TwxNTp8nRlunW6Nsc3xz8nPCf1EeTWPGJ9RFsmL1OWWZdp m+RNynbf9vAB34Hwu74vfD/4rvquhrNS/QZeSAt1ljydLRZIByktKSkx0WFAaukrEVMvW9BOI3Z6 D/TxOnqyNrFXEjtv7qX6g4k0kkjvSaSJrKIXl4aKV3qBKaT320PL4ujJQiQFMy+VT5lSUDAzOhOY iqOZUQ/6r9uN2ME9j9xClujGJkAn8ySkWrMlGDeQOoieiUbZVrqh34Ket40KlY/u1mvMBlOqq929 hWs6u/NmtBfKG8iGOQ/OKBjzYN/Zu+t3cdfuKk5dXxddwV1d3q728ej9cRmJgcVac6Y/LGnidTav wjtdNnA65EebDGZTAGlFVepSlVN9bs7VyOsS/juvA8018jpN1hTku2iyuQ21qLY4l8tq5HJ2hyA6 BFsf0S46+xCH82YuR9B/OGH1LL8beq4zuVHPdWtkcUL5xflPjH/hyr/xtyHQF2c25pNtjQxZyT0t PK2sNAhH6BHuiHBEPCofVY4ajhqPmo9ajmpHbUccSBZKOOI+T8/rgaV6Wi/+S/6X0YN4UViSTWEs JMquwsIKhIyyq3iKqFH/sTeqyo2pdDqLj8eNsKW6UmzNZHGjTBY3ymRxo0wWN4LUFLBhPnx9oy+j EFMIy7lri+RjkqGniWOWYUtxYy/EvqLBCz/TYOyrn1fU1KxYWVMDompooP1jtQ0NsR2rv3v72Hff HXv7O2Y7Id7yB/Sd6cqHI7ftQp7Hce6jJLCW+Z7tng88P4g/yt+4r8kKrKfEuNacmOBweq3QmqEt yzYJmrNRs3jjBlTQbg1oWo7tGRtn8wZ+t6DiDs142IPpzv9NdWZaM2X6M2Vas64/o8c6823EhCbV WWSqM7lZddYzPnU6uG5CAR3+7zZUrL9kjbW4wYpi+lZ/Xd9iNmZdpPhJeZP7LOwKoRr6FuyKRMHI tCw/DAtmYLr8RpvHWsxMSxlWptFmcdgwLlZfwBNXq5JvUqt+9/VC9t+oVekY0mhfMtOSMCNTNy0J MzKbDU2TfSkw+xKrmv53den/bFVc+YWvvkn/uQqeEAH+2JAJlQXlx4yllEazQZE4g4FwZjAGTiIQ ygGkKvgcnA1ixms/EDccGzWfxpwSYAWTMwD868pkXAm0WAXRKpj7iBZR60Os2o2k30T3bmjTcSZ3 de+Qr6srK3fm+Me9NRwUX/1YIDa5Qdm4MXqvLn+2gNbbob0t6dDIDi4lh+TQHC6nZRe1i6FDcofA 6BSsrU+9z3qfNi00LWVaeFrqMsfTGdsy9trrHLtafqR+ZDirYvWVetGQzIQmW/ioJqlYHUKtCVa3 Dwt+WyS0cBdguW5xsDj0BzIoOCg0iYw3jjePt4y3VgYqg7PJLOMs0yzzLMss9yzPjMCMYDWWx24n e4J7QkfMJ0wnzOl9lJSAxSB4BYvNEEhMkd3rhifM8IadMvSYxIhBIEK4hdH9Sin8brt3V2H1ly8L gmR3xJhjo7bxxJvZ+sW4AqanojMVZ+YZyA2YIchFQjSGMpcc88ldN1zb+TJEh8+RmEvEDDmXIh84 lyZbUfTbvblUShdyiZJqwMrUFNWQpAVySXLAatE9PPqmiS2xeDZbtpIMVox1K8h45NIz4qsC9bx/ sCd3QoBiPRpS3cMpW6quDlk8JylpWmT++x06fvzzzmfqnpu5oHP+/LkvlpR8+euJLm/27vKHntnB YI4v77biniOra9tt7X57YUFqak7roj597vnzvrhcqsCcdhMPwb8xJ+KoJgvFp8kK8QUiItGH96gJ yOTIf8WgqelWpPg8GTEkIOpFxgdh49XRP0asZnvAJH8XYOvgvP2bPBpsweTFcra8UV/Xy5xk11VD lxM5QC7B3oY4pIQ2TaphozGCRGg9BSiefRa3ToVuD8/sOOPQKLaabS/9JWaNTOy9cEV2R9ewmjp6 aDU9FCtcHeu28J52g+P9WYL+tMW3j1zkiUi7Y/JnDi4QsUm6pDWBriBtjS4OX187AD3H5zaZA0aD IUd9EA5nXvUmNE5+edyeYCpuI4GB7xb8LmtZKInJWsJkbVMik+7Ma5K1ApO1tLmsRRyzPVN7WUcb g0wdOtqEtnuHfX73yA0RyNrckV/3Ecqvbfi1unr8tstcVXQWrIk9i7nHmV6mx5bQN4lsjLScxy/l n+HP8Vd5sZQbwo2jY8Ut0AG/ES+TS6KqiCqcuXA4I2OmYVGkBRTFIBRXEkAiCsdW6bEDWCHwVOOj MxLYDGK8giTupRHC00jECickvslUQwWsVpz3pO5+1wNI5/+X8BEUkaZgZEh3viNaF/O/Qx+kC/fG 3EJ5/SJ++rUN8bnCkmihDv1xIA67tumLAYJMkC1pVe1eg9fst6erLc0tLPnmPmZEYJFbMMk4zjQD izzvByNYQBbQVdJK65tWLDOTvkHY+4p4RfrN8ps1BZ+Ls5ZwJfwJwyfGkyZZsCFBwWyCq9toQljC YTFDf9dUQbNJsmq2CMRxj+lBrEw5YwmYq+SAVJVqoo5A6T34IBNHzlAnFgOXI7GoPho974mWx9ks 47TenJyuOWAPUPWh9euuLD0Oq8dg9BAMNo0RmGO7X5yQ6K99/mjYPXHJKy+dSBEDe4Xy6NB169hC Lba9toF7b93aaC6ba5aztRZjY0QccTHjvrzSQmwptZQzlXx5DPLYxwrT+GnCKm4rt1V8QXpBrhP3 SXvko+Kn4rfG3+RLRl9YbC+O5caIf+QeETeLn3DfKep/C8sE4P5nYZnA72EZKR6WQQJdPCyDWMzL eiymUctuDMewlTr/ezSG6RY3BWOsn9BXY2N+QmTR/2FsDn3359h2fNXKGXuM3huNRTfR11iPSTDW WngRY2AnH0eWPoYPVL1APuEFfNKhjDxGqvlFwmPiY/ZVZBX/pPSk/AK/XXhBrOP3CHvEo8JR8ZRw SnSpUCB1ImADyHN2u2CyWxrpgGhIwkKaRABrVbFqlfD2RmKwG+C6tdrRbyT40yLxVnG4eI+4RBRF n9OEpdTIPusXp4gz5fnXI1L9GItgHJ2F6FkyFlvI3pQAGM+BgCMMa5f0wCqz/8rTmgiELX/TTeOO SOypfxfpyEP3xW597LfDg3v0Kxm2aLonW8hF7m/JtX/GXv3UutFTUtuNjQ9iJ/h6VTniOcMjjq3c WxzHYjlsMptiOXWI5UgsxlTHYjmGeCynmMVyihHLYd5ZOGf/T7GcBdyL0VH8smh/7ug2tiCj/ns9 lsO5Go5zdSycrsdyPsSb+CS00Sss+kh/SRMfxWISsD7OtQGrvq/gAxLMP7GLXyZ4df9EmHSNhKjj q1K7Mam36B5O7BqZhrXzymjL0/ZpPvco3+hgWmrOOyfOn9e+ucQ2ukkL6xYGnwdWrcvCudgqeuYb YR7CtOYnBC8W199ZNrLb4FlYXP+nG1baS5MfcJRM7j++SwlW2t9zqFq7udisnR0jUJ/RTjLcLfZO MrJmjsYaf9bK0e5RrJEfnTgfRRujTU2Mt9DRfLW/2PzErhvaRKeW3oJPAYzoNhifAuCX3dyi5g3U x5KNKGnYyXxr/+F3K86B84Gr/KevtCTAE3fjt1mC/8MXWdr81++wdP+3r6/cQtgXTW4lA8ht+J7J 7fjeHft63hAyFIQ8jPyB3Ikv9g3Ht2VeQesoqB1yCj8JK2pJtwG9hgwdltXvnrtHjLqH1Tb+aE8U BgAqAFWAeYClgGcANYCDgPcBXwEuMCQDaIAgIBcQAQwAVACqAPMASwHPAGoABwHvA74CXGCDBtAA QUAuIAIYAKgAVAHmAZYCngHUAA4C3gd8BbgAOiUADRAE5AIigAGACkAVYB5gKeAZQA3gIOB9wFeA C/guLwFogCAgFxABDABUAKoA8wBLAc8AagAHAe8DvgJcYIMJ0ADBhsYfTpDrx+C1zcoZzcotmpVb NivjK3Q3PS+rWblVs3J2s3LrZmX2NY0b25fbrMy+BHRjPYtw31jOa1ZGXP+m+vbNygh+3VTfsVkZ 8vim+vxm5c7Nyl2blbs1K3dvVu7RrNyzWbm4WbmkWbm0WblXs3LvZuU+zcp9m5X17yXdgB/9mtXr Xyi6oZ5xlhvHf0Cz8m3NygOblW9vVh7UrKyr9ze8745m9UOalYc2K5c1Kw9rVh7erDyiWXlks/Ko ZuXRzcqVzcpjmpXHNiuPa1Ye36w8oVl5YrPypGblyc3Kdzcrg5neNF9VzcpTmpWnNitPa1ae3qw8 o1l5ZrMy8yjciC/3NSvD131TPXJXbirPubkcRA7ajfVBKB+E/D8Lx8NHCmVuZHN0cmVhbQplbmRv YmoKMzQgMCBvYmoKMTY4MDkKZW5kb2JqCjM1IDAgb2JqCihkcmFmdC1pZXRmLXNpZHItYmdwc2Vj LWFsZ3MtZXhhbXBsZXMtdjIpCmVuZG9iagozNiAwIG9iagooTWFjIE9TIFggMTAuMTEuNiBRdWFy dHogUERGQ29udGV4dCkKZW5kb2JqCjM3IDAgb2JqCihUZXh0RWRpdCkKZW5kb2JqCjM4IDAgb2Jq CihEOjIwMTcwMTI2MjAwOTU2WjAwJzAwJykKZW5kb2JqCjM5IDAgb2JqCigpCmVuZG9iago0MCAw IG9iagpbIF0KZW5kb2JqCjEgMCBvYmoKPDwgL1RpdGxlIDM1IDAgUiAvUHJvZHVjZXIgMzYgMCBS IC9DcmVhdG9yIDM3IDAgUiAvQ3JlYXRpb25EYXRlIDM4IDAgUiAvTW9kRGF0ZQozOCAwIFIgL0tl eXdvcmRzIDM5IDAgUiAvQUFQTDpLZXl3b3JkcyA0MCAwIFIgPj4KZW5kb2JqCnhyZWYKMCA0MQow MDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMjkyMDAgMDAwMDAgbiAKMDAwMDAwMTYyNiAwMDAwMCBu IAowMDAwMDEwOTYzIDAwMDAwIG4gCjAwMDAwMDAwMjIgMDAwMDAgbiAKMDAwMDAwMTYwNiAwMDAw MCBuIAowMDAwMDAxNzMwIDAwMDAwIG4gCjAwMDAwMDMwNjcgMDAwMDAgbiAKMDAwMDAxMTEzMSAw MDAwMCBuIAowMDAwMDAxODI3IDAwMDAwIG4gCjAwMDAwMDMwNDYgMDAwMDAgbiAKMDAwMDAwNDg0 MCAwMDAwMCBuIAowMDAwMDAzMTAyIDAwMDAwIG4gCjAwMDAwMDQ4MTkgMDAwMDAgbiAKMDAwMDAw NDk0NyAwMDAwMCBuIAowMDAwMDA2ODQ4IDAwMDAwIG4gCjAwMDAwMDUwNDUgMDAwMDAgbiAKMDAw MDAwNjgyNyAwMDAwMCBuIAowMDAwMDA2OTU1IDAwMDAwIG4gCjAwMDAwMDg1ODYgMDAwMDAgbiAK MDAwMDAwNzA1MyAwMDAwMCBuIAowMDAwMDA4NTY1IDAwMDAwIG4gCjAwMDAwMDg2OTMgMDAwMDAg biAKMDAwMDAxMDMwNiAwMDAwMCBuIAowMDAwMDA4NzkxIDAwMDAwIG4gCjAwMDAwMTAyODUgMDAw MDAgbiAKMDAwMDAxMDQxMyAwMDAwMCBuIAowMDAwMDEwNzU4IDAwMDAwIG4gCjAwMDAwMTA1MTEg MDAwMDAgbiAKMDAwMDAxMDczOCAwMDAwMCBuIAowMDAwMDEwODY1IDAwMDAwIG4gCjAwMDAwMTEw ODEgMDAwMDAgbiAKMDAwMDAxMTgxNSAwMDAwMCBuIAowMDAwMDEyMDU5IDAwMDAwIG4gCjAwMDAw Mjg5NTkgMDAwMDAgbiAKMDAwMDAyODk4MSAwMDAwMCBuIAowMDAwMDI5MDM5IDAwMDAwIG4gCjAw MDAwMjkwOTIgMDAwMDAgbiAKMDAwMDAyOTExOSAwMDAwMCBuIAowMDAwMDI5MTYxIDAwMDAwIG4g CjAwMDAwMjkxODAgMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSA0MSAvUm9vdCAzMSAwIFIgL0lu Zm8gMSAwIFIgL0lEIFsgPGMwNWRiYmUzNjMwYjU0YjM1MzhjODY5ZjUwMDlmYjQ5Pgo8YzA1ZGJi ZTM2MzBiNTRiMzUzOGM4NjlmNTAwOWZiNDk+IF0gPj4Kc3RhcnR4cmVmCjI5MzQ0CiUlRU9GCg== --_003_06FD4D79FBDD44E09CF24B7A039A06A9nistgov_ Content-Type: text/plain; name="draft-ietf-sidr-bgpsec-algs-examples-v2.txt" Content-Description: draft-ietf-sidr-bgpsec-algs-examples-v2.txt Content-Disposition: attachment; filename="draft-ietf-sidr-bgpsec-algs-examples-v2.txt"; size=10076; creation-date="Thu, 26 Jan 2017 20:10:17 GMT"; modification-date="Thu, 26 Jan 2017 20:10:17 GMT" Content-ID: <673F79F7B75B95459298DA7F361527D8@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 VG9wb2xvZ3k6CgpBUyg2NDQ5NiktLS0tQVMoNjU1MzYpLS0tLUFTKDY1NTM3KQoKUHJlZml4IEFu bm91bmNlbWVudDogQVMoNjQ0OTYpLCAxOTIuMC4yLjAvMjQKCkZvciB0aGlzIGV4YW1wbGUsIHRo ZSBFQ0RTQSBhbGdvcml0aG0gd2FzIHByb3ZpZGVkIHdpdGggYSBzdGF0aWMgayB0byAKbWFrZSB0 aGUgcmVzdWx0IGRldGVybWluaXN0aWMuIApUaGUgayB1c2VkIGZvciBhbGwgc2lnbmF0dXJlIG9w ZXJhdGlvbnMgd2FzIHRha2VuIGZyb20gUkZDIDY5NzksIApjaGFwdGVyIEEuMi41IOKAnFNpZ25h dHVyZXMgV2l0aCBTSEEtMjU2LCBtZXNzYWdlICdzYW1wbGUn4oCdLgoKICBrID0gQTZFM0M1N0RE MDFBQkU5MDA4NjUzODM5ODM1NURENEMzQjE3QUE4NzMzODJCMEYyNEQ2MTI5NDkzRDhBQUQ2MAoK S2V5cyBvZiBBUzY0NDk2Ogo9PT09PT09PT09PT09PT09CnNraTogQUI0RDkxMEY1NUNBRTcxQTIx NUVGM0NBRkUzQUNDNDVCNUVFQzE1NAoKcHJpdmF0ZSBrZXk6CiAgeCA9IEQ4QUE0REZCRTI0NzhG ODZFODhBNzQ1MUJGMDc1NTY1NzA5QzU3NUFDMUMxMzZEMDgxQzU0MDI1NENBNDQwQjkKCnB1Ymxp YyBrZXk6IAogIFV4ID0gNzM5MUJBQkI5MkEwQ0IzQkUxMEU1OUIxOUVCRkZCMjE0RTA0QTkxRTBD QkExQjEzOUE3RDM4RDkwRjc3RTU1QQogIFV5ID0gQTA1QjhFNjk1Njc4RTBGQTE2OTA0QjU1RDlE NEY1QzBERkM1ODg5NUVFNTBCQzRGNzVEMjA1QTI1QkQzNkZGNQoKUm91dGVyIEtleSBDZXJ0aWZp Y2F0ZSBleGFtcGxlIHVzaW5nIE9wZW5TU0wgMS4wLjFlLWZpcHMgMTEgRmViIDIwMTMKLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KQ2VydGlmaWNhdGU6CiAgICBEYXRhOgogICAgICAgIFZlcnNpb246IDMgKDB4MikKICAg ICAgICBTZXJpYWwgTnVtYmVyOiAzODY1NTYxMiAoMHgyNGRkNjdjKQogICAgU2lnbmF0dXJlIEFs Z29yaXRobTogZWNkc2Etd2l0aC1TSEEyNTYKICAgICAgICBJc3N1ZXI6IENOPVJPVVRFUi0wMDAw RkJGMAogICAgICAgIFZhbGlkaXR5CiAgICAgICAgICAgIE5vdCBCZWZvcmU6IEphbiAgMSAwNTow MDowMCAyMDE3IEdNVAogICAgICAgICAgICBOb3QgQWZ0ZXIgOiBKdWwgIDEgMDU6MDA6MDAgMjAx OCBHTVQKICAgICAgICBTdWJqZWN0OiBDTj1ST1VURVItMDAwMEZCRjAKICAgICAgICBTdWJqZWN0 IFB1YmxpYyBLZXkgSW5mbzoKICAgICAgICAgICAgUHVibGljIEtleSBBbGdvcml0aG06IGlkLWVj UHVibGljS2V5CiAgICAgICAgICAgICAgICBQdWJsaWMtS2V5OiAoMjU2IGJpdCkKICAgICAgICAg ICAgICAgIHB1YjogCiAgICAgICAgICAgICAgICAgICAgMDQ6NzM6OTE6YmE6YmI6OTI6YTA6Y2I6 M2I6ZTE6MGU6NTk6YjE6OWU6YmY6CiAgICAgICAgICAgICAgICAgICAgZmI6MjE6NGU6MDQ6YTk6 MWU6MGM6YmE6MWI6MTM6OWE6N2Q6Mzg6ZDk6MGY6CiAgICAgICAgICAgICAgICAgICAgNzc6ZTU6 NWE6YTA6NWI6OGU6Njk6NTY6Nzg6ZTA6ZmE6MTY6OTA6NGI6NTU6CiAgICAgICAgICAgICAgICAg ICAgZDk6ZDQ6ZjU6YzA6ZGY6YzU6ODg6OTU6ZWU6NTA6YmM6NGY6NzU6ZDI6MDU6CiAgICAgICAg ICAgICAgICAgICAgYTI6NWI6ZDM6NmY6ZjUKICAgICAgICAgICAgICAgIEFTTjEgT0lEOiBwcmlt ZTI1NnYxCiAgICAgICAgWDUwOXYzIGV4dGVuc2lvbnM6CiAgICAgICAgICAgIFg1MDl2MyBLZXkg VXNhZ2U6IAogICAgICAgICAgICAgICAgRGlnaXRhbCBTaWduYXR1cmUKICAgICAgICAgICAgWDUw OXYzIFN1YmplY3QgS2V5IElkZW50aWZpZXI6IAogICAgICAgICAgICAgICAgQUI6NEQ6OTE6MEY6 NTU6Q0E6RTc6MUE6MjE6NUU6RjM6Q0E6RkU6M0E6Q0M6NDU6QjU6RUU6QzE6NTQKICAgICAgICAg ICAgWDUwOXYzIEV4dGVuZGVkIEtleSBVc2FnZTogCiAgICAgICAgICAgICAgICAxLjMuNi4xLjUu NS43LjMuMzAKICAgICAgICAgICAgc2JncC1hdXRvbm9tb3VzU3lzTnVtOiBjcml0aWNhbAogICAg ICAgICAgICAgICAgQXV0b25vbW91cyBTeXN0ZW0gTnVtYmVyczoKICAgICAgICAgICAgICAgICAg NjQ0OTYKICAgICAgICAgICAgICAgIFJvdXRpbmcgRG9tYWluIElkZW50aWZpZXJzOgogICAgICAg ICAgICAgICAgICBpbmhlcml0CgogICAgU2lnbmF0dXJlIEFsZ29yaXRobTogZWNkc2Etd2l0aC1T SEEyNTYKICAgICAgICAgMzA6NDQ6MDI6MjA6MDc6Yjc6YjQ6NmE6NWY6YTQ6ZjE6Y2M6Njg6MzY6 Mzk6MDM6YTQ6ODM6CiAgICAgICAgIGVjOjdjOjgwOjAyOmQyOmY2OjA4OjlkOjQ2OmIyOmVjOjJh OjdiOmU2OjkyOmIzOjZmOmIxOgogICAgICAgICAwMjoyMDowMDo5MTowNTo0YTphMTpmNTpiMDox ODo5ZDoyNzoyNDplODpiNDoyMjpmZDpkMToKICAgICAgICAgMWM6ZjA6M2Q6YjE6Mzg6MjQ6NWQ6 NjQ6Mjk6MzU6Mjg6OGQ6ZWU6MGM6Mzg6MjkKLS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1J SUJpRENDQVMrZ0F3SUJBZ0lFQWszV2ZEQUtCZ2dxaGtqT1BRUURBakFhTVJnd0ZnWURWUVFEREE5 U1QxVlUKUlZJdE1EQXdNRVpDUmpBd0hoY05NVGN3TVRBeE1EVXdNREF3V2hjTk1UZ3dOekF4TURV d01EQXdXakFhTVJndwpGZ1lEVlFRRERBOVNUMVZVUlZJdE1EQXdNRVpDUmpBd1dUQVRCZ2NxaGtq T1BRSUJCZ2dxaGtqT1BRTUJCd05DCkFBUnprYnE3a3FETE8rRU9XYkdldi9zaFRnU3BIZ3k2R3hP YWZUalpEM2ZsV3FCYmptbFdlT0Q2RnBCTFZkblUKOWNEZnhZaVY3bEM4VDNYU0JhSmIwMi8xbzJN d1lUQUxCZ05WSFE4RUJBTUNCNEF3SFFZRFZSME9CQllFRkt0TgprUTlWeXVjYUlWN3p5djQ2ekVX MTdzRlVNQk1HQTFVZEpRUU1NQW9HQ0NzR0FRVUZCd01lTUI0R0NDc0dBUVVGCkJ3RUlBUUgvQkE4 d0RhQUhNQVVDQXdENzhLRUNCUUF3Q2dZSUtvWkl6ajBFQXdJRFJ3QXdSQUlnQjdlMGFsK2sKOGN4 b05qa0RwSVBzZklBQzB2WUluVWF5N0NwNzVwS3piN0VDSUFDUkJVcWg5YkFZblNjazZMUWkvZEVj OEQyeApPQ1JkWkNrMUtJM3VERGdwCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0KCgoKS2V5cyBv ZiBBUyg2NTYzNik6Cj09PT09PT09PT09PT09PT09PQpza2k6IDQ3RjIzQkYxQUIyRjhBOUQyNjg2 NEVCQkQ4REYyNzExQzc0NDA2RUMKCnByaXZhdGUga2V5OgogIHggPSA2Q0IyRTkzMUIxMTJGMjQ1 NTRCQ0RDQUFGRDk1NTNBOTUxOUE5QUYzM0MwMjNCNjA4NDZBMjFGQzk1NTgzMTcyCgpwdWJsaWMg a2V5OiAKICBVeCA9IDI4RkM1RkU5QUZDRjVGNENBQjNGNUY4NUNCMjEyRkMxRTlEMEUwREJFQUVF NDI1QkQyRjBEMzE3NUFBMEU5ODkKICBVeSA9IEVBOUI2MDNFMzhGMzVGQjMyOURGNDk1NjQxRjJC QTA0MEYxQzNBQzYxMzgzMDdGMjU3Q0JBNkI4QjU4OEY0MUYKClJvdXRlciBLZXkgQ2VydGlmaWNh dGUgZXhhbXBsZSB1c2luZyBPcGVuU1NMIDEuMC4xZS1maXBzIDExIEZlYiAyMDEzCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tCkNlcnRpZmljYXRlOgogICAgRGF0YToKICAgICAgICBWZXJzaW9uOiAzICgweDIpCiAgICAg ICAgU2VyaWFsIE51bWJlcjogMzE2ODE4OTk0MiAoMHhiY2Q2YmRmNikKICAgIFNpZ25hdHVyZSBB bGdvcml0aG06IGVjZHNhLXdpdGgtU0hBMjU2CiAgICAgICAgSXNzdWVyOiBDTj1ST1VURVItMDAw MEZGRkYKICAgICAgICBWYWxpZGl0eQogICAgICAgICAgICBOb3QgQmVmb3JlOiBKYW4gIDEgMDU6 MDA6MDAgMjAxNyBHTVQKICAgICAgICAgICAgTm90IEFmdGVyIDogSnVsICAxIDA1OjAwOjAwIDIw MTggR01UCiAgICAgICAgU3ViamVjdDogQ049Uk9VVEVSLTAwMDBGRkZGCiAgICAgICAgU3ViamVj dCBQdWJsaWMgS2V5IEluZm86CiAgICAgICAgICAgIFB1YmxpYyBLZXkgQWxnb3JpdGhtOiBpZC1l Y1B1YmxpY0tleQogICAgICAgICAgICAgICAgUHVibGljLUtleTogKDI1NiBiaXQpCiAgICAgICAg ICAgICAgICBwdWI6IAogICAgICAgICAgICAgICAgICAgIDA0OjI4OmZjOjVmOmU5OmFmOmNmOjVm OjRjOmFiOjNmOjVmOjg1OmNiOjIxOgogICAgICAgICAgICAgICAgICAgIDJmOmMxOmU5OmQwOmUw OmRiOmVhOmVlOjQyOjViOmQyOmYwOmQzOjE3OjVhOgogICAgICAgICAgICAgICAgICAgIGEwOmU5 Ojg5OmVhOjliOjYwOjNlOjM4OmYzOjVmOmIzOjI5OmRmOjQ5OjU2OgogICAgICAgICAgICAgICAg ICAgIDQxOmYyOmJhOjA0OjBmOjFjOjNhOmM2OjEzOjgzOjA3OmYyOjU3OmNiOmE2OgogICAgICAg ICAgICAgICAgICAgIGI4OmI1Ojg4OmY0OjFmCiAgICAgICAgICAgICAgICBBU04xIE9JRDogcHJp bWUyNTZ2MQogICAgICAgIFg1MDl2MyBleHRlbnNpb25zOgogICAgICAgICAgICBYNTA5djMgS2V5 IFVzYWdlOiAKICAgICAgICAgICAgICAgIERpZ2l0YWwgU2lnbmF0dXJlCiAgICAgICAgICAgIFg1 MDl2MyBTdWJqZWN0IEtleSBJZGVudGlmaWVyOiAKICAgICAgICAgICAgICAgIDQ3OkYyOjNCOkYx OkFCOjJGOjhBOjlEOjI2Ojg2OjRFOkJCOkQ4OkRGOjI3OjExOkM3OjQ0OjA2OkVDCiAgICAgICAg ICAgIFg1MDl2MyBFeHRlbmRlZCBLZXkgVXNhZ2U6IAogICAgICAgICAgICAgICAgMS4zLjYuMS41 LjUuNy4zLjMwCiAgICAgICAgICAgIHNiZ3AtYXV0b25vbW91c1N5c051bTogY3JpdGljYWwKICAg ICAgICAgICAgICAgIEF1dG9ub21vdXMgU3lzdGVtIE51bWJlcnM6CiAgICAgICAgICAgICAgICAg IDY1NTM1CiAgICAgICAgICAgICAgICBSb3V0aW5nIERvbWFpbiBJZGVudGlmaWVyczoKICAgICAg ICAgICAgICAgICAgaW5oZXJpdAoKICAgIFNpZ25hdHVyZSBBbGdvcml0aG06IGVjZHNhLXdpdGgt U0hBMjU2CiAgICAgICAgIDMwOjQ1OjAyOjIxOjAwOmRmOjA0OmM1OjE3OjA0OmQwOmYyOmI5OmZh OmYzOmQ5OjZlOjNmOgogICAgICAgICA2ZjphMTo1ODpkODpmZTo2YzoxODplNDozNzpjYToxOTo3 YzpjODo3NTo0MDo1Nzo2ZTo3ZToKICAgICAgICAgOWQ6MDI6MjA6MTI6NDU6ZTg6YTg6NTg6NmI6 MDA6N2I6ZTY6YTk6MGU6ZjI6YjY6NjI6NTA6CiAgICAgICAgIDRiOjFjOjAxOjZmOjNiOjQxOjEx OjY5Ojg4OjMwOjczOjlmOmQ3OjAyOjllOjY0OjRmCi0tLS0tQkVHSU4gQ0VSVElGSUNBVEUtLS0t LQpNSUlCaWpDQ0FUQ2dBd0lCQWdJRkFMeld2Zll3Q2dZSUtvWkl6ajBFQXdJd0dqRVlNQllHQTFV RUF3d1BVazlWClZFVlNMVEF3TURCR1JrWkdNQjRYRFRFM01ERXdNVEExTURBd01Gb1hEVEU0TURj d01UQTFNREF3TUZvd0dqRVkKTUJZR0ExVUVBd3dQVWs5VlZFVlNMVEF3TURCR1JrWkdNRmt3RXdZ SEtvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRApRZ0FFS1B4ZjZhL1BYMHlyUDErRnl5RXZ3ZW5RNE52 cTdrSmIwdkRURjFxZzZZbnFtMkErT1BOZnN5bmZTVlpCCjhyb0VEeHc2eGhPREIvSlh5NmE0dFlq MEg2TmpNR0V3Q3dZRFZSMFBCQVFEQWdlQU1CMEdBMVVkRGdRV0JCUkgKOGp2eHF5K0tuU2FHVHJ2 WTN5Y1J4MFFHN0RBVEJnTlZIU1VFRERBS0JnZ3JCZ0VGQlFjREhqQWVCZ2dyQmdFRgpCUWNCQ0FF Qi93UVBNQTJnQnpBRkFnTUEvLytoQWdVQU1Bb0dDQ3FHU000OUJBTUNBMGdBTUVVQ0lRRGZCTVVY CkJORHl1ZnJ6Mlc0L2I2RlkyUDVzR09RM3lobDh5SFZBVjI1K25RSWdFa1hvcUZockFIdm1xUTd5 dG1KUVN4d0IKYnp0QkVXbUlNSE9mMXdLZVpFOD0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQoK CgpCR1BTZWMgVXBkYXRlIGZyb20gQVMoNjU1MzYpIHRvIEFTKDY1NTM3KToKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpCaW5hcnkgRm9ybSBvZiBCR1BTZWMgVXBk YXRlIChUQ1AtRFVNUCk6CkZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGICBGRiBGRiBGRiBGRiBGRiBG RiBGRiBGRgowMSAwMCAwMiAwMCAwMCAwMCBFOSA0MCAgMDEgMDEgMDIgODAgMDQgMDQgMDAgMDAK MDAgMDAgODAgMEUgMEQgMDAgMDEgMDEgIDA0IEM2IDMzIDY0IDY0IDAwIDE4IEMwCjAwIDAyIDkw ICoqIDAwIENBIDAwIDBFICAwMSAwMCAwMCAwMSAwMCAwMCAwMSAwMAowMCAwMCBGQiBGMCAwMCBC QyAwMSA0NyAgRjIgM0IgRjEgQUIgMkYgOEEgOUQgMjYKODYgNEUgQkIgRDggREYgMjcgMTEgQzcg IDQ0IDA2IEVDIDAwIDQ2IDMwIDQ0IDAyCjIwIDcyIDE0IEJDIDk2IDQ3IDE2IDBCICBCRCAzOSBG RiAyRiA4MCA1MyAzRiA1RApDNiBERCBENyAwRCBERiA4NiBCQiA4MSAgNTYgNjEgRTggMDUgRDUg RDQgRTYgRjIKN0MgMDIgMjAgMkQgREMgMDAgM0MgNjQgIEJFIDdCIDI5IEM5IEVCIERCIEM4IEE0 Cjk3IEVEIDY2IDI4IDVFIEU5IDIyIDc2ICA4MyBFNiBDMSA3OCBDRSA4RCBFNiBEMwo1OSA1RiA0 MSBBQiA0RCA5MSAwRiA1NSAgQ0EgRTcgMUEgMjEgNUUgRjMgQ0EgRkUKM0EgQ0MgNDUgQjUgRUUg QzEgNTQgMDAgIDQ3IDMwIDQ1IDAyIDIwIDcyIDE0IEJDCjk2IDQ3IDE2IDBCIEJEIDM5IEZGIDJG ICA4MCA1MyAzRiA1RCBDNiBERCBENyAwRApERiA4NiBCQiA4MSA1NiA2MSBFOCAwNSAgRDUgRDQg RTYgRjIgN0MgMDIgMjEgMDAKQzYgMTcgMTkgMzQgMDcgNDMgMDYgM0IgIDhBIDVDIENEIDU0IDE2 IDM5IDBCIDMxCjIxIDFEIDNDIDUyIDQ4IDA3IDk1IDg3ICBEMCAxMyAxMyA3QiA0MSBDRCAyMyBF MgoKKiogVG8gYmUgcmVwbGFjZWQgd2l0aCBvbmUgb2N0ZXQgaGV4IHZhbHVlIHNwZWNpZmllZCBi eSBJQU5BIGZvcgogICB0aGUgQkdQU0VDX1BBVEggYXR0cmlidXRlLgoKClNpZ25hdHVyZSBGcm9t IEFTKDY0NDk2KSB0byBBUyg2NTUzNik6Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQpEaWdlc3Q6ICAgIDIxIDMzIEU1IENBIEEwIDI2IEJFIDA3ICAgM0QgOUMgMUIgNEUg RkUgQjkgQjkgNzcgCiAgICAgICAgICAgOUYgMjAgRjggRjUgREUgMjkgRkEgOTggICA0MCAwMCA5 RiA2MCAKU2lnbmF0dXJlOiAzMCA0NSAwMiAyMCA3MiAxNCBCQyA5NiAgIDQ3IDE2IDBCIEJEIDM5 IEZGIDJGIDgwIAogICAgICAgICAgIDUzIDNGIDVEIEM2IEREIEQ3IDBEIERGICAgODYgQkIgODEg NTYgNjEgRTggMDUgRDUgCiAgICAgICAgICAgRDQgRTYgRjIgN0MgMDIgMjEgMDAgQzYgICAxNyAx OSAzNCAwNyA0MyAwNiAzQiA4QSAKICAgICAgICAgICA1QyBDRCA1NCAxNiAzOSAwQiAzMSAyMSAg IDFEIDNDIDUyIDQ4IDA3IDk1IDg3IEQwIAogICAgICAgICAgIDEzIDEzIDdCIDQxIENEIDIzIEUy IAoKU2lnbmF0dXJlIEZyb20gQVMoNjU1MzYpIHRvIEFTKDY1NTM3KToKLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KRGlnZXN0OiAgICA0NiA0QiA1NyBDRSBCMSAyRCAxOCBC MCAgIEZEIDFBIDFBIDM1IDk0IDE3IDNBIDRBIAogICAgICAgICAgIDA5IDg4IEU1IEY0IEVEIEVE IDJGIDNEICAgODMgMDggNUEgQTggClNpZ25hdHVyZTogMzAgNDQgMDIgMjAgNzIgMTQgQkMgOTYg ICA0NyAxNiAwQiBCRCAzOSBGRiAyRiA4MCAKICAgICAgICAgICA1MyAzRiA1RCBDNiBERCBENyAw RCBERiAgIDg2IEJCIDgxIDU2IDYxIEU4IDA1IEQ1IAogICAgICAgICAgIEQ0IEU2IEYyIDdDIDAy IDIwIDJEIERDICAgMDAgM0MgNjQgQkUgN0IgMjkgQzkgRUIgCiAgICAgICAgICAgREIgQzggQTQg OTcgRUQgNjYgMjggNUUgICBFOSAyMiA3NiA4MyBFNiBDMSA3OCBDRSAKICAgICAgICAgICA4RCBF NiBEMyA1OSA1RiA0MSAKCgpUaGUgaHVtYW4gcmVhZGFibGUgb3V0cHV0IGlzIHByb2R1Y2VkIHVz aW5nIGJncHNlYy1pbywgYSBiZ3BzZWMgCnRyYWZmaWMgZ2VuZXJhdG9yIHRoYXQgdXNlcyBhIHdp cmVzaGFyayBsaWtlIHByaW50b3V0LgoKU2VuZCBVcGRhdGUgTWVzc2FnZQorLS1tYXJrZXI6IEZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGCistLWxlbmd0aDogMjU2CistLXR5cGU6ICAg MiAoVVBEQVRFKQorLS13aXRoZHJhd25fcm91dGVzX2xlbmd0aDogMAorLS10b3RhbF9wYXRoX2F0 dHJfbGVuZ3RoOiAyMzMKICAgKy0tT1JJR0lOOiBJTkNPTVBMRVRFICg0IGJ5dGVzKQogICB8ICAr LS1GbGFnczogMHg0MCAoV2VsbC1Lbm93biwgVHJhbnNpdGl2ZSwgQ29tcGxldGUpCiAgIHwgICst LVR5cGUgQ29kZTogT1JJR0lOICgxKQogICB8ICArLS1MZW5ndGg6IDEgYnl0ZQogICB8ICArLS1P cmlnaW46IElOQ09NUExFVEUgKDEpCiAgICstLU1VTFRJX0VYSVRfRElTQyAoNyBieXRlcykKICAg fCAgKy0tRmxhZ3M6IDB4ODAgKE9wdGlvbmFsLCBDb21wbGV0ZSkKICAgfCAgKy0tVHlwZSBDb2Rl OiBNVUxUSV9FWElUX0RJU0MgKDQpCiAgIHwgICstLUxlbmd0aDogNCBieXRlcwogICB8ICArLS1k YXRhOiAwMCAwMCAwMCAwMCAKICAgKy0tTVBfUkVBQ0hfTkxSSSAoMTYgYnl0ZXMpCiAgIHwgICst LUZsYWdzOiAweDgwIChPcHRpb25hbCwgQ29tcGxldGUpCiAgIHwgICstLVR5cGUgQ29kZTogTVBf UkVBQ0hfTkxSSSAoMTQpCiAgIHwgICstLUxlbmd0aDogMTMgYnl0ZXMKICAgfCAgKy0tZGF0YTog MDAgMDEgMDEgMDQgQzYgMzMgNjQgNjQgICAwMCAxOCBDMCAwMCAwMiAKICAgKy0tQkdQU0VDIFBh dGggQXR0cmlidXRlICgyMDYgYnl0ZXMpCiAgICAgICstLUZsYWdzOiAweDkwIChPcHRpb25hbCwg Q29tcGxldGUsIEV4dGVuZGVkIExlbmd0aCkKICAgICAgKy0tVHlwZSBDb2RlOiBCR1BTRUMgUGF0 aCBBdHRyaWJ1dGUgKCoqKQogICAgICArLS1MZW5ndGg6IDIwMiBieXRlcwogICAgICArLS1TZWN1 cmUgUGF0aCAoMTQgYnl0ZXMpCiAgICAgIHwgICstLUxlbmd0aDogMTQgYnl0ZXMKICAgICAgfCAg Ky0tU2VjdXJlIFBhdGggU2VnbWVudDogKDYgYnl0ZXMpCiAgICAgIHwgIHwgICstLXBDb3VudDog MQogICAgICB8ICB8ICArLS1GbGFnczogMAogICAgICB8ICB8ICArLS1BUyBudW1iZXI6IDY1NTM2 ICgxLjApCiAgICAgIHwgICstLVNlY3VyZSBQYXRoIFNlZ21lbnQ6ICg2IGJ5dGVzKQogICAgICB8 ICAgICArLS1wQ291bnQ6IDEKICAgICAgfCAgICAgKy0tRmxhZ3M6IDAKICAgICAgfCAgICAgKy0t QVMgbnVtYmVyOiA2NDQ5NiAoMC42NDQ5NikKICAgICAgKy0tU2lnbmF0dXJlIEJsb2NrICgxODgg Ynl0ZXMpCiAgICAgICAgICstLUxlbmd0aDogMTg4IGJ5dGVzCiAgICAgICAgICstLUFsZ28gSUQ6 IDEKICAgICAgICAgKy0tU2lnbmF0dXJlIFNlZ21lbnQ6ICg5MiBieXRlcykKICAgICAgICAgfCAg Ky0tU0tJOiA0N0YyM0JGMUFCMkY4QTlEMjY4NjRFQkJEOERGMjcxMUM3NDQwNkVDCiAgICAgICAg IHwgICstLUxlbmd0aDogNzAgYnl0ZXMKICAgICAgICAgfCAgKy0tU2lnbmF0dXJlOiAzMCA0NCAw MiAyMCA3MiAxNCBCQyA5NiAgNDcgMTYgMEIgQkQgMzkgRkYgMkYgODAgCiAgICAgICAgIHwgICAg ICAgICAgICAgICAgNTMgM0YgNUQgQzYgREQgRDcgMEQgREYgIDg2IEJCIDgxIDU2IDYxIEU4IDA1 IEQ1IAogICAgICAgICB8ICAgICAgICAgICAgICAgIEQ0IEU2IEYyIDdDIDAyIDIwIDJEIERDICAw MCAzQyA2NCBCRSA3QiAyOSBDOSBFQiAKICAgICAgICAgfCAgICAgICAgICAgICAgICBEQiBDOCBB NCA5NyBFRCA2NiAyOCA1RSAgRTkgMjIgNzYgODMgRTYgQzEgNzggQ0UgCiAgICAgICAgIHwgICAg ICAgICAgICAgICAgOEQgRTYgRDMgNTkgNUYgNDEgCiAgICAgICAgICstLVNpZ25hdHVyZSBTZWdt ZW50OiAoOTMgYnl0ZXMpCiAgICAgICAgICAgICstLVNLSTogQUI0RDkxMEY1NUNBRTcxQTIxNUVG M0NBRkUzQUNDNDVCNUVFQzE1NAogICAgICAgICAgICArLS1MZW5ndGg6IDcxIGJ5dGVzCiAgICAg ICAgICAgICstLVNpZ25hdHVyZTogMzAgNDUgMDIgMjAgNzIgMTQgQkMgOTYgIDQ3IDE2IDBCIEJE IDM5IEZGIDJGIDgwIAogICAgICAgICAgICAgICAgICAgICAgICAgIDUzIDNGIDVEIEM2IEREIEQ3 IDBEIERGICA4NiBCQiA4MSA1NiA2MSBFOCAwNSBENSAKICAgICAgICAgICAgICAgICAgICAgICAg ICBENCBFNiBGMiA3QyAwMiAyMSAwMCBDNiAgMTcgMTkgMzQgMDcgNDMgMDYgM0IgOEEgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgNUMgQ0QgNTQgMTYgMzkgMEIgMzEgMjEgIDFEIDNDIDUyIDQ4 IDA3IDk1IDg3IEQwIAogICAgICAgICAgICAgICAgICAgICAgICAgIDEzIDEzIDdCIDQxIENEIDIz IEUyIAoKKiogVG8gYmUgcmVwbGFjZWQgd2l0aCBvbmUgb2N0ZXQgaGV4IHZhbHVlIHNwZWNpZmll ZCBieSBJQU5BIGZvcgogICB0aGUgQkdQU0VDX1BBVEggYXR0cmlidXRlLgo= --_003_06FD4D79FBDD44E09CF24B7A039A06A9nistgov_-- From nobody Mon Jan 30 16:14:09 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE1F1296F3; Mon, 30 Jan 2017 16:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 h-nNMAjD05qK; Mon, 30 Jan 2017 16:14:06 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [IPv6:2001:418:8006::30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4B41296EA; Mon, 30 Jan 2017 16:13:59 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 97AF11398C; Tue, 31 Jan 2017 00:13:57 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 2DFE04664F1A; Mon, 30 Jan 2017 19:13:21 -0500 (EST) Date: Mon, 30 Jan 2017 19:13:20 -0500 From: Rob Austein To: "Alexey Melnikov" In-Reply-To: <148442017790.24124.2732462706586628755.idtracker@ietfa.amsl.com> References: <148442017790.24124.2732462706586628755.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170131001321.2DFE04664F1A@minas-ithil.hactrn.net> Archived-At: Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-publication@ietf.org, The IESG , sidr@ietf.org Subject: Re: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 00:14:07 -0000 [Sorry for delay, was out for a while with a nasty flu, still catching up.] At Sat, 14 Jan 2017 10:56:17 -0800, Alexey Melnikov wrote: ... > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I find the document to be a bit short on normative references and some > implementation details. Other than that the document looks fine. My > specific questions and concern are as follows: > > 1) Please add a normative reference for HTTP, URI and RelaxNG on first > use. Added, will be in -11 > 2) Base64 needs a normative reference (including the section number, as > there are 2 variants). Added, will be in -11. > 3) Section 2 says that all payloads use CMS. None of your examples show > CMS. Can you please elaborate on how CMS is used. The short version is already in the running text (section "Protocol Specification" describes the CMS wrapping). Not shown in examples because CMS is, um, rather verbose, and looks like dog food. A full-blown exposition on use of CMS would look like RFC 6492 section 3.1 ("CMS Profile") and all of its subsections. Sure you want that? Should we incorporate RFC 6492 3.1 by reference? > 4) How can URI of the service be discovered? Out of scope, but draft-ietf-sidr-oob-setup would be one way. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In 2.5: is the list of error reasons extensible? Probably, given sufficient cause. > Was Relax NG schema validated with a tool? Yes, using trang and xmllint. > In Section 5 you should reference the document, as IANA registrations cut > & pasted to IANA website as separate files. Would be happy to do so but does not appear to be on IANA website. Chicken and egg problem? Leave for RFC Editor? From nobody Mon Jan 30 16:19:44 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF99B1296F5; Mon, 30 Jan 2017 16:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 3wwWyBrVHr3Q; Mon, 30 Jan 2017 16:19:37 -0800 (PST) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C331296EA; Mon, 30 Jan 2017 16:19:37 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 4BDEEB869; Tue, 31 Jan 2017 00:19:37 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id A85CD4664FD9; Mon, 30 Jan 2017 19:19:00 -0500 (EST) Date: Mon, 30 Jan 2017 19:19:00 -0500 From: Rob Austein To: "Mirja Kuehlewind" In-Reply-To: <148457339142.22536.12377935833892537902.idtracker@ietfa.amsl.com> References: <148457339142.22536.12377935833892537902.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170131001900.A85CD4664FD9@minas-ithil.hactrn.net> Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-publication@ietf.org Subject: Re: [sidr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-sidr-publication-10=3A_=28with_COMMENT=29?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 00:19:39 -0000 At Mon, 16 Jan 2017 05:29:51 -0800, Mirja Kuehlewind wrote: ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > My only question is why this is a sidr wg doc? This seems like a general > mechanism that cannot only be used in the routing infrastructure. Has > this doc been at least reviewed by other wgs? It was written to solve a specific problem in in the RPKI protocol suite (it was actually written outside of the IETF, but was brought into the SIDR WG a long time ago). It's been around for years. No idea if anybody outside the SIDR WG read it before IETF Last Call. With respect, I don't think this constitutes grounds for delaying this document. Since you made this a COMMENT rather than a DISCUSS I will assume you agree unless you tell me otherwise. :) From nobody Mon Jan 30 16:34:13 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D561296EA; Mon, 30 Jan 2017 16:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 kPy8FtdmJUwG; Mon, 30 Jan 2017 16:34:05 -0800 (PST) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2A161296C7; Mon, 30 Jan 2017 16:34:05 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 98381B869; Tue, 31 Jan 2017 00:34:05 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id D76804665206; Mon, 30 Jan 2017 19:33:28 -0500 (EST) Date: Mon, 30 Jan 2017 19:33:28 -0500 From: Rob Austein To: "Alissa Cooper" In-Reply-To: <148466796666.31979.17532709479234975824.idtracker@ietfa.amsl.com> References: <148466796666.31979.17532709479234975824.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170131003328.D76804665206@minas-ithil.hactrn.net> Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-publication@ietf.org Subject: Re: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 00:34:07 -0000 At Tue, 17 Jan 2017 07:46:06 -0800, Alissa Cooper wrote: ... > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > What is the upgrade path for the future when new versions of this > protocol get published? How are clients and servers meant to agree on > which version to use? The schema includes a version number, so a new protocol version would be detectable; in the most straightforward implementation, attempting to parse an unknown protocol version would result in a schema validation error. I don't think it's really possible to specify the upgrade path in detail until one knows what the newer version looks like, ie, what changed, so I'd defer this until the (hypothetical) new version. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Although I understand why Section 6 says transport security is not > strictly required, given that the authentication and authorization > mechanisms that this protocol relies on are outside of the scope here, > isn't it possible that clients and servers may be exchanging cookies or > other headers in the course of using this protocol that would benefit > from transport encryption? It seems like mentioning that transport > security may still be beneficial although not required might be a good > idea. Um, the authentication is CMS signatures, it's just the authorization that's out of scope. I can't think of any sane reason for stuffing cookies or the like into this protocol, but yes, it's theoretically possible. The protocol is currently specified in terms of plain HTTP because an earlier version using HTTPS included a horrible authentication hairball in which HTTPS and CMS were required to use the same BPKI certificates for authentication, which turned out to be an implementation nightmare. So we backed off to plain HTTP to cut free of that mess, and we didn't think there were any privacy issues in the real data (if there had been, we would have been using CMS encryption too). That said, the world has changed, and I see at least one other discuss asking for HTTPS, so I guess we'll be going down that path, but this time with no required linkage between CMS and HTTPS, and with the authentication (still) just based on CMS. From nobody Mon Jan 30 16:40:01 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76617129759; Mon, 30 Jan 2017 16:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 UJ2n3w0hNs7c; Mon, 30 Jan 2017 16:39:59 -0800 (PST) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E5B1129789; Mon, 30 Jan 2017 16:39:58 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 14628B97F; Tue, 31 Jan 2017 00:39:58 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 5D3914665264; Mon, 30 Jan 2017 19:39:21 -0500 (EST) Date: Mon, 30 Jan 2017 19:39:21 -0500 From: Rob Austein To: "Ben Campbell" In-Reply-To: <148477318982.2006.5926498434357117741.idtracker@ietfa.amsl.com> References: <148477318982.2006.5926498434357117741.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170131003921.5D3914665264@minas-ithil.hactrn.net> Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-publication@ietf.org Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-publication-10: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 00:40:00 -0000 At Wed, 18 Jan 2017 12:59:49 -0800, Ben Campbell wrote: ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Most of my comments have already been made by others. But with the > questions about upgrade paths, I see there is in fact a "version" element > defined. How is that expected to be used? I don't see a version related > error code. In the most straightforward implementation, wrong version would show up as a schema validation error. We could certainly add an error code for this if you prefer, just didn't think of it. From nobody Mon Jan 30 16:58:46 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B401297A8; Mon, 30 Jan 2017 16:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 Q3cEYDbUIzm9; Mon, 30 Jan 2017 16:58:44 -0800 (PST) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F1D1297A7; Mon, 30 Jan 2017 16:58:44 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id A5CA7B965; Tue, 31 Jan 2017 00:58:43 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 0669146654B0; Mon, 30 Jan 2017 19:58:07 -0500 (EST) Date: Mon, 30 Jan 2017 19:58:06 -0500 From: Rob Austein To: "Stephen Farrell" In-Reply-To: <148478450463.2001.14196919509991761982.idtracker@ietfa.amsl.com> References: <148478450463.2001.14196919509991761982.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170131005807.0669146654B0@minas-ithil.hactrn.net> Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-publication@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 00:58:45 -0000 At Wed, 18 Jan 2017 16:08:24 -0800, Stephen Farrell wrote: ... > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Why is sha-256 hardcoded? Real answer: because it's hard-coded in RFC 6486 and we were trying to use the same hashing algorithm for manifests, this, and RRDP (draft-ietf-sidr-delta-protocol). > You could easily include a hash alg-id even as an option and in > that way get algorithm agility, as called for by BCP201. (Or you > could use something like ni URIs but that's a bit of a self-serving > suggestion;-) Anyway, what's the plan for replacing sha-256 here? > (This is a bit of a subset of Alissa's discuss with which I agree.) > > One possible way to handle this here is to identify sha-256 as > the default hash algorithm but to re-define the ABNF for hash > to allow an alg-id of some sort to be included there. Or have > some generic versioning text somewhere that calls for a > version bump if sha-256 is not to be used. I had been assuming that an algorithm change would be a protocol version bump. Given that the server is probably storing these hashes in a database, changing the algorithm is probably a bit more involved than just changing the bits on the wire. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - general: I think a design that uses https with mutual auth > would have been better and easier. But given that this is > implemented and deployed, I guess it's too late for this one. The design goals included offline authentication for audit purposes, possibly years after the fact. That's hard to do with any sort of channel security mechanism, hence this approach. > - As with the oob spec, the xmlns values get me a 404. Don't think this is critical, but I can put up a vhost for this at some point if it will make people happier. > - section 6: I don't agree that CMS signed data means that > https is not needed. The latter provides confidentiality and > integrity and server auth which the former does not. And even > ignoring the security reasons, https is arguably much easier > to deploy and requires less development. And http is > vulnerable to middlebox messing (e.g. a client using http is > more likely to be forced to support cleartext proxy-auth > passwords). I would encourage you to encourage use of https > with server auth in addition to CMS signed data payloads. Er, the CMS signatures do provide integrity, I think. Having implemented both application code using both HTTPS and CMS as part of this project, I will have to respectfully disagree on relative difficulty of implementation. CMS is a format hairball, true, but it's all signed objects which can be signed and verified calmly at the implementation's convenience. TLS authentication tends to involve callbacks at awkward times, requiring one to make authentication decisions at a time chosen by somebody at the other end of a network connection, which can get pretty nasty. That said, I don't really object to HTTPS as a transport protocol, so long as we don't have to change the authentication mechanism. From nobody Mon Jan 30 17:02:39 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16D2129789; Mon, 30 Jan 2017 17:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 lDYJ1rRRb-pj; Mon, 30 Jan 2017 17:02:36 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C717E129784; Mon, 30 Jan 2017 17:02:36 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 627681398C; Tue, 31 Jan 2017 01:02:35 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id E32F74665502; Mon, 30 Jan 2017 20:01:57 -0500 (EST) Date: Mon, 30 Jan 2017 20:01:57 -0500 From: Rob Austein To: "Kathleen Moriarty" In-Reply-To: <148476342049.2020.11557954514441735216.idtracker@ietfa.amsl.com> References: <148476342049.2020.11557954514441735216.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170131010157.E32F74665502@minas-ithil.hactrn.net> Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-publication@ietf.org Subject: Re: [sidr] Kathleen Moriarty's No Objection on draft-ietf-sidr-publication-10: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 01:02:38 -0000 At Wed, 18 Jan 2017 10:17:00 -0800, Kathleen Moriarty wrote: ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > As for Alissa's comment on transport, more language added to the Security > Considerations section would be helpful to explain why the CMS signature > is sufficient. I am assuming that the only exposure would be to public > information during transport that is protected from tampering, unless I > missed something in reading the draft (I don't think you are transferring > private keys and didn't see that in the text). Correct, no private keys in flight here. Everything being transferred is a signed object intended for public consumption. Will try to come up with something for security considerations (I would say "suggestions welcome" but I think you just did...). From nobody Mon Jan 30 17:20:34 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF042127071; Mon, 30 Jan 2017 17:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.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_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham 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 cs_PM4ORssMu; Mon, 30 Jan 2017 17:20:26 -0800 (PST) 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 255D912009C; Mon, 30 Jan 2017 17:20:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 81026BE39; Tue, 31 Jan 2017 01:20:23 +0000 (GMT) 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 2PhYA1YzGOJq; Tue, 31 Jan 2017 01:20:22 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AD562BE2F; Tue, 31 Jan 2017 01:20:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485825622; bh=++SXkprU1BX0qVkGDUHNVR8JfjGt+Yiq+KXy1fWyKP4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Pqkjkn0Y9f40gLcrF1tG3zpEBDKpm7eM7ZaOdOQ5BKdZWabUkq98a5hamZCMklknR 2s5x7VuLB2z3QCwzLyS0A+TgJBlmvRCoRb0z7z1OHIJqL5fyRFCiT8DtACsiEAd00a /MjWWubHs55+uma7zNuuQpuAZLKWNZb/u5+n5dsE= To: Rob Austein References: <148478450463.2001.14196919509991761982.idtracker@ietfa.amsl.com> <20170131005807.0669146654B0@minas-ithil.hactrn.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 31 Jan 2017 01:20:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170131005807.0669146654B0@minas-ithil.hactrn.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060807000306010809070208" Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-publication@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 01:20:29 -0000 This is a cryptographically signed message in MIME format. --------------ms060807000306010809070208 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Rob, On 31/01/17 00:58, Rob Austein wrote: > At Wed, 18 Jan 2017 16:08:24 -0800, Stephen Farrell wrote: > ... >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> Why is sha-256 hardcoded? >=20 > Real answer: because it's hard-coded in RFC 6486 and we were trying to > use the same hashing algorithm for manifests, this, and RRDP > (draft-ietf-sidr-delta-protocol). Hmm. I don't see sha-256 mentioned in 6486 never mind hardcoded. Is there some indirection I'm missing? (But this may be moot, see below.) >=20 >> You could easily include a hash alg-id even as an option and in >> that way get algorithm agility, as called for by BCP201. (Or you >> could use something like ni URIs but that's a bit of a self-serving >> suggestion;-) Anyway, what's the plan for replacing sha-256 here? >> (This is a bit of a subset of Alissa's discuss with which I agree.) >> >> One possible way to handle this here is to identify sha-256 as >> the default hash algorithm but to re-define the ABNF for hash >> to allow an alg-id of some sort to be included there. Or have >> some generic versioning text somewhere that calls for a >> version bump if sha-256 is not to be used. >=20 > I had been assuming that an algorithm change would be a protocol > version bump. Given that the server is probably storing these hashes > in a database, changing the algorithm is probably a bit more involved > than just changing the bits on the wire. WRT clearing the discuss, if the draft said that then I'd be happy to clear. (Meaning that I don't care how the spec achieves alg. agility so long as it does somehow.) Cheers, S. PS: I'm happy to chat about stuff below, but no need if we don't need to:-) >=20 >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> - general: I think a design that uses https with mutual auth >> would have been better and easier. But given that this is >> implemented and deployed, I guess it's too late for this one. >=20 > The design goals included offline authentication for audit purposes, > possibly years after the fact. That's hard to do with any sort of > channel security mechanism, hence this approach. >=20 >> - As with the oob spec, the xmlns values get me a 404. >=20 > Don't think this is critical, but I can put up a vhost for this at > some point if it will make people happier. >=20 >> - section 6: I don't agree that CMS signed data means that >> https is not needed. The latter provides confidentiality and >> integrity and server auth which the former does not. And even >> ignoring the security reasons, https is arguably much easier >> to deploy and requires less development. And http is >> vulnerable to middlebox messing (e.g. a client using http is >> more likely to be forced to support cleartext proxy-auth >> passwords). I would encourage you to encourage use of https >> with server auth in addition to CMS signed data payloads. >=20 > Er, the CMS signatures do provide integrity, I think. >=20 > Having implemented both application code using both HTTPS and CMS as > part of this project, I will have to respectfully disagree on relative > difficulty of implementation. CMS is a format hairball, true, but > it's all signed objects which can be signed and verified calmly at the > implementation's convenience. TLS authentication tends to involve > callbacks at awkward times, requiring one to make authentication > decisions at a time chosen by somebody at the other end of a network > connection, which can get pretty nasty. >=20 > That said, I don't really object to HTTPS as a transport protocol, so > long as we don't have to change the authentication mechanism. >=20 --------------ms060807000306010809070208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMzEw MTIwMjFaMC8GCSqGSIb3DQEJBDEiBCA2ObgLl1SlJEv+4v5T6jB1Mhy3UkhUABezDwMVOM+h RzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAKlIrg/MtkBS7q7JnakP7m5XJtAhXr3nz89mnpAcLb9hOVuhNTEtFn BNcc9bP3sxcV/hKZuDhI9eNVqf/d5XTST0dQzVQ5O40AEqyzv6cS6p+3zIlXakFWW9gQ7geD DISqQJZiSIO7o0s0irwrInAJ0h7uVuRMzkJLuPJTnPlK3GHXOApMndW3zj6s/TPrWVwGsP/W fEpQuTsGFLQuPfYLiSqwNVdr+9j2MM3jr1QQiE1bk5Gmw/CJY7Aft9iLmTeaq7Pl9htLE3d7 Vndj3y3YwGOINwUqAU7MAGF2LCwpyjfUY+Ain7lNuL7PVI2qFwrat+Zb5SNIJimzmqRZbGdx AAAAAAAA --------------ms060807000306010809070208-- From nobody Mon Jan 30 17:46:54 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5458D12984F; Mon, 30 Jan 2017 17:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 htX4Ke39BjV3; Mon, 30 Jan 2017 17:46:47 -0800 (PST) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66095129854; Mon, 30 Jan 2017 17:46:47 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id B43C1B869; Tue, 31 Jan 2017 01:46:46 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 8D38D46658D5; Mon, 30 Jan 2017 20:46:09 -0500 (EST) Date: Mon, 30 Jan 2017 20:46:09 -0500 From: Rob Austein To: Stephen Farrell In-Reply-To: References: <148478450463.2001.14196919509991761982.idtracker@ietfa.amsl.com> <20170131005807.0669146654B0@minas-ithil.hactrn.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170131014609.8D38D46658D5@minas-ithil.hactrn.net> Archived-At: Cc: Rob Austein , Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-publication@ietf.org Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 01:46:48 -0000 At Tue, 31 Jan 2017 01:20:21 +0000, Stephen Farrell wrote: > > >> Why is sha-256 hardcoded? > > > > Real answer: because it's hard-coded in RFC 6486 and we were trying to > > use the same hashing algorithm for manifests, this, and RRDP > > (draft-ietf-sidr-delta-protocol). > > Hmm. I don't see sha-256 mentioned in 6486 never mind > hardcoded. Is there some indirection I'm missing? (But this > may be moot, see below.) OK, strictly speaking it's not hard coded in 6486, it's a reference to 6485. Works out to the same thing for practical purposes: sha-256 now, upgrade theoretically possible but likely to be somewhat painful. > > I had been assuming that an algorithm change would be a protocol > > version bump. Given that the server is probably storing these hashes > > in a database, changing the algorithm is probably a bit more involved > > than just changing the bits on the wire. > > WRT clearing the discuss, if the draft said that then I'd > be happy to clear. (Meaning that I don't care how the spec > achieves alg. agility so long as it does somehow.) Will do, thanks. From nobody Mon Jan 30 18:00:50 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA1812986E; Mon, 30 Jan 2017 18:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 4aexXwtA3I0v; Mon, 30 Jan 2017 18:00:41 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 3F5BF129849; Mon, 30 Jan 2017 18:00:41 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id s140so150208655qke.0; Mon, 30 Jan 2017 18:00:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uSAN4lWtWwqTVqBna0JG74RRQ3CQkZBiOfCTjXhRdH4=; b=io9cy7vPIINjG+kjppvNICA2rrL1KvIExI1BJd07uW9hBmLUBUnmRNOFOb35qIsk7/ QaK3E2OdBify9Fe+l2fQ99lPbjICXEO0giMde10/BK2WyceZNDAa/uIpDzAo5KaLsN5R V2eOBo5ry4gPPABTYIzaPJuvC2Dr27i+v22K6qNhJA6BShOovd5U/siKChg/Jdj3e9Wt Af4XgbxHlIsisVt/hOKsdYMOs6ocQU5MibhZpM91WXvO2kdiOyacEwBXU4hxeQeJflRh mRdOSeTiU+biYn92OyQTEV1i3cGIRMoyK6SXlw26/cjZPZz9SrjEXA/cQSGAQkefNCwv OMIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uSAN4lWtWwqTVqBna0JG74RRQ3CQkZBiOfCTjXhRdH4=; b=Mr1ro/Qkfe2bNBOQ0SkZwLSGnD0MKsjldOt4PZP8eERsFqKzQlRtrhNG9ugUycGi42 Awvzaye8wKICDFH66mC46r54aS5VQXj+031xeRcBb0WU6XBV+8cAqhMvCX4bDsyguLDR oXQ9QTFnKNM/AYiVQCFaFXncacCz7GhAifpiMrTRYhWat2esT8tj4R6BjnLqsy6oHMgX lcNV2YNJlbvA2o1edmbReOmYT2xlyZSdSEDaRZ7vHPI31a3qKSzGK1N94QUyK3Aim0lp Y1X2HAI4wd2svQskN4/tOv7fyTR5MwLYCkeQDdFdpdyQowQwcKHBDkx8sDNl25dJWJKT LTsA== X-Gm-Message-State: AIkVDXLjI7+kehNOAUG2AjsMMu1unXs2a/10dTaTUol0qBNluw3AFAno5Adb5WXqDiI6ibUGx/2qqoaY7tl3Xg== X-Received: by 10.55.81.194 with SMTP id f185mr24668798qkb.153.1485828040391; Mon, 30 Jan 2017 18:00:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Mon, 30 Jan 2017 18:00:39 -0800 (PST) In-Reply-To: <20170131010157.E32F74665502@minas-ithil.hactrn.net> References: <148476342049.2020.11557954514441735216.idtracker@ietfa.amsl.com> <20170131010157.E32F74665502@minas-ithil.hactrn.net> From: Kathleen Moriarty Date: Mon, 30 Jan 2017 21:00:39 -0500 Message-ID: To: Rob Austein Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Chris Morrow , sidr chairs , The IESG , sidr@ietf.org, draft-ietf-sidr-publication@ietf.org Subject: Re: [sidr] Kathleen Moriarty's No Objection on draft-ietf-sidr-publication-10: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 02:00:43 -0000 Hi Rob, On Mon, Jan 30, 2017 at 8:01 PM, Rob Austein wrote: > At Wed, 18 Jan 2017 10:17:00 -0800, Kathleen Moriarty wrote: > ... >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> As for Alissa's comment on transport, more language added to the Security >> Considerations section would be helpful to explain why the CMS signature >> is sufficient. I am assuming that the only exposure would be to public >> information during transport that is protected from tampering, unless I >> missed something in reading the draft (I don't think you are transferring >> private keys and didn't see that in the text). > > Correct, no private keys in flight here. Everything being transferred > is a signed object intended for public consumption. OK, my response here was tied to my text following that considered CA policies. Having run CAs and reviewed many policies, most are strict enough that I would think the session encryption would be mandated by policy assurance level. This would mean something like only those operating under a rudimentary assurance level might not have session encryption... but knowing where that line is drawn would be helpful. I believe Stephen put a discuss on this and I agree with that since I was making assumptions on the policy assurance requirements. If the assurance requirements cover the need for session encryption, that should be stated or a stronger requirement in this draft per Stephen's discuss. Thank you, Kathleen > > Will try to come up with something for security considerations (I > would say "suggestions welcome" but I think you just did...). -- Best regards, Kathleen From nobody Mon Jan 30 20:24:06 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61168129D8E; Mon, 30 Jan 2017 20:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 ie33E0oSPolM; Mon, 30 Jan 2017 20:24:03 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA51128B44; Mon, 30 Jan 2017 20:24:02 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 59F641398C; Tue, 31 Jan 2017 04:24:01 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 464A846665B4; Mon, 30 Jan 2017 23:23:23 -0500 (EST) Date: Mon, 30 Jan 2017 23:23:23 -0500 From: Rob Austein To: "Terry Manderson" In-Reply-To: <148472099055.32074.3466420839397217706.idtracker@ietfa.amsl.com> References: <148472099055.32074.3466420839397217706.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170131042323.464A846665B4@minas-ithil.hactrn.net> Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-publication@ietf.org Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 04:24:04 -0000 At Tue, 17 Jan 2017 22:29:50 -0800, Terry Manderson wrote: ... > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Looking at section 4, operational considerations I was expecting to see a > review of any considerations as to how this protocol works, the > interaction between the layers of HTTP, CMS, and XML and any > implementation differences/difficulties that exist between the 2 known > implementations. Interop report not written, would be a separate document in any case. Don't really understand what you were looking for with the rest of this, the layering is tedious but straightforward so don't really understand what "interactions" you thought would be described here. I am guessing that this part is not the substance of the DISCUSS. If there's something you really need us to do here, please explain. > Instead there is a discussion on laying out the > repository structure under the mandatory to implement _retrieval_ > mechanism (RSYNC) and the nuances of RSYNC itself. Yes. Taking it a piece at a time: - This is present in this document because in this protocol the CA engine explicitly specifies the rsync URI at which each object should be published. Thus, if there are considerations for what those URIs should be, this seemed like as good a place as we had for writing them down. - I could see a case that the WG should have written some entirely different document about URI structure, but, as you no doubt recall, this has always been a vexed subject, with a "structure matters for efficiency" camp and an "anybody who doesn't like the structure we picked can jump in a lake" camp. This is why none of the language in this section is normative: the WG never reached consensus (well, I don't think it did, ask a chair if you want an official opinion) on this, so we wrote down what we knew about the issue for people who want to try to do the efficient thing and left it at that. - The timing of all of this is a bit odd, since we are finally, with RRDP (draft-ietf-sidr-delta-protocol), hoping to get away from all this rsync madness, thereby we hope eventually rendering this entire topic moot. But we're not there yet, and rsync is still the mandatory to implement protocol. Now, given all that, I could see an argument for dropping this discussion out of sidr-publication on the grounds that it will be totally out of place if RRDP takes over. Would that be satisfactory? > This appears to be misplaced as the protocol (HTTP/CMS/XML) > interactions here are simply about publication from a certificate > authority operator to a repository operator, and in that space > surely the publication protocol (this doc) is agnostic to the exact > repo structure. Yes and no. Yes, but it's still the client who picks the URIs (subject to veto by the server, but if publication succeeds at all it's with a URI supplied by the client). > In both a database world (not a file based one) and where multiple RPKI > fetch mechanisms (rsync, http, torrent, etc ...) are used, how is the > exact URI meaningful for sidr-publication? At the moment, even a database-based server still has to enforce the rule that each object has a unique rsync URI. We expect that restriction to remain in place until rsync is declared irrelevant. From nobody Tue Jan 31 08:15:16 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAB21299AC; Tue, 31 Jan 2017 08:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=unavailable 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 wNQNWyF3BJAr; Tue, 31 Jan 2017 08:15:11 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9B93B129504; Tue, 31 Jan 2017 08:15:11 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v0VGF2Vj098277 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 31 Jan 2017 10:15:03 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Rob Austein" Date: Tue, 31 Jan 2017 10:15:03 -0600 Message-ID: <1B892C42-207B-446D-A1DD-7B4F39337806@nostrum.com> In-Reply-To: <20170131003921.5D3914665264@minas-ithil.hactrn.net> References: <148477318982.2006.5926498434357117741.idtracker@ietfa.amsl.com> <20170131003921.5D3914665264@minas-ithil.hactrn.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-publication@ietf.org Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-publication-10: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 16:15:12 -0000 On 30 Jan 2017, at 18:39, Rob Austein wrote: > At Wed, 18 Jan 2017 12:59:49 -0800, Ben Campbell wrote: > ... >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Most of my comments have already been made by others. But with the >> questions about upgrade paths, I see there is in fact a "version" >> element >> defined. How is that expected to be used? I don't see a version >> related >> error code. > > In the most straightforward implementation, wrong version would show > up as a schema validation error. Does that mean that the version element is not actually used? > > We could certainly add an error code for this if you prefer, just > didn't think of it. I think that's up to you (and the WG). The main thing I would like to see is some text talking about how versioning is expected to work, or at least how _this_ version should behave in version mismatch conditions. Whether or not it needs an error code probably depends on that text. Thanks! Ben. From nobody Tue Jan 31 18:44:47 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8881297C6; Tue, 31 Jan 2017 18:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 KiWNVGxI5PS7; Tue, 31 Jan 2017 18:44:39 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A22512953E; Tue, 31 Jan 2017 18:44:39 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 31 Jan 2017 18:44:36 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Tue, 31 Jan 2017 18:44:36 -0800 From: Terry Manderson To: Rob Austein Thread-Topic: Terry Manderson's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS) Thread-Index: AQHScVRH2KDA6djSb0i8Rnp4Z6wfEqFSlviAgAIeW4A= Date: Wed, 1 Feb 2017 02:44:36 +0000 Message-ID: References: <148472099055.32074.3466420839397217706.idtracker@ietfa.amsl.com> <20170131042323.464A846665B4@minas-ithil.hactrn.net> In-Reply-To: <20170131042323.464A846665B4@minas-ithil.hactrn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3568797873_1154370440" MIME-Version: 1.0 Archived-At: Cc: Chris Morrow , "sidr-chairs@ietf.org" , The IESG , "sidr@ietf.org" , "draft-ietf-sidr-publication@ietf.org" Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 02:44:41 -0000 --B_3568797873_1154370440 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Hi Rob, On 31/01/2017, 2:23 PM, "Rob Austein" wrote: At Tue, 17 Jan 2017 22:29:50 -0800, Terry Manderson wrote: ... > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Looking at section 4, operational considerations I was expecting to see a > review of any considerations as to how this protocol works, the > interaction between the layers of HTTP, CMS, and XML and any > implementation differences/difficulties that exist between the 2 known > implementations. Interop report not written, would be a separate document in any case. Don't really understand what you were looking for with the rest of this, the layering is tedious but straightforward so don't really understand what "interactions" you thought would be described here. The layering of XML, within CMS, within HTTP is certainly tedious. During interop and development did any situations arise where a failure at one level caused misinterpretation at another or left something in an unclear state? If not, then we can move past this. I am guessing that this part is not the substance of the DISCUSS. If there's something you really need us to do here, please explain. > Instead there is a discussion on laying out the > repository structure under the mandatory to implement _retrieval_ > mechanism (RSYNC) and the nuances of RSYNC itself. Yes. Taking it a piece at a time: - This is present in this document because in this protocol the CA engine explicitly specifies the rsync URI at which each object should be published. Thus, if there are considerations for what those URIs should be, this seemed like as good a place as we had for writing them down. - I could see a case that the WG should have written some entirely different document about URI structure, but, as you no doubt recall, this has always been a vexed subject, with a "structure matters for efficiency" camp and an "anybody who doesn't like the structure we picked can jump in a lake" camp. This is why none of the language in this section is normative: the WG never reached consensus (well, I don't think it did, ask a chair if you want an official opinion) on this, so we wrote down what we knew about the issue for people who want to try to do the efficient thing and left it at that. - The timing of all of this is a bit odd, since we are finally, with RRDP (draft-ietf-sidr-delta-protocol), hoping to get away from all this rsync madness, thereby we hope eventually rendering this entire topic moot. But we're not there yet, and rsync is still the mandatory to implement protocol. Now, given all that, I could see an argument for dropping this discussion out of sidr-publication on the grounds that it will be totally out of place if RRDP takes over. Would that be satisfactory? Thank you for the summation. I feel that the discussion is out of place in this document, given the WG has never really reached consensus on the topic AND that RRDP will supersede this concern anyway. Yes. Please cut the text from this Document. > This appears to be misplaced as the protocol (HTTP/CMS/XML) > interactions here are simply about publication from a certificate > authority operator to a repository operator, and in that space > surely the publication protocol (this doc) is agnostic to the exact > repo structure. Yes and no. Yes, but it's still the client who picks the URIs (subject to veto by the server, but if publication succeeds at all it's with a URI supplied by the client). Right, which is the tango held in sidr-oob-setup-06 where both parties agree to the URI. > In both a database world (not a file based one) and where multiple RPKI > fetch mechanisms (rsync, http, torrent, etc ...) are used, how is the > exact URI meaningful for sidr-publication? At the moment, even a database-based server still has to enforce the rule that each object has a unique rsync URI. We expect that restriction to remain in place until rsync is declared irrelevant. Thanks Terry --B_3568797873_1154370440 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFMyk NGWvLx5/6hQsaAaaMJVhJIXoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE3MDIwMTAyNDQzM1owDQYJKoZIhvcNAQEBBQAEggEAF/QVpfpOraWoEMragGFZ nu5TK48XiR9Vi66gRQWLxQMH4l5EGLClGj0NBlffm3/gbZgPrQHrCoFlQ0OE5UcuJN5nfhH/ 07MWwje2HgY4M5dg+1Wm2SeV3DphxYXX3bYNrTcRgsBvQ5hv7AbVCRUYmwHZsKtOaTdY80rF I+DRFLjnzAEF0vt8qZXTkS3m1n7zGtOg3cWs0GSc9gfKsqDZEfNf5eB9FdC1e/5QrqAtiT4y EKz6Qb6iIPSIZqC9Em12AzF/MgpG952Orqb4DDmbSN6SXbfsOGaXztmkdd+bsPGuUZkqo1Zp 9Ivq4trJRSFVI08k9zAZXTbg1k2NShNSMg== --B_3568797873_1154370440-- From nobody Tue Jan 31 20:23:57 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FBD129C7D; Tue, 31 Jan 2017 20:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 29h9ZFc-EVwp; Tue, 31 Jan 2017 20:23:51 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27053129C7B; Tue, 31 Jan 2017 20:23:51 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 9E56F139A3; Wed, 1 Feb 2017 04:23:49 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 42A1C466B729; Tue, 31 Jan 2017 23:23:06 -0500 (EST) Date: Tue, 31 Jan 2017 23:23:06 -0500 From: Rob Austein To: Terry Manderson In-Reply-To: References: <148472099055.32074.3466420839397217706.idtracker@ietfa.amsl.com> <20170131042323.464A846665B4@minas-ithil.hactrn.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170201042306.42A1C466B729@minas-ithil.hactrn.net> Archived-At: Cc: Rob Austein , Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-publication@ietf.org Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 04:23:52 -0000 At Wed, 1 Feb 2017 02:44:36 +0000, Terry Manderson wrote: ... > The layering of XML, within CMS, within HTTP is certainly tedious. Agreed, but...copied from RFC 6492, trying not to reinvent wheels. > During interop and development did any situations arise where a > failure at one level caused misinterpretation at another or left > something in an unclear state? Not that I recall. Fairly high degree of code reuse from RFC 6492. ... > Now, given all that, I could see an argument for dropping this > discussion out of sidr-publication on the grounds that it will be > totally out of place if RRDP takes over. Would that be satisfactory? ... > Yes. Please cut the text from this Document. (Will be) gone in -11. Thanks! From nobody Tue Jan 31 20:29:00 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DE6129C7E; Tue, 31 Jan 2017 20:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 fLOhHpy1RZNu; Tue, 31 Jan 2017 20:28:57 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [IPv6:2001:418:8006::30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87635129C61; Tue, 31 Jan 2017 20:28:57 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id D3D9D13992; Wed, 1 Feb 2017 04:28:56 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id AF8B7466B7B2; Tue, 31 Jan 2017 23:28:14 -0500 (EST) Date: Tue, 31 Jan 2017 23:28:14 -0500 From: Rob Austein To: "Ben Campbell" In-Reply-To: <1B892C42-207B-446D-A1DD-7B4F39337806@nostrum.com> References: <148477318982.2006.5926498434357117741.idtracker@ietfa.amsl.com> <20170131003921.5D3914665264@minas-ithil.hactrn.net> <1B892C42-207B-446D-A1DD-7B4F39337806@nostrum.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170201042814.AF8B7466B7B2@minas-ithil.hactrn.net> Archived-At: Cc: Rob Austein , Chris Morrow , sidr-chairs@ietf.org, The IESG , sidr@ietf.org, draft-ietf-sidr-publication@ietf.org Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-publication-10: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 04:28:59 -0000 At Tue, 31 Jan 2017 10:15:03 -0600, Ben Campbell wrote: > On 30 Jan 2017, at 18:39, Rob Austein wrote: ... > > In the most straightforward implementation, wrong version would show > > up as a schema validation error. > > Does that mean that the version element is not actually used? No, the version attribute is required to be present. It's just that, at the moment, there's only one value it's allowed to have. > > We could certainly add an error code for this if you prefer, just > > didn't think of it. > > I think that's up to you (and the WG). The main thing I would like to > see is some text talking about how versioning is expected to work, or at > least how _this_ version should behave in version mismatch conditions. > Whether or not it needs an error code probably depends on that text. OK, will add something about that to -11. From nobody Tue Jan 31 22:03:14 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE7D12975C; Tue, 31 Jan 2017 22:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 Hpy7-ksaIb_3; Tue, 31 Jan 2017 22:03:07 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D321293FE; Tue, 31 Jan 2017 22:03:07 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 31 Jan 2017 22:03:05 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Tue, 31 Jan 2017 22:03:04 -0800 From: Terry Manderson To: Rob Austein Thread-Topic: Terry Manderson's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS) Thread-Index: AQHScVRH2KDA6djSb0i8Rnp4Z6wfEqFSlviAgAIeW4D//3PmAIAAw5CA Date: Wed, 1 Feb 2017 06:03:04 +0000 Message-ID: References: <148472099055.32074.3466420839397217706.idtracker@ietfa.amsl.com> <20170131042323.464A846665B4@minas-ithil.hactrn.net> <20170201042306.42A1C466B729@minas-ithil.hactrn.net> In-Reply-To: <20170201042306.42A1C466B729@minas-ithil.hactrn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3568809783_430836394" MIME-Version: 1.0 Archived-At: Cc: Chris Morrow , "sidr-chairs@ietf.org" , The IESG , "sidr@ietf.org" , "draft-ietf-sidr-publication@ietf.org" Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 06:03:09 -0000 --B_3568809783_430836394 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit No, Thank you! I will clear my DISCUSS when -11 is posted. Cheers Terry On 1/02/2017, 2:23 PM, "iesg on behalf of Rob Austein" wrote: At Wed, 1 Feb 2017 02:44:36 +0000, Terry Manderson wrote: ... > The layering of XML, within CMS, within HTTP is certainly tedious. Agreed, but...copied from RFC 6492, trying not to reinvent wheels. > During interop and development did any situations arise where a > failure at one level caused misinterpretation at another or left > something in an unclear state? Not that I recall. Fairly high degree of code reuse from RFC 6492. ... > Now, given all that, I could see an argument for dropping this > discussion out of sidr-publication on the grounds that it will be > totally out of place if RRDP takes over. Would that be satisfactory? ... > Yes. Please cut the text from this Document. (Will be) gone in -11. Thanks! --B_3568809783_430836394 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFLQI tN781npTWztz+D9mDNsHMPD4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE3MDIwMTA2MDMwM1owDQYJKoZIhvcNAQEBBQAEggEArnMPzhIA8SdIvR1XWHZF Hs3UU2lehkv+wmDJP3iLBX2ImWDR54bHZb+UG2+pAWFJoWBNNPzERmkXUAuYZz7HEX0Fiwr7 Dn8wJxReUPtBL7F0+bkDh6b1Uym5dv3Q+yjJuHrYz1haJMya/DqxZhBvSm2CJWf7Ufv18kxd bvpBMNCwMOBUHWYrxj6PSwPVMPZSj/PmKmnwRrV0kFxJCYmT/0qbwWUIGZsWmsni5drobsH6 8YCsjtmxu6it/qxQ8ooDUaAnvb2uMn/hHqd1YXMVqzyrwaBhs5798XvxQN21Q6cRSvhEVOJa 8DZJKqFyuVvwZPvFsoDc/i/AA8jrjwRxUg== --B_3568809783_430836394--