From nobody Thu Jun 1 06:59: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 CC1EA1277BB for ; Thu, 1 Jun 2017 06:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zdns.cn 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 jC5-u4mW1WcZ for ; Thu, 1 Jun 2017 06:59:35 -0700 (PDT) Received: from mail.zdns.cn (mail.knet.cn [202.173.10.13]) (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 F0AAB120727 for ; Thu, 1 Jun 2017 06:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zdns.cn; s=dkim; x=1496930375; i=madi@zdns.cn; h=Content-Type: Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; bh=65blwuIIk r1NItNXrxMdkQBnzinCvUVFcEngn/H6wW0=; b=QNS1dyWZTaAAvTME4QvChKU5b X7KQbHKLocHNP13GjLZ9ipQowT74OfRcHZRRuOTY7GHhYK95BVfs0iqg8gfWWUav kfAkDGaa5kSgsIP0SZhPdCdTKe7UTvfNp0VYkgl2NT+L0lApaWLYCRyajs/frCz4 n4C1M7mWTi+AgSMfJo= X-TM-DID: 2997fee94ad879592fbac2cd24591996 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Declan Ma In-Reply-To: <457EED60-10C5-4445-AD63-6916A1738484@gmail.com> Date: Thu, 1 Jun 2017 21:59:12 +0800 Cc: sidrops@ietf.org, sidr wg list Content-Transfer-Encoding: quoted-printable Message-Id: <82EE6F8D-2924-4201-85E4-5CF359F28F8F@zdns.cn> References: <457EED60-10C5-4445-AD63-6916A1738484@gmail.com> To: "Carlos M. Martinez" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sidr] [Sidrops] RPSTIR updated X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 13:59:37 -0000 Carlos, Thank you for giving it a try. Your feedback will make RPSTIR a better work.=20 Declan(Di) Ma > =D4=DA 2017=C4=EA5=D4=C230=C8=D5=A3=AC10:01=A3=ACCarlos M. Martinez = =D0=B4=B5=C0=A3=BA >=20 > Thanks ! I=A1=AFll give it a try. >=20 > On 25 Mar 2017, at 4:09, Declan Ma wrote: >=20 >> Hi, folks, >>=20 >> We RPSTIR team just had the very software updated to support the = algorithm specified by Validation Reconsidered = (draft-ietf-sidr-rpki-validation-reconsidered-07) . >>=20 >> Given the SIDR WG has not reach the agreement whether and how new = OIDs should be employed, this release, for the time being, is counting = on the old OIDs. >>=20 >> And we will shift into new OIDs accordingly once the IETF has come = into a conclusion about that. >>=20 >> Welcome to have a try on this new version of RPSTIR. >>=20 >> We would appreciate your feedbacks. >>=20 >> https://github.com/bgpsecurity/rpstir/releases >>=20 >>=20 >>=20 >> Declan(Di) Ma >>=20 >> ZDNS >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Jun 15 08:02: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 0076312946F; Thu, 15 Jun 2017 08:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 vFzpMhDinMKs; Thu, 15 Jun 2017 08:02:19 -0700 (PDT) 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 5E4C6128B93; Thu, 15 Jun 2017 08:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16982; q=dns/txt; s=iport; t=1497538939; x=1498748539; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gUmxHRxoI+/9usCd5O3pmKJkWWODMsAL5Hhvjr0ju8A=; b=kc3t9c4SLeNnWCaE3R6gdPpUmn2csE8g7us9uOZTLNPsFdjvt/EQZH7Y RmxxgBXaA93oQdFbcNZaa40pAeqrtCOObpW6Zb3B+vbWDRAlU6CvSOKv6 RseCwWuJ9UktRcIicKr/xTH2EG7sm9c2G89TVqjpUmH6yyI5qy3MhK6Ue E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAQB5oEJZ/5pdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm88LWKBDQeDb4oYkVWQb4U6ghGCboM2AhqCRT8YAQIBAQEBAQEBax0?= =?us-ascii?q?LhRkGI1YQAgEIPwMCAgIwFBECBA4FiUhkqlKCJiuLGAEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2GYoFgKwuBYIEMhEaDNjCCMQWXDoc7ApNTkguUfgEfOIEKdBVbAYR?= =?us-ascii?q?6HIFmdocTAiQHgQWBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,343,1493683200"; d="scan'208,217";a="261229023" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2017 15:02:18 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v5FF2IIb015937 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Jun 2017 15:02: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; Thu, 15 Jun 2017 10:02:17 -0500 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, 15 Jun 2017 10:02:17 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" CC: "sidr-chairs@ietf.org" , "sidr@ietf.org" , Tim Bruijnzeels , Chris Morrow Thread-Topic: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07 Thread-Index: AQHSmQVAKIoRRn/RNUKU0uFv8zRBd6GQn0+AgAE/doCAAMXagIAAPSwAgABKFgCAAtHPgICRFmCA Date: Thu, 15 Jun 2017 15:02:17 +0000 Message-ID: References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> <20170311222527.324125ACF21@minas-ithil.hactrn.net> <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> <68C71545-48E4-40B8-91AC-88DE44C4125D@ripe.net> <8C26566E-8E22-4D35-85E1-387BA980115E@ripe.net> In-Reply-To: <8C26566E-8E22-4D35-85E1-387BA980115E@ripe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.66.78] Content-Type: multipart/alternative; boundary="_000_C1D1FDD298924EE086FF24F412AF6669ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 15:02:22 -0000 --_000_C1D1FDD298924EE086FF24F412AF6669ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhdXRob3JzOg0KDQpIaSENCg0KSXTigJlzIGJlZW4gMyBtb250aHMgc2luY2UgdGhpcyBl LW1haWwsIHdoaWNoIHdhcyB0aGUgbGFzdCBvZiB0aGUgdGhyZWFkIHN0YXJ0ZWQgZnJvbSBteSBy ZXZpZXcuDQoNCkkgYW0gZXhwZWN0aW5nIGEgcmV2aXNlZCBJRCDigJMgd2hhdCBhcmUgdGhlIHBs YW5zIHRvIG1vdmUgZm9yd2FyZD8NCg0KVGhhbmtzIQ0KDQpBbHZhcm8uDQoNCg0KDQpPbiAzLzE1 LzE3LCAxMDoyNCBBTSwgInNpZHIgb24gYmVoYWxmIG9mIFRpbSBCcnVpam56ZWVscyIgPHNpZHIt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lkci1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYg b2YgdGltQHJpcGUubmV0PG1haWx0bzp0aW1AcmlwZS5uZXQ+PiB3cm90ZToNCg0KSGkgQ2hyaXMs DQoNCk9uIDEzIE1hciAyMDE3LCBhdCAxNToyMSwgQ2hyaXMgTW9ycm93IDxtb3Jyb3djQG9wcy1u ZXRtYW4ubmV0PG1haWx0bzptb3Jyb3djQG9wcy1uZXRtYW4ubmV0Pj4gd3JvdGU6DQoNCmJ1dCwg aGF2aW5nIDIgdmVyc2lvbnMgb2YgdGhlIHZhbGlkYXRpb24NCmFsZ29yaXRobSBhbmQgc2VlaW5n IHB1Ymxpc2hlZCBkYXRhIGZvciBib3RoIE9JRCBzZXRzIGZvciBhIHNpbmdsZQ0KcHJlZml4L3B1 YmxpY2F0aW9uIGJ1bmRsZSB3aWxsIGJlIHZlcnkgcHJvYmxlbWF0aWMuIFRoZXJlJ3Mgbm8NCnBy b3NjcmliZWQgJ3ByZWZlciBuZXcgb3ZlciBvbGQnIGFjdGlvbiBoZXJlLCBzbyBhIENBIG11c3Qg b25seQ0KcHVibGlzaCBvbmUgdmVyc2lvbiBvZiB0aGVpciBkYXRhLg0KDQpXaHkgaXMgdGhpcyBh IHByb2JsZW0sIHJlYWxseT8NCg0KVGhlIE9JRHMgYXJlIHNldCBvbiBhIHBlciBjZXJ0aWZpY2F0 ZSBiYXNpcyBieSB0aGUgaXNzdWluZyBDQS4gRldJVywgaW4gb3VyIGhvc3RlZCBzZXQgdXAgd2Ug KndpbGwqIGJlIGFibGUgdG8gcHJvLWFjdGl2ZWx5IHJlLWlzc3VlIGV2ZXJ5dGhpbmcgdXNpbmcg dGhlIG5ldyBPSURzIHdpdGhvdXQgdXNlciBpbnRlcmFjdGlvbiwgYnV0IHRoZXJlIGFyZSBjYXNl cyBpbiBob3N0ZWQgQ0EgZGVwbG95bWVudHMgd2hlcmUgYSBob3N0ZWQgQ0EgY2FuIGF1dG9tYXRp Y2FsbHkgcmUtaXNzdWUgbWFuaWZlc3RzLCBidXQgUk9BcyBjYW4gb25seSBiZSByZS1pc3N1ZWQg YnkgZXhwbGljaXQgdXNlciByZXF1ZXN0LCBvbmUgYnkgb25lLg0KDQpTbyB3ZSBtYXkgc2VlIGhv c3RlZCBDQXMgd2l0aCBwcm9kdWN0cyBsaWtlIHRoaXM6DQoNCjEgQ1JMICh2YWxpZGF0aW9uIGFs Z29yaXRobSBkb2VzIG5vdCBhcHBseSkNCjEgTUZUIChuZXcgdmFsaWRhdGlvbiwgYWx0aG91Z2gg aXQgd29uJ3QgbWF0dGVyIGJlY2F1c2UgaW5oZXJpdCBpcyB1c2VkKQ0KMSBST0Egd2l0aCBuZXcg dmFsaWRhdGlvbiAod2hpY2ggaGFzIGJlZW4gcmUtaXNzdWVkIGJ5IHRoZSB1c2VyKQ0KMSBST0Eg d2l0aCBvbGQgdmFsaWRhdGlvbiAod2hpY2ggaGFzIE5PVCB5ZXQgYmVlbiByZS1pc3N1ZWQpDQoN ClRoaXMgbWlnaHQgc2VlbSBjb25mdXNpbmcsIGJ1dCBzaW5jZSB0aGUgT0lEcyBtYWtlIGl0IHZl cnkgZXhwbGljaXQgd2hpY2ggYWxnb3JpdGhtIHRoZSBDQSBpbnRlbmRlZCB0byB1c2UsIEkgcmVh bGx5IGRvIG5vdCBzZWUgYW55IGFtYmlndWl0eSBoZXJlLg0KDQpNeSBtYWluIGNvbmNlcm4gaXMg dGhhdCB3ZSBuZWVkIHRvIGJlIHF1aXRlIGNvbmZpZGVudCB0aGF0IG5ldyBSUCBjb2RlIHRoYXQg dW5kZXJzdGFuZHMgdGhlIG5ldyBPSURzIGhhcyBiZWVuIGF2YWlsYWJsZSBhbmQgaXMgZGVwbG95 ZWQuIEJlY2F1c2Ugb2xkIFJQcyB3aWxsIHJlamVjdCBFVkVSWVRISU5HIG9uY2UgQ0FzIHN0YXJ0 IHVzaW5nIHRoZSBuZXcgT0lEcy4NCg0KVGhhdCBpcyB3aHkgSSB3b3VsZCBoYXZlIHByZWZlcnJl ZCB0byBub3QgbmVlZCBuZXcgT0lEcywgYW5kIGp1c3QgYWdyZWUgb24gYSBkYXkgdGhhdCB0aGUg bmV3IGFsZ29yaXRobSBzaG91bGQgYmUgcHJlZmVycmVkLiBSb2Igc2VlbXMgYWRhbWFudCB0aGF0 IHRoZSBSRkMzNzc5IGV4dGVuc2lvbiBsaWJyYXJ5IGNvZGUgZG9lcyBub3QgaGF2ZSBhY2Nlc3Mg dG8gdGhlIGNvbnRleHQgb2YgdGhlIGZ1bGwgY2VydGlmaWNhdGUgd2l0aCB0aGUgUlBLSSBDUCBP SUQgLSBzbyB0aGVyZSBpcyBubyB3YXkgdG8gaGF2ZSBzb21ldGhpbmcgbGlrZToNCg0KaWYgKEZV TEwgY2VydGlmaWNhdGUgaGFzIFJQS0kgQ1AgT0lEICYmIERhdGUgaXMgYWZ0ZXIgJ3N3aXRjaCcg ZGF5KSB7DQogIGRvIE5FVyBvbiBSRkMzNzc5IGV4dGVuc2lvbg0KfSBlbHNlIHsNCiAgZG8gT0xE IG9uIFJGQzM3NzkgZXh0ZW5zaW9uDQp9DQoNClRoZSBpbXBhY3Qgb2YgUlAgc29mdHdhcmUgbm90 IHVzaW5nIHRoZSBuZXcgbGlicmFyeSBvbiAnc3dpdGNoJyBkYXkgaXMgZmFpcmx5IGxpbWl0ZWQu IFRoZXkgd291bGQgbm90IHJlamVjdCB0aGUgZnVsbCByZXBvc2l0b3J5LCBidXQgb25seSByZWpl Y3QgdGhlIGV4Y2VwdGlvbmFsIGNhc2VzIHdoZXJlIGNlcnRpZmljYXRlcyBBUkUgb3Zlci1jbGFp bWluZy4gQW5kIG9mIGNvdXJzZSB0aGUgZGF0ZSBjaGVjayBjYW4gYmUgcmVtb3ZlZCBpbiByZWxl YXNlcyBvZiB0aGUgbGlicmFyeSBhZnRlciAnc3dpdGNoJyBkYXkuLg0KDQpJdCBzZWVtcyB0byBt ZSB0aGF0IHRoaXMgaXMgYSBkZXNpZ24gaXNzdWUgd2l0aCBPcGVuU1NMIGl0c2VsZiwgYnV0IGJl IHRoYXQgYXMgaXQgbWF5IC0gaXQgbWF5IGJlIHVuc3VybW91bnRhYmxlLiBSb2Iga25vd3MgdGhp cyBjb2RlIG11Y2ggYmV0dGVyIHRoYW4gSSBkby4NCg0KU3RpbGwgdGhlIGNvbnNlcXVlbmNlIG9m IGFsbCB0aGlzIGlzIGlzIHRoYXQgd2Ugd2lsbCBoYXZlIHRvIGhhdmUgYSBtaXgsIGFuZCB0aGF0 IGRlc3BpdGUgb3VyIGJlc3QgZWZmb3J0cyB0byB3YXJuIGV2ZXJ5b25lIHRvIHVwZ3JhZGUgdGhl aXIgUlAgc29mdHdhcmUgSSBleHBlY3QgdGhhdCB3ZSBXSUxMIHNlZSBhIG51bWJlciBvZiBvcGVy YXRvcnMgdGhhdCBzdWRkZW5seSBmaW5kIHRoYXQgdGhlaXIgb2xkIFJQIHNvZnR3YXJlIGhhcyBy ZWplY3Qgb3VyIGZ1bGwgcmVwb3NpdG9yeSB3aGVuIHN0YXJ0IHVzaW5nIHRoZSBuZXcgT0lEcy4N Cg0KSWYgaXQgY2FuJ3QgYmUgYXZvaWRlZCB0aGFuIHNvIGJlIGl0LCBidXQgSSBiZWxpZXZlIHRo aXMgcGVyc3BlY3RpdmUgc2hvdWxkIGJlIGNvbnNpZGVyZWQgYXMgd2VsbC4NCg0KDQoNCkNoZWVy cw0KDQpUaW0NCg0KDQoNCg== --_000_C1D1FDD298924EE086FF24F412AF6669ciscocom_ 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 eTpNb25hY287DQoJcGFub3NlLTE6MiAwIDUgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250 LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPkRlYXIgYXV0aG9yczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5IaSE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj5JdOKAmXMgYmVlbiAzIG1vbnRocyBzaW5jZSB0aGlzIGUtbWFp bCwgd2hpY2ggd2FzIHRoZSBsYXN0IG9mIHRoZSB0aHJlYWQgc3RhcnRlZCBmcm9tIG15IHJldmll dy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5JIGFtIGV4cGVjdGluZyBhIHJldmlzZWQgSUQg 4oCTIHdoYXQgYXJlIHRoZSBwbGFucyB0byBtb3ZlIGZvcndhcmQ/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+VGhhbmtzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkFsdmFyby48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIDMvMTUvMTcsIDEwOjI0IEFNLCAmcXVvdDtzaWRyIG9uIGJlaGFs ZiBvZiBUaW0gQnJ1aWpuemVlbHMmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzaWRyLWJvdW5j ZXNAaWV0Zi5vcmciPnNpZHItYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBo cmVmPSJtYWlsdG86dGltQHJpcGUubmV0Ij50aW1AcmlwZS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIENo cmlzLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAx MyBNYXIgMjAxNywgYXQgMTU6MjEsIENocmlzIE1vcnJvdyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1v cnJvd2NAb3BzLW5ldG1hbi5uZXQiPm1vcnJvd2NAb3BzLW5ldG1hbi5uZXQ8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNb25hY28iPmJ1dCwgaGF2aW5nIDIgdmVyc2lvbnMg b2YgdGhlIHZhbGlkYXRpb248YnI+DQphbGdvcml0aG0gYW5kIHNlZWluZyBwdWJsaXNoZWQgZGF0 YSBmb3IgYm90aCBPSUQgc2V0cyBmb3IgYSBzaW5nbGU8YnI+DQpwcmVmaXgvcHVibGljYXRpb24g YnVuZGxlIHdpbGwgYmUgdmVyeSBwcm9ibGVtYXRpYy4gVGhlcmUncyBubzxicj4NCnByb3Njcmli ZWQgJ3ByZWZlciBuZXcgb3ZlciBvbGQnIGFjdGlvbiBoZXJlLCBzbyBhIENBIG11c3Qgb25seTxi cj4NCnB1Ymxpc2ggb25lIHZlcnNpb24gb2YgdGhlaXIgZGF0YS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2h5IGlz IHRoaXMgYSBwcm9ibGVtLCByZWFsbHk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBPSURzIGFyZSBzZXQgb24gYSBwZXIgY2VydGlmaWNh dGUgYmFzaXMgYnkgdGhlIGlzc3VpbmcgQ0EuIEZXSVcsIGluIG91ciBob3N0ZWQgc2V0IHVwIHdl ICp3aWxsKiBiZSBhYmxlIHRvIHByby1hY3RpdmVseSByZS1pc3N1ZSBldmVyeXRoaW5nIHVzaW5n IHRoZSBuZXcgT0lEcyB3aXRob3V0IHVzZXIgaW50ZXJhY3Rpb24sIGJ1dCB0aGVyZSBhcmUgY2Fz ZXMgaW4gaG9zdGVkIENBIGRlcGxveW1lbnRzIHdoZXJlDQogYSBob3N0ZWQgQ0EgY2FuIGF1dG9t YXRpY2FsbHkgcmUtaXNzdWUgbWFuaWZlc3RzLCBidXQgUk9BcyBjYW4gb25seSBiZSByZS1pc3N1 ZWQgYnkgZXhwbGljaXQgdXNlciByZXF1ZXN0LCBvbmUgYnkgb25lLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB3ZSBtYXkgc2VlIGhvc3Rl ZCBDQXMgd2l0aCBwcm9kdWN0cyBsaWtlIHRoaXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEgQ1JMICh2YWxpZGF0aW9uIGFsZ29yaXRobSBk b2VzIG5vdCBhcHBseSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjEgTUZUIChuZXcgdmFsaWRhdGlvbiwgYWx0aG91Z2ggaXQgd29uJ3QgbWF0dGVy IGJlY2F1c2UgaW5oZXJpdCBpcyB1c2VkKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+MSBST0Egd2l0aCBuZXcgdmFsaWRhdGlvbiAod2hpY2ggaGFz IGJlZW4gcmUtaXNzdWVkIGJ5IHRoZSB1c2VyKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSBST0Egd2l0aCBvbGQgdmFsaWRhdGlvbiAod2hpY2gg aGFzIE5PVCB5ZXQgYmVlbiByZS1pc3N1ZWQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgbWlnaHQgc2VlbSBjb25mdXNpbmcsIGJ1dCBz aW5jZSB0aGUgT0lEcyBtYWtlIGl0IHZlcnkgZXhwbGljaXQgd2hpY2ggYWxnb3JpdGhtIHRoZSBD QSBpbnRlbmRlZCB0byB1c2UsIEkgcmVhbGx5IGRvIG5vdCBzZWUgYW55IGFtYmlndWl0eSBoZXJl LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N eSBtYWluIGNvbmNlcm4gaXMgdGhhdCB3ZSBuZWVkIHRvIGJlIHF1aXRlIGNvbmZpZGVudCB0aGF0 IG5ldyBSUCBjb2RlIHRoYXQgdW5kZXJzdGFuZHMgdGhlIG5ldyBPSURzIGhhcyBiZWVuIGF2YWls YWJsZSBhbmQgaXMgZGVwbG95ZWQuIEJlY2F1c2Ugb2xkIFJQcyB3aWxsIHJlamVjdCBFVkVSWVRI SU5HIG9uY2UgQ0FzIHN0YXJ0IHVzaW5nIHRoZSBuZXcgT0lEcy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBpcyB3aHkgSSB3b3VsZCBo YXZlIHByZWZlcnJlZCB0byBub3QgbmVlZCBuZXcgT0lEcywgYW5kIGp1c3QgYWdyZWUgb24gYSBk YXkgdGhhdCB0aGUgbmV3IGFsZ29yaXRobSBzaG91bGQgYmUgcHJlZmVycmVkLiBSb2Igc2VlbXMg YWRhbWFudCB0aGF0IHRoZSBSRkMzNzc5IGV4dGVuc2lvbiBsaWJyYXJ5IGNvZGUgZG9lcyBub3Qg aGF2ZSBhY2Nlc3MgdG8gdGhlIGNvbnRleHQgb2YgdGhlIGZ1bGwgY2VydGlmaWNhdGUNCiB3aXRo IHRoZSBSUEtJIENQIE9JRCAtIHNvIHRoZXJlIGlzIG5vIHdheSB0byBoYXZlIHNvbWV0aGluZyBs aWtlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5pZiAoRlVMTCBjZXJ0aWZpY2F0ZSBoYXMgUlBLSSBDUCBPSUQgJmFtcDsmYW1wOyBEYXRlIGlz IGFmdGVyICdzd2l0Y2gnIGRheSkgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IGRvIE5FVyBvbiBSRkMzNzc5IGV4dGVuc2lvbjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+fSBlbHNlIHs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyBkbyBPTEQgb24gUkZDMzc3OSBleHRlbnNpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPn08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGltcGFjdCBvZiBSUCBzb2Z0d2FyZSBub3QgdXNp bmcgdGhlIG5ldyBsaWJyYXJ5IG9uICdzd2l0Y2gnIGRheSBpcyBmYWlybHkgbGltaXRlZC4gVGhl eSB3b3VsZCBub3QgcmVqZWN0IHRoZSBmdWxsIHJlcG9zaXRvcnksIGJ1dCBvbmx5IHJlamVjdCB0 aGUgZXhjZXB0aW9uYWwgY2FzZXMgd2hlcmUgY2VydGlmaWNhdGVzIEFSRSBvdmVyLWNsYWltaW5n LiBBbmQgb2YgY291cnNlIHRoZSBkYXRlIGNoZWNrIGNhbg0KIGJlIHJlbW92ZWQgaW4gcmVsZWFz ZXMgb2YgdGhlIGxpYnJhcnkgYWZ0ZXIgJ3N3aXRjaCcgZGF5Li48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgc2VlbXMgdG8gbWUgdGhhdCB0 aGlzIGlzIGEgZGVzaWduIGlzc3VlIHdpdGggT3BlblNTTCBpdHNlbGYsIGJ1dCBiZSB0aGF0IGFz IGl0IG1heSAtIGl0IG1heSBiZSB1bnN1cm1vdW50YWJsZS4gUm9iIGtub3dzIHRoaXMgY29kZSBt dWNoIGJldHRlciB0aGFuIEkgZG8uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlN0aWxsIHRoZSBjb25zZXF1ZW5jZSBvZiBhbGwgdGhpcyBpcyBp cyB0aGF0IHdlIHdpbGwgaGF2ZSB0byBoYXZlIGEgbWl4LCBhbmQgdGhhdCBkZXNwaXRlIG91ciBi ZXN0IGVmZm9ydHMgdG8gd2FybiBldmVyeW9uZSB0byB1cGdyYWRlIHRoZWlyIFJQIHNvZnR3YXJl IEkgZXhwZWN0IHRoYXQgd2UgV0lMTCBzZWUgYSBudW1iZXIgb2Ygb3BlcmF0b3JzIHRoYXQgc3Vk ZGVubHkgZmluZCB0aGF0IHRoZWlyIG9sZCBSUA0KIHNvZnR3YXJlIGhhcyByZWplY3Qgb3VyIGZ1 bGwgcmVwb3NpdG9yeSB3aGVuIHN0YXJ0IHVzaW5nIHRoZSBuZXcgT0lEcy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgaXQgY2FuJ3QgYmUg YXZvaWRlZCB0aGFuIHNvIGJlIGl0LCBidXQgSSBiZWxpZXZlIHRoaXMgcGVyc3BlY3RpdmUgc2hv dWxkIGJlIGNvbnNpZGVyZWQgYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVyczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaW08bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C1D1FDD298924EE086FF24F412AF6669ciscocom_-- From nobody Tue Jun 20 08:55: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 40FDA131458; Tue, 20 Jun 2017 08:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 T_VMR6x46aM4; Tue, 20 Jun 2017 08:55:52 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 E7CFA131A91; Tue, 20 Jun 2017 08:52:54 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id w1so136179182qtg.2; Tue, 20 Jun 2017 08:52:54 -0700 (PDT) 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=rJg56xscWiJFG0bQcEkSKNR5TgkYeyh9mGp6y6A/JK0=; b=jsOODCZMCt1cO99PNY61gZWqgcEeMEclOZ6TlGuN1RN26g+woPAXaFrtIpaC91lc+m 1swGKsiADjcPjGMhKqvyPnRY7acZrTSewbnPkIsq1um099oXfSvAhzo/NUox3RTpELzK Ill35ML42MTpIGpsvTYTqlQPBZUBu01RlL4sBDQAAxOl26Jce7eKXHXoePimn3n//fCe UCcAce0hMJIopn3srqP3Z7abN4Ds7KgaNiQaqa2ccY4GAmL/H+tnQu4lAk1mCdapkTJF qRWFKhl+pxbMjBHPHKxJIaFuW25amAkEwJQmCYXvPIPeJ88DOhVRwliVw1KGL6W19j1B Vpnw== 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=rJg56xscWiJFG0bQcEkSKNR5TgkYeyh9mGp6y6A/JK0=; b=Fr0G4uVU8pHEmZYT66WBSOhOKwLxKk6zMp2MBOX2tDm+ECZRSOEkg+fbwX/DqfS3lC 9FVU+duBT1RPdyb41jEXAnAl9LDjvKFXhOVxLETqtEjl6xCdWDGMxnTk0yJBpA/oGoQ4 YTF0gv67Bb98h815yDND89c/mZQ38LqygGmOOIs7EWHshCOh7jpLiFZfqGtV07/04zyR aFFXb4+Mwj56VlvGsl4Uaka/DdlL74dzEbpKuuQgsPp0r1QGn8vUu9NPS72TCaEbJEt3 zK32IJm6DBxH5zTR6Sw58S913Lc7U9PzAIdIXfo7RV/7Y/tNQNLGBjpDDPkGiB7I26F3 e67Q== X-Gm-Message-State: AKS2vOwWRIk3+b5E9wmTWNJQrrRxy0N0+pOxbPCA5uJNaXGJeFMm2VJ6 wAonnq0XyDyc/h6pl9lUtL/ACVib2g== X-Received: by 10.237.44.101 with SMTP id f92mr36522756qtd.150.1497973974065; Tue, 20 Jun 2017 08:52:54 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.86.106 with HTTP; Tue, 20 Jun 2017 08:52:53 -0700 (PDT) In-Reply-To: References: <801A5228-4DF6-4882-A2A9-77B9BAD58871@tislabs.com> From: Christopher Morrow Date: Tue, 20 Jun 2017 11:52:53 -0400 X-Google-Sender-Auth: yqsMaB5Cjmd516Gsume_jkXaRbk Message-ID: To: Tim Bruijnzeels Cc: Sandra Murphy , sidr chairs , sidr Content-Type: multipart/alternative; boundary="94eb2c0615fc9b671a0552663e85" Archived-At: Subject: Re: [sidr] WGLC for draft-ietf-sidr-slurm-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 15:55:54 -0000 --94eb2c0615fc9b671a0552663e85 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Howdy WG folks. this seems to not have gotten much review (after the authors changed a bunch).. can we get some readin/reviewin/commentin going on here please? :) On Mon, Apr 17, 2017 at 2:06 PM, Tim Bruijnzeels wrote: > Dear WG > > One thing the authors noted was that there may be discussion needed aroun= d > the filtering of BGPSec assertions based on matching SKI - as the documen= t > currently says. This was added mainly in an attempt to make the spec > feature complete and give an operator full freedom on filter rules. > > SKIs use SHA-1. And recently it has been shown that SHA-1 collisions can > be generated. This could lead one to believe that filtering of assertions > based on a SKIs may not be a good idea. However, it should be noted that > such collisions are probably irrelevant here. A =E2=80=98malicious' CA ca= n always > issue another router certificate for an existing (and requested) router > certificate SKI and public key. So =E2=80=98collisions=E2=80=99 can exist= anyway and a more > secure hashing algorithm would not help. > > The more fundamental question here is if it is really useful to have > filtering based on the key itself - and if so - should it be possible to > filter on the key alone (as the draft allows) or only in combination with > an asserted ASN for that key (also allowed in this draft)? > > As said it was mainly added for feature completeness, but it would be goo= d > to hear from this WG what the thoughts are. Personally I don=E2=80=99t se= e a big > issue here - and would leave it to operators to use the options as they s= ee > fit. But if there are concerns and there is no clear use case then I for > one would be happy to take it out again in which case BGPSec assertions c= an > only be filtered on matching ASN. > > Cheers > Tim > > > On 10 Apr 2017, at 17:49, Sandra Murphy wrote: > > > > The authors of draft-ietf-sidr-slurm-04, "Simplified Local internet > nUmber Resource Management with the RPKI=E2=80=9D, have indicated that th= ey believe > the current version includes all wg comments and is mature and ready for > working group last call. > > > > This message starts a WGLC for draft-ietf-sidr-slurm-04. The WGLC will > end 24 April 2017. > > > > The draft can be found at https://tools.ietf.org/html/ > draft-ietf-sidr-slurm-04 or https://datatracker.ietf.org/ > doc/draft-ietf-sidr-slurm/. > > > > Please reply to the list whether the document is ready for publication > or you have comments that you think should be addressed. > > > > Please do read and respond to the list. Remember that responses are > required to gauge consensus, silence is not consent. > > > > =E2=80=94Sandy, speaking as wg co-chair > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --94eb2c0615fc9b671a0552663e85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy WG folks. this seems to not have gotten much review = (after the authors changed a bunch).. can we get some readin/reviewin/comme= ntin going on here please? :)

On Mon, Apr 17, 2017 at 2:06 PM, Tim Bruijnzeels <tim@ripe.ne= t> wrote:
Dear WG

One thing the authors noted was that there may be discussion needed around = the filtering of BGPSec assertions based on matching SKI - as the document = currently says. This was added mainly in an attempt to make the spec featur= e complete and give an operator full freedom on filter rules.

SKIs use SHA-1. And recently it has been shown that SHA-1 collisions can be= generated. This could lead one to believe that filtering of assertions bas= ed on a SKIs may not be a good idea. However, it should be noted that such = collisions are probably irrelevant here. A =E2=80=98malicious' CA can a= lways issue another router certificate for an existing (and requested) rout= er certificate SKI and public key. So =E2=80=98collisions=E2=80=99 can exis= t anyway and a more secure hashing algorithm would not help.

The more fundamental question here is if it is really useful to have filter= ing based on the key itself - and if so - should it be possible to filter o= n the key alone (as the draft allows) or only in combination with an assert= ed ASN for that key (also allowed in this draft)?

As said it was mainly added for feature completeness, but it would be good = to hear from this WG what the thoughts are. Personally I don=E2=80=99t see = a big issue here - and would leave it to operators to use the options as th= ey see fit.=C2=A0 But if there are concerns and there is no clear use case = then I for one would be happy to take it out again in which case BGPSec ass= ertions can only be filtered on matching ASN.

Cheers
Tim

> On 10 Apr 2017, at 17:49, Sandra Murphy <sandy@tislabs.com> wrote:
>
> The authors of draft-ietf-sidr-slurm-04, "Simplified Local intern= et nUmber Resource Management with the RPKI=E2=80=9D, have indicated that t= hey believe the current version includes all wg comments and is mature and = ready for working group last call.
>
> This message starts a WGLC for draft-ietf-sidr-slurm-04.=C2=A0 The WGL= C will end 24 April 2017.
>
> The draft can be found at https://tools.iet= f.org/html/draft-ietf-sidr-slurm-04 or https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/.
>
> Please reply to the list whether the document is ready for publication= or you have comments that you think should be addressed.
>
> Please do read and respond to the list.=C2=A0 Remember that responses = are required to gauge consensus, silence is not consent.
>
> =E2=80=94Sandy, speaking as wg co-chair
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

--94eb2c0615fc9b671a0552663e85-- From nobody Tue Jun 20 20:38: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 A0B0C12EBE4; Tue, 20 Jun 2017 20:38:54 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, 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 uJBwFcBy7tck; Tue, 20 Jun 2017 20:38:52 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2600E12949F; Tue, 20 Jun 2017 20:38:52 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 90AA128B003B; Tue, 20 Jun 2017 23:38:50 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 786F61F8036; Tue, 20 Jun 2017 23:38:50 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Sandra Murphy In-Reply-To: Date: Tue, 20 Jun 2017 23:38:44 -0400 Cc: Sandra Murphy , Tim Bruijnzeels , sidr chairs , sidr Content-Transfer-Encoding: quoted-printable Message-Id: <87ACB275-5A80-427B-A6D6-D888CC72E03C@tislabs.com> References: <801A5228-4DF6-4882-A2A9-77B9BAD58871@tislabs.com> To: Christopher Morrow X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [sidr] once more with feeling! WGLC for draft-ietf-sidr-slurm-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 03:38:55 -0000 The =E2=80=9Cnot have gotten much=E2=80=9D was one request from an = author, which got no response from the working group. Come on, folks. We can do this. Maybe the usual increase in attention and energy of an approaching = meeting will help. This starts a second wglc for draft-ietf-sidr-slurm-04. Since it is the = second wglc, it will be short, ending 30 Jun 2017. Silence is not consent. Consensus for publication requires actual = comment. Read it. Speak up. =E2=80=94Sandy, speaking as one of the wg co-chairs > On Jun 20, 2017, at 11:52 AM, Christopher Morrow = wrote: >=20 > Howdy WG folks. this seems to not have gotten much review (after the = authors changed a bunch).. can we get some readin/reviewin/commentin = going on here please? :) >=20 > On Mon, Apr 17, 2017 at 2:06 PM, Tim Bruijnzeels wrote: > Dear WG >=20 > One thing the authors noted was that there may be discussion needed = around the filtering of BGPSec assertions based on matching SKI - as the = document currently says. This was added mainly in an attempt to make the = spec feature complete and give an operator full freedom on filter rules. >=20 > SKIs use SHA-1. And recently it has been shown that SHA-1 collisions = can be generated. This could lead one to believe that filtering of = assertions based on a SKIs may not be a good idea. However, it should be = noted that such collisions are probably irrelevant here. A =E2=80=98malici= ous' CA can always issue another router certificate for an existing (and = requested) router certificate SKI and public key. So =E2=80=98collisions=E2= =80=99 can exist anyway and a more secure hashing algorithm would not = help. >=20 > The more fundamental question here is if it is really useful to have = filtering based on the key itself - and if so - should it be possible to = filter on the key alone (as the draft allows) or only in combination = with an asserted ASN for that key (also allowed in this draft)? >=20 > As said it was mainly added for feature completeness, but it would be = good to hear from this WG what the thoughts are. Personally I don=E2=80=99= t see a big issue here - and would leave it to operators to use the = options as they see fit. But if there are concerns and there is no = clear use case then I for one would be happy to take it out again in = which case BGPSec assertions can only be filtered on matching ASN. >=20 > Cheers > Tim >=20 > > On 10 Apr 2017, at 17:49, Sandra Murphy wrote: > > > > The authors of draft-ietf-sidr-slurm-04, "Simplified Local internet = nUmber Resource Management with the RPKI=E2=80=9D, have indicated that = they believe the current version includes all wg comments and is mature = and ready for working group last call. > > > > This message starts a WGLC for draft-ietf-sidr-slurm-04. The WGLC = will end 24 April 2017. > > > > The draft can be found at = https://tools.ietf.org/html/draft-ietf-sidr-slurm-04 or = https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/. > > > > Please reply to the list whether the document is ready for = publication or you have comments that you think should be addressed. > > > > Please do read and respond to the list. Remember that responses are = required to gauge consensus, silence is not consent. > > > > =E2=80=94Sandy, speaking as wg co-chair > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From nobody Tue Jun 20 23:07: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 E0778131654 for ; Tue, 20 Jun 2017 23:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 cfO49aJowGol for ; Tue, 20 Jun 2017 23:07:45 -0700 (PDT) Received: from smtp104.biz.mail.bf1.yahoo.com (smtp104.biz.mail.bf1.yahoo.com [98.139.221.63]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7154E131632 for ; Tue, 20 Jun 2017 23:07:43 -0700 (PDT) Received: (qmail 30496 invoked from network); 21 Jun 2017 06:07:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1498025262; bh=4gViRfMFUBTAS/vxUZfABwdUcft61XCwJ9HiXm7Jy1k=; h=Date:Subject:From:To:CC:Message-ID:References:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=hRQd1MqxdcMdatoiJb0nJXOXbJl0nbDt40vkZ6kmodADN2v25jeSpBKlYu8ZsoZV1d5szxdNhIPYz/IxcILumTQyTdj79fsBEzlKdsQp2zfepU3r6WdNGvjEg6pna/eEmZ08UwQYRYdZEdouoUVBb+dGS1ChFXdRAZjYf+LWiuQ= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: k0PgoAMVM1m7GSO1qUn9gAh8592oDNNh5Poeb_4rJJKlZad Jq4rt8SVsqgZjv09wVh1L2l3qXRwUvWDn85PAV7iU5r1bE96LUzdRMAobTEJ 6v9VEooQSIIBbBjkQGh9th3P9ucy8kz8Th4cUzlI70.LDKJ3mC3fzr8gMrbw _HoshgyUWf2XPS3Pjptl63JWFgg3sKbIpeduA7ToOPm2uS4z0NE1HXi0pLlL H.jL4QGfTLYorVodNo0SZJfIxB2BtJFET1WoUjVf8f.BXLMX47ai4brKVCWJ HRq4LIn0sEDnLtvDuAfonk5wnODvYBOcQ2VDTM_G2wg7p3HMXlXCcySQQHAn EHa2hvsXvJ67TN5.SJxOCvycHhLaXFa0H8d7Db0W.wf3kIrvwpGL_9aRAjxm 9GqOqyop0SMXoajLAvvnBQp1n48Obq0tpUkZtMz7o2guqSilQiU303O1pwVw UuGyR4ujI3G_uSSpOP7sNIAgRkBuuA5DV.bjwhmNxWM6Wx0THrwn5T4QvnRl Qc2I77me2uJ74Olu_HIsDOY..2qqtwKvTIL5QHvY9XG_Lq4.yzyY9MfFzSS9 7G.EONaeTi_OPAc5vnnuFhwG6zA-- X-Yahoo-SMTP: mGN28M.swBAqLrsVsMnMt.9fxF9UZFOhOQ-- User-Agent: Microsoft-MacOutlook/f.23.0.170610 Date: Tue, 20 Jun 2017 23:07:37 -0700 From: Mehmet Adalier To: Sandra Murphy , Christopher Morrow CC: sidr , sidr chairs Message-ID: <5D93CE9B-B802-4014-A3B8-F8B3A2F42456@antarateknik.com> Thread-Topic: [sidr] once more with feeling! WGLC for draft-ietf-sidr-slurm-04 References: <801A5228-4DF6-4882-A2A9-77B9BAD58871@tislabs.com> <87ACB275-5A80-427B-A6D6-D888CC72E03C@tislabs.com> In-Reply-To: <87ACB275-5A80-427B-A6D6-D888CC72E03C@tislabs.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [sidr] once more with feeling! WGLC for draft-ietf-sidr-slurm-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 06:07:53 -0000 In my opinion: 1) Irrelevant of the underlying hash function, BGPSec assertions based on =E2= =80=9Conly with matching SKI=E2=80=9D should not be recommended/possible 2) Regarding keys, =E2=80=9Conly in combination with an asserted ASN for that ke= y,=E2=80=9D not on the key alone mehmet On 6/20/17, 8:38 PM, "sidr on behalf of Sandra Murphy" wrote: The =E2=80=9Cnot have gotten much=E2=80=9D was one request from an author, which go= t no response from the working group. =20 Come on, folks. We can do this. =20 Maybe the usual increase in attention and energy of an approaching meet= ing will help. =20 This starts a second wglc for draft-ietf-sidr-slurm-04. Since it is th= e second wglc, it will be short, ending 30 Jun 2017. =20 Silence is not consent. Consensus for publication requires actual comm= ent. Read it. Speak up. =20 =E2=80=94Sandy, speaking as one of the wg co-chairs =20 =20 > On Jun 20, 2017, at 11:52 AM, Christopher Morrow wrote: >=20 > Howdy WG folks. this seems to not have gotten much review (after the = authors changed a bunch).. can we get some readin/reviewin/commentin going o= n here please? :) >=20 > On Mon, Apr 17, 2017 at 2:06 PM, Tim Bruijnzeels wrote= : > Dear WG >=20 > One thing the authors noted was that there may be discussion needed a= round the filtering of BGPSec assertions based on matching SKI - as the docu= ment currently says. This was added mainly in an attempt to make the spec fe= ature complete and give an operator full freedom on filter rules. >=20 > SKIs use SHA-1. And recently it has been shown that SHA-1 collisions = can be generated. This could lead one to believe that filtering of assertion= s based on a SKIs may not be a good idea. However, it should be noted that s= uch collisions are probably irrelevant here. A =E2=80=98malicious' CA can always i= ssue another router certificate for an existing (and requested) router certi= ficate SKI and public key. So =E2=80=98collisions=E2=80=99 can exist anyway and a more s= ecure hashing algorithm would not help. >=20 > The more fundamental question here is if it is really useful to have = filtering based on the key itself - and if so - should it be possible to fil= ter on the key alone (as the draft allows) or only in combination with an as= serted ASN for that key (also allowed in this draft)? >=20 > As said it was mainly added for feature completeness, but it would be= good to hear from this WG what the thoughts are. Personally I don=E2=80=99t see a= big issue here - and would leave it to operators to use the options as they= see fit. But if there are concerns and there is no clear use case then I f= or one would be happy to take it out again in which case BGPSec assertions c= an only be filtered on matching ASN. >=20 > Cheers > Tim >=20 > > On 10 Apr 2017, at 17:49, Sandra Murphy wrote: > > > > The authors of draft-ietf-sidr-slurm-04, "Simplified Local internet= nUmber Resource Management with the RPKI=E2=80=9D, have indicated that they belie= ve the current version includes all wg comments and is mature and ready for = working group last call. > > > > This message starts a WGLC for draft-ietf-sidr-slurm-04. The WGLC = will end 24 April 2017. > > > > The draft can be found at https://tools.ietf.org/html/draft-ietf-si= dr-slurm-04 or https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/. > > > > Please reply to the list whether the document is ready for publicat= ion or you have comments that you think should be addressed. > > > > Please do read and respond to the list. Remember that responses ar= e required to gauge consensus, silence is not consent. > > > > =E2=80=94Sandy, speaking as wg co-chair > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 =20 _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr =20 From nobody Thu Jun 22 01:36: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 4F9511279EB; Thu, 22 Jun 2017 01:36:31 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 IsrTet-u_W1u; Thu, 22 Jun 2017 01:36:29 -0700 (PDT) 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 4F5AC1242F7; Thu, 22 Jun 2017 01:36:26 -0700 (PDT) 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 1dNxbA-0000DA-R1; Thu, 22 Jun 2017 10:36:22 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-45.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dNxbA-0002Gd-Jh; Thu, 22 Jun 2017 10:36:20 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Bruijnzeels In-Reply-To: Date: Thu, 22 Jun 2017 10:36:19 +0200 Cc: "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" , "sidr-chairs@ietf.org" , "sidr@ietf.org" , Chris Morrow Content-Transfer-Encoding: quoted-printable Message-Id: References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> <20170311222527.324125ACF21@minas-ithil.hactrn.net> <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> <68C71545-48E4-40B8-91AC-88DE44C4125D@ripe.net> <8C26566E-8E22-4D35-85E1-387BA980115E@ripe.net> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719db093de51ab813d90c693c2833294ff4 Archived-At: Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 08:36:31 -0000 Hi Alvaro, all, Speaking for myself the reason for the delay is that I underestimated = the impact of the new OIDs on deployability of this algorithm. I also = meant to talk to all interested parties about this in person in Chicago, = but unfortunately my father was hospitalised at the time (all good = now!). All that said I will work on an update of this document following = Alvaro=E2=80=99s review. This document will define an additional = validation algorithm, but not update the existing one. We can finish = this work first and then have a structured discussion about deployment - = I propose that we take this work to SIDROPS. I canceled all my meetings today so I should have updated text to share = with my co-authors soon. Will then send a new version to the WG asap. Tim > On 15 Jun 2017, at 17:02, Alvaro Retana (aretana) = wrote: >=20 > Dear authors: > =20 > Hi! > =20 > It=E2=80=99s been 3 months since this e-mail, which was the last of = the thread started from my review. > =20 > I am expecting a revised ID =E2=80=93 what are the plans to move = forward? > =20 > Thanks! > =20 > Alvaro. > =20 > =20 > =20 > On 3/15/17, 10:24 AM, "sidr on behalf of Tim Bruijnzeels" = wrote: > =20 > Hi Chris,=20 > =20 >> On 13 Mar 2017, at 15:21, Chris Morrow = wrote: >> =20 >> but, having 2 versions of the validation >> algorithm and seeing published data for both OID sets for a single >> prefix/publication bundle will be very problematic. There's no >> proscribed 'prefer new over old' action here, so a CA must only >> publish one version of their data. > =20 > Why is this a problem, really? > =20 > The OIDs are set on a per certificate basis by the issuing CA. FWIW, = in our hosted set up we *will* be able to pro-actively re-issue = everything using the new OIDs without user interaction, but there are = cases in hosted CA deployments where a hosted CA can automatically = re-issue manifests, but ROAs can only be re-issued by explicit user = request, one by one. > =20 > So we may see hosted CAs with products like this: > =20 > 1 CRL (validation algorithm does not apply) > 1 MFT (new validation, although it won't matter because inherit is = used) > 1 ROA with new validation (which has been re-issued by the user) > 1 ROA with old validation (which has NOT yet been re-issued) > =20 > This might seem confusing, but since the OIDs make it very explicit = which algorithm the CA intended to use, I really do not see any = ambiguity here. > =20 > My main concern is that we need to be quite confident that new RP code = that understands the new OIDs has been available and is deployed. = Because old RPs will reject EVERYTHING once CAs start using the new = OIDs. > =20 > That is why I would have preferred to not need new OIDs, and just = agree on a day that the new algorithm should be preferred. Rob seems = adamant that the RFC3779 extension library code does not have access to = the context of the full certificate with the RPKI CP OID - so there is = no way to have something like: > =20 > if (FULL certificate has RPKI CP OID && Date is after 'switch' day) { > do NEW on RFC3779 extension > } else { > do OLD on RFC3779 extension > } > =20 > The impact of RP software not using the new library on 'switch' day is = fairly limited. They would not reject the full repository, but only = reject the exceptional cases where certificates ARE over-claiming. And = of course the date check can be removed in releases of the library after = 'switch' day.. > =20 > It seems to me that this is a design issue with OpenSSL itself, but be = that as it may - it may be unsurmountable. Rob knows this code much = better than I do. > =20 > Still the consequence of all this is is that we will have to have a = mix, and that despite our best efforts to warn everyone to upgrade their = RP software I expect that we WILL see a number of operators that = suddenly find that their old RP software has reject our full repository = when start using the new OIDs. > =20 > If it can't be avoided than so be it, but I believe this perspective = should be considered as well. > =20 > =20 > =20 > Cheers > =20 > Tim > =20 > =20 > =20 From nobody Thu Jun 22 02:25: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 ED7B3129400; Thu, 22 Jun 2017 02:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 x2zA8JiiFT3T; Thu, 22 Jun 2017 02:25:01 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 504BA128B51; Thu, 22 Jun 2017 02:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1474; q=dns/txt; s=iport; t=1498123501; x=1499333101; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dUugbXki6qPmwTvL2vCOUDgO02/3YjpFR76RNi8u36s=; b=Q1VBb71QmjwuiEV5PIsmMwzMjaYV+l11vgYBYPIdW19zkE6zfuvRjey0 yWbWDgdQrxlVH6iK8aicYNtNZuElHFGYgqqXDaH8HrqdsiUUk2HM759Mt yNvkgfwdm2i2t/v4aLDAafr8ktoo/oa+1nAMRfNSFgDSLaALYP4dg9c7N 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAQCWjEtZ/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1iBbweDZYoZkTwilXiCEYYkAhqCYj8YAQIBAQEBAQEBayiFGQE?= =?us-ascii?q?EASMRRQULAgEIGgImAgICMBUQAgQOBYokCKtigiaLZQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2BC4VigWArC4Juh30wgjEBBJcdh0YCk2CCCZAGiSWLcAEfOIEKdBV?= =?us-ascii?q?bAYR6HIFmdoceAgIiB4EFgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.39,372,1493683200"; d="scan'208";a="264674245" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2017 09:24:50 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v5M9OohT001401 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Jun 2017 09:24:50 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; Thu, 22 Jun 2017 04:24:50 -0500 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, 22 Jun 2017 04:24:49 -0500 From: "Alvaro Retana (aretana)" To: Tim Bruijnzeels CC: "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" , "sidr-chairs@ietf.org" , "sidr@ietf.org" , Chris Morrow Thread-Topic: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07 Thread-Index: AQHSmQVAKIoRRn/RNUKU0uFv8zRBd6GQn0+AgAE/doCAAMXagIAAPSwAgABKFgCAAtHPgICRFmCAgApy9ICAAC8TAA== Date: Thu, 22 Jun 2017 09:24:49 +0000 Message-ID: <5C70CE73-FEC7-4592-AF31-90B2664A9144@cisco.com> References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> <20170311222527.324125ACF21@minas-ithil.hactrn.net> <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> <68C71545-48E4-40B8-91AC-88DE44C4125D@ripe.net> <8C26566E-8E22-4D35-85E1-387BA980115E@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.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.208.170] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 09:25:03 -0000 T24gNi8yMi8xNywgMTA6MzYgQU0sICJUaW0gQnJ1aWpuemVlbHMiIDx0aW1AcmlwZS5uZXQ+IHdy b3RlOg0KDQpUaW06DQoNCkhpIQ0KDQo+IEFsbCB0aGF0IHNhaWQgSSB3aWxsIHdvcmsgb24gYW4g dXBkYXRlIG9mIHRoaXMgZG9jdW1lbnQgZm9sbG93aW5nIA0KPiBBbHZhcm/igJlzIHJldmlldy4g VGhpcyBkb2N1bWVudCB3aWxsIGRlZmluZSBhbiBhZGRpdGlvbmFsIHZhbGlkYXRpb24gDQo+IGFs Z29yaXRobSwgYnV0IG5vdCB1cGRhdGUgdGhlIGV4aXN0aW5nIG9uZS4gV2UgY2FuIGZpbmlzaCB0 aGlzIHdvcmsgDQo+IGZpcnN0IGFuZCB0aGVuIGhhdmUgYSBzdHJ1Y3R1cmVkIGRpc2N1c3Npb24g YWJvdXQgZGVwbG95bWVudCAtIEkgDQo+IHByb3Bvc2UgdGhhdCB3ZSB0YWtlIHRoaXMgd29yayB0 byBTSURST1BTLg0KDQpJ4oCZbSBhc3N1bWluZyB0aGF0IHlvdSBtZWFuOiBmaW5pc2ggZHJhZnQt aWV0Zi1zaWRyLXJwa2ktdmFsaWRhdGlvbi1yZWNvbnNpZGVyZWQgaW4gc2lkciAoaS5lLiBwdWJs aXNoIGFzIGFuIFJGQykgYW5kIHRoZW4gZnVydGhlciBkaXNjdXNzIGRlcGxveW1lbnQgaW4gc2lk cm9wcywgcmlnaHQ/DQoNCj4gSSBjYW5jZWxlZCBhbGwgbXkgbWVldGluZ3MgdG9kYXkgc28gSSBz aG91bGQgaGF2ZSB1cGRhdGVkIHRleHQgdG8gDQo+IHNoYXJlIHdpdGggbXkgY28tYXV0aG9ycyBz b29uLiBXaWxsIHRoZW4gc2VuZCBhIG5ldyB2ZXJzaW9uIHRvIA0KPiB0aGUgV0cgYXNhcC4NCg0K SnVzdCBhIHByb2NlZHVyZSBub3RlOiAgRXZlbiB0aG91Z2ggdGhlcmUgc2hvdWxkIGJlIGEgZ29v ZCBudW1iZXIgb2YgY2hhbmdlcywgSSBkb27igJl0IHRoaW5rIHdlIG5lZWQgdG8gcnVuIHRoZSBy ZXN1bHQgdGhyb3VnaCB0aGUgV0cgKGFzIGluIGEgbmV3IFdHTEMpLiAgSeKAmW0gaGFwcHkgdG8g YWxsb3cgdGltZSBmb3IgYW55b25lIHRvIGNvbW1lbnQgZnVydGhlciwgZWl0aGVyIG5vdyBvciBk dXJpbmcgSUVURiBMQy4gIEkganVzdCByYXRoZXIgbm90IG9mZmljaWFsbHkgc2VuZCB0aGUgZG9j dW1lbnQgYmFjayB0byB0aGUgV0cuDQoNClRoYW5rcyENCg0KQWx2YXJvLg0KDQoNCg0K From nobody Thu Jun 22 02:27: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 1E5BA1294DC; Thu, 22 Jun 2017 02:26:59 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 lBXAxkJYWjRi; Thu, 22 Jun 2017 02:26:57 -0700 (PDT) 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 4318C1292FD; Thu, 22 Jun 2017 02:26:57 -0700 (PDT) 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 1dNyO5-0007Jr-WE; Thu, 22 Jun 2017 11:26:54 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-45.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dNyO5-00087T-PL; Thu, 22 Jun 2017 11:26:53 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Bruijnzeels In-Reply-To: <5C70CE73-FEC7-4592-AF31-90B2664A9144@cisco.com> Date: Thu, 22 Jun 2017 11:26:52 +0200 Cc: "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" , "sidr-chairs@ietf.org" , "sidr@ietf.org" , Chris Morrow Content-Transfer-Encoding: quoted-printable Message-Id: References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> <20170311222527.324125ACF21@minas-ithil.hactrn.net> <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> <68C71545-48E4-40B8-91AC-88DE44C4125D@ripe.net> <8C26566E-8E22-4D35-85E1-387BA980115E@ripe.net> <5C70CE73-FEC7-4592-AF31-90B2664A9144@cisco.com> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719f0f13221b56bf6493e02826335416f73 Archived-At: Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 09:26:59 -0000 > On 22 Jun 2017, at 11:24, Alvaro Retana (aretana) = wrote: >=20 > On 6/22/17, 10:36 AM, "Tim Bruijnzeels" wrote: >=20 > Tim: >=20 > Hi! >=20 >> All that said I will work on an update of this document following=20 >> Alvaro=E2=80=99s review. This document will define an additional = validation=20 >> algorithm, but not update the existing one. We can finish this work=20= >> first and then have a structured discussion about deployment - I=20 >> propose that we take this work to SIDROPS. >=20 > I=E2=80=99m assuming that you mean: finish = draft-ietf-sidr-rpki-validation-reconsidered in sidr (i.e. publish as an = RFC) and then further discuss deployment in sidrops, right? yes >=20 >> I canceled all my meetings today so I should have updated text to=20 >> share with my co-authors soon. Will then send a new version to=20 >> the WG asap. >=20 > Just a procedure note: Even though there should be a good number of = changes, I don=E2=80=99t think we need to run the result through the WG = (as in a new WGLC). I=E2=80=99m happy to allow time for anyone to = comment further, either now or during IETF LC. I just rather not = officially send the document back to the WG. Works for me >=20 > Thanks! >=20 > Alvaro. >=20 >=20 >=20 From nobody Thu Jun 22 10:08: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 DBDF3129AF9; Thu, 22 Jun 2017 10:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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, RCVD_IN_MSPIKE_H2=-2.8, 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=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 LvvtM5Vpc5OD; Thu, 22 Jun 2017 10:08:38 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0042.outbound.protection.outlook.com [104.47.42.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C44127599; Thu, 22 Jun 2017 10:08:33 -0700 (PDT) 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=BKnS1e/I9rDGurw+kYi3o6JjhgIsABQ/zQa2G+ofD3o=; b=lvvIyzC+zN0dvwjBD6uhVOVbM/VgCyhwI9B6Xpf/d8SN94i42b2KonSO/UleleNeFPsntuUYBaQyWfbwV6efDwq4nyHmGB0hmz4QdCGFomghxLLxGdL0c8qFGvBSUkF3RxTLKqY+KPQEDny3q+zho0Ctm2C0Hprcu7C4JM6sYr4= Received: from CY4PR18MB1127.namprd18.prod.outlook.com (10.173.184.14) by CY4PR18MB1125.namprd18.prod.outlook.com (10.173.184.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.15; Thu, 22 Jun 2017 17:08:32 +0000 Received: from CY4PR18MB1127.namprd18.prod.outlook.com ([10.173.184.14]) by CY4PR18MB1127.namprd18.prod.outlook.com ([10.173.184.14]) with mapi id 15.01.1199.016; Thu, 22 Jun 2017 17:08:32 +0000 From: Keyur Patel To: "sidrops@ietf.org" CC: "sidr@ietf.org" , Chris Morrow Thread-Topic: Call for SIDROPS WG Agenda Items Thread-Index: AQHS63os+NtiT9/+yEOgeo/5FTcLaw== Date: Thu, 22 Jun 2017 17:08:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arrcus.com; x-originating-ip: [2600:1010:b065:ef43:3500:4425:cc53:824d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR18MB1125; 7:r0J2nMYCQ9CuRO+E7b2ZPdE/bzz8r8Jftg31bexGTRG4jyDazmv0jmJDFE3gdv1gxppZeyq1mtqkHwhLyXPggWZTRg2lWySfMA0qEs24m8wiiA9nOAECkAHwH6D7vXeo8kM8UdSg9AVlukhWmIcBnqPis2G2ugoqxaWs4qz+KhojqtB8ejHfs/qR6sHjpCzTf71IRO+H2brseom+dkvbgajIyOBZmav+ZB8tUhNjsZVb3uMU0KwOsQc6jK599axbDQtmCHG2Wz3+QqxFU6K69B3+bD/TOfkccEhzVIV7T9gbiiM/p+1SWk+JuV5VNJVQnexRRaJwsvgXCtLJVsAuc4Mg21JsCofUq8pCxS3EgZRoggodjyDsnaBpR4RP+J6+Qdpc1ox6nKzjaCI5fvoN0DppLit7IFR7eyr3W6Ob+sbYeAu3sejAdEOvcovkLfrTXjTHaSrzfUkZ38Y3CY+2T8jnEho5FEI2OiTW4RNfvv3MP+PSFZF+bAY6uDPpJag/43KOfeSK7Wn5dFuf8SImdrQN5cxqd/s3JcYD+MJR7lE4XLWHoHh170gw7nQP8IifH7nFKhTEBin/lA6EJORv9X9gShqVu/G4otGB0e6dl5K4rVhD5WtMwG4waI9cJoBTTQdGx8XP2yhixO5GkE/bsokixMaDy/E7OZZ6XEQIaQcfMS3gg2i7L0HyG4/sZxQ4MRgrDOGiydqIPQSR4mLQiozIIsoQA7HTt5EES81VVLtBWh/x4by3v4zj/m1u36wk1/OH9ZhFTuL7B4osDNxr6FtfMVXN54eDebeNjN1Bc/8= x-ms-office365-filtering-correlation-id: fa407242-de9d-402d-ea0f-08d4b9914f94 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201702281549075); SRVR:CY4PR18MB1125; x-ms-traffictypediagnostic: CY4PR18MB1125: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123555025)(20161123558100)(20161123564025)(2016111802025)(6043046)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR18MB1125; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR18MB1125; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(39450400003)(39410400002)(39400400002)(377454003)(110136004)(38730400002)(6916009)(7736002)(2900100001)(8676002)(1730700003)(2501003)(6306002)(54896002)(81166006)(25786009)(6512007)(6116002)(8936002)(102836003)(189998001)(36756003)(53936002)(6486002)(77096006)(99286003)(3280700002)(4326008)(14454004)(478600001)(5640700003)(54356999)(122556002)(86362001)(3660700001)(2351001)(2906002)(6436002)(54906002)(50986999)(33656002)(6506006)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR18MB1125; H:CY4PR18MB1127.namprd18.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_F51CD01F93B74F709C94828138600FE1arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 17:08:32.0918 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR18MB1125 Archived-At: Subject: [sidr] Call for SIDROPS WG Agenda Items X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 17:08:41 -0000 --_000_F51CD01F93B74F709C94828138600FE1arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgZm9sa3MsDQoNClNJRFJPUFMgd2lsbCBtZWV0IGF0IElFVEYtOTkgb24gTW9uZGF5LCBKdWx5 IDE3dGggZnJvbSAzOjUwIHBtIC0gNToyMCBwbS4NClBsZWFzZSBmb3J3YXJkIGFueSBTSURST1BT IGFnZW5kYSBpdGVtcyB5b3UgbWF5IGhhdmUgdG8gQ2hyaXMgYW5kIG1lLg0KUGxlYXNlIGFsc28g bWFrZSBzdXJlIHRoYXQgeW91ciBzbGlkZXMgYXJlIGF2YWlsYWJsZSB0byB0aGUgY2hhaXJzIGJ5 DQpNb25kYXkgbW9ybmluZyAoNy8xNi8yMDE3KS4gU2xpZGVzIHJlY2VpdmVkIGFmdGVyIHdpbGwg YmUgbGVzcw0KbGlrZWx5IHRvIGJlIGF2YWlsYWJsZSBmb3IgdXNlIGR1cmluZyB0aGUgbWVldGlu Zy4NCg0KUmVnYXJkcywNCkNocmlzIGFuZCBLZXl1cg0KDQo= --_000_F51CD01F93B74F709C94828138600FE1arrcuscom_ 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 eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSBmb2xr cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNJRFJPUFMgd2ls bCBtZWV0IGF0IElFVEYtOTkgb24gTW9uZGF5LCBKdWx5IDE3dGggZnJvbSAzOjUwIHBtIC0gNToy MCBwbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGxlYXNlIGZvcndhcmQgYW55IFNJRFJPUFMgYWdlbmRh IGl0ZW1zIHlvdSBtYXkgaGF2ZSB0byBDaHJpcyBhbmQgbWUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlBs ZWFzZSBhbHNvIG1ha2Ugc3VyZSB0aGF0IHlvdXIgc2xpZGVzIGFyZSBhdmFpbGFibGUgdG8gdGhl IGNoYWlycyBieTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Nb25kYXkgbW9ybmluZyAoNy8xNi8yMDE3KS4g U2xpZGVzIHJlY2VpdmVkIGFmdGVyIHdpbGwgYmUgbGVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5saWtl bHkgdG8gYmUgYXZhaWxhYmxlIGZvciB1c2UgZHVyaW5nIHRoZSBtZWV0aW5nLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Q2hyaXMgYW5kIEtleXVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F51CD01F93B74F709C94828138600FE1arrcuscom_-- From nobody Mon Jun 26 00:47: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 2818F126C23 for ; Mon, 26 Jun 2017 00:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 9kBLMY0Ltl5y for ; Mon, 26 Jun 2017 00:47:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F4B126579 for ; Mon, 26 Jun 2017 00:47:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPV44396; Mon, 26 Jun 2017 07:47:48 +0000 (GMT) Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 26 Jun 2017 08:47:47 +0100 Received: from DGGEML502-MBX.china.huawei.com ([169.254.2.143]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0301.000; Mon, 26 Jun 2017 15:47:38 +0800 From: "Xialiang (Frank)" To: "sidr@ietf.org" Thread-Topic: Re:once more with feeling! WGLC for draft-ietf-sidr-slurm-04 Thread-Index: AdLuUHqSlTYV+fwDSWCTQ83QDXnXtw== Date: Mon, 26 Jun 2017 07:47:37 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.159.76] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12BAFDA48DGGEML502MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5950BC24.00AA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.143, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ea59f2d322d4d4d3f11ad5e15ff6a98d Archived-At: Subject: Re: [sidr] once more with feeling! WGLC for draft-ietf-sidr-slurm-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 07:47:52 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12BAFDA48DGGEML502MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have reviewed this draft and think it is an useful method for ISPs to man= age and validate their local network through RPKI extensions. And this draft is well written. So, I support its publication at this stage. B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F12BAFDA48DGGEML502MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I have reviewed this draft and = think it is an useful method for ISPs to manage and validate their local ne= twork through RPKI extensions.

And this draft is well written.=

 

So, I support its publication a= t this stage.

 

B.R.

Frank

--_000_C02846B1344F344EB4FAA6FA7AF481F12BAFDA48DGGEML502MBXchi_-- From nobody Mon Jun 26 02:51: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 3FDE2129A97; Mon, 26 Jun 2017 02:51:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149847070121.31837.14846928984439938825@ietfa.amsl.com> Date: Mon, 26 Jun 2017 02:51:41 -0700 Archived-At: Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 09:51: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 : RPKI Validation Reconsidered Authors : Geoff Huston George Michaelson Carlos M. Martinez Tim Bruijnzeels Andrew Lee Newton Daniel Shaw Filename : draft-ietf-sidr-rpki-validation-reconsidered-08.txt Pages : 22 Date : 2017-06-26 Abstract: This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the RPKI, while retaining essential security features. The use of this updated procedure is signalled by form of a set of alternative Object Identifiers (OIDs) indicating that the alternative version of RFC 3779 X.509 Extensions for IP Addresses and AS Identifiers, and certificate policy for the Resource Public Key Infrastructure (RFC 6484) defined in this document should be used. Furthermore this document provides an alternative to ROA (RFC 6482), and BGPSec Router Certificate (BGPSec PKI Profiles - publication requested) validation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered-08 https://datatracker.ietf.org/doc/html/draft-ietf-sidr-rpki-validation-reconsidered-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-validation-reconsidered-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 Mon Jun 26 03:11: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 1701C129A92; Mon, 26 Jun 2017 03:11:31 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 M9dDgQFsd681; Mon, 26 Jun 2017 03:11:29 -0700 (PDT) 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 027F01270AC; Mon, 26 Jun 2017 03:11:29 -0700 (PDT) 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 1dPQzL-00035J-CG; Mon, 26 Jun 2017 12:11:25 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-8.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dPQzL-0003WO-33; Mon, 26 Jun 2017 12:11:23 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Bruijnzeels In-Reply-To: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> Date: Mon, 26 Jun 2017 12:11:22 +0200 Cc: "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" , "sidr-chairs@ietf.org" , "sidr@ietf.org" , Chris Morrow Content-Transfer-Encoding: quoted-printable Message-Id: <44CDB780-72BB-4FE3-8CA5-B760B7149670@ripe.net> References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07190a20fd014401b97a5c1f7a190b3f8e3b Archived-At: Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 10:11:31 -0000 Dear Alvaro, We have just uploaded a -08 version. See comments in-line below: > On 9 Mar 2017, at 19:44, Alvaro Retana (aretana) = wrote: >=20 > Dear authors: > =20 > I just finished reading this document. My review is predicated on the = assumption that the intent of the WG is to define an additional = validation process, and not amend/change/update/deprecate the existing = one=E2=80=A6yet, which is why there are not only process changes = specified, but also new OIDs. > =20 > As written, with Updates and text =E2=80=9Cto be used in place of=E2=80=9D= existing specifications, the document achieves the deprecation of the = current (old) mechanism: simply because procedurally you are replacing = the existing/old text with the new one=E2=80=A6and the old one would = then not be anymore. The result then is not coherent with the = assumption above, and we will need to rewrite (at least from an intent = point of view) the document before progressing. > =20 > I think that the easiest way forward would be for this document to say = something like: =E2=80=9Ca new validation mechanism is specified, which = uses these new OIDs =E2=80=93 the specifications defined in RFCA, RFCB, = etc.. apply, except for the following exceptions/changes.=E2=80=9D You = should then be able to use most of the substantive text already written. > =20 > Please see below for specific comments =E2=80=93 including more on why = this document should not Update the existing RFCs. > =20 > Thanks! > =20 > Alvaro. > =20 > =20 > =20 > Major: > =20 > M1. Section 4.2.1. (Changes to RFC6484). This document requests an = assignment of a new OID (id-cp-ipAddr-asNumber-v2); both the reference = and the policy to be followed are contained here, and not in RFC6484. = IOW, this document shouldn=E2=80=99t Update RFC6484. Instead, it should = request the new OID and simply reference RFC6484 when pointing back to = id-cp-ipAddr-asNumber. > =20 done, using =E2=80=9Calternative to=E2=80=9D in lots of places now.. > =20 > M2. Section 4.2.2. (Changes to RFC3779). Same comment: this document = requests the assignment of new OIDs=E2=80=A6. Note that if the changes = in Section 4.2.2.1. (OID for id-pe-ipAddrBlocks-v2) and Section 4.2.2.3. = (OID for id-pe-autonomousSysIds-v2) were to be used in place of the text = in RFC3779, then id-pe-ipAddrBlocks and id-pe-autonomousSysIds would end = up being deprecated. > =20 > M2.1. [minor] The syntax for id-pe-ipAddrBlocks-v2 and = id-pe-autonomousSysIds-v2 (4.2.2.2 and 4.2.2.4) use the =E2=80=9Cv1=E2=80=9D= names. > =20 > M2.2. For Sections 4.2.2.5 and 4.2.2.6, I think that what you want to = say is (something like): =E2=80=9Cwhen the OIDs defined in this document = are used, the procedures in RFC3779 are followed, except for the = certificate path validation (section 2.3), which is specified in Section = 4.2.4.4 of this document, and=E2=80=A6=E2=80=9D Again, if the text was = to replace what is currently in RFC3779, then those procedures would be = deprecated. > =20 > M2.3. Same comment for Section 4.2.2.7: amending the specification in = RFC3779 results in loosing what is defined there. > =20 done > =20 > M3. Section 4.2.4. (Changes to RFC6487). Same comments as above: = replacing the text (which is what an Update does), would result in the = mechanism specified in RFC6487 to be the same as what is specified in = this document=E2=80=A6which means that the option in the first paragraph = (=E2=80=9C=E2=80=A6MUST issue certificates either as specified in = [RFC6487] or with all the amendments specified in the following = sections.) would result in the same thing. As with Section 4.2.2 = (above), I think you really should specify what the exceptions are for = the extensions defined in this document (and not Update RFC6487). Presented as an alternative. But note that the validation algorithm = proposed here can handle a mix of RFC6487 and =E2=80=98reconsidered=E2=80=99= certificates. In a nutshell: it will warn on over-claims if = =E2=80=98reconsidered=E2=80=99 OIDs are used, and reject otherwise. This = allows for a gradual deployment in the RPKI where some issuing CAs opt = in to using this, and other don=E2=80=99t (yet). In other words: RPs that support =E2=80=98reconsidered=E2=80=99 should = use this approach instead of the algorithm defined in 7.2 of RFC6487. = The outcome in a pure RFC6487 world will be unchanged, the only negative = effect being that work was spent on calculating =E2=80=9CValidated = Resource Sets=E2=80=9D that was not strictly needed. > =20 > =20 > M4. Section 4.2.4.4. (Amended Resource Certificate Path Validation). > =20 > M4.1. [Comment about RFC6487] This document correctly mentions the = NotBefore/NotAfter values (which should really be notBefore/notAfter), = instead of From/To (in RFC6487). It seems to me that this is an error = in the original text. Can you please file an Errata against RFC6487? Focussing on this first, will try to remember! > =20 > M4.2. s/Certificate x contains all the extensions that MUST be = present/Certificate x contains all the required extensions The = =E2=80=9CMUST=E2=80=9D is not normative in this context. Ok, I think it=E2=80=99s better now. I also made it explicit what to = expect when an RFC6487 CP is found, vs a =E2=80=98reconsidered=E2=80=99 = CP. > =20 > M4.3. [minor] s/MUST be satisfy the constraints/MUST satisfy the = constraints > =20 > M4.4. =E2=80=9CIf IP Address Delegation extension is present, it is = replaced with the intersection of the values from that extension and the = current value of the VRS-IP.=E2=80=9D What is replaced, the IP Address = Delegation extension or the VRS-IP? If the extension, what does it mean = to replace the extension in the certificate? Note that the text about = the AS Identifier Delegation extension is as confusing. > =20 > M4.5. =E2=80=9C=E2=80=A6these values MAY be stored along with the = certificate, to facilitate incremental validation=E2=80=A6=E2=80=9D = This document (and RFC6487) don=E2=80=99t say anything about where to = store anything =E2=80=93 I don=E2=80=99t think we need that normative = =E2=80=9CMAY=E2=80=9D. s/MAY/may Removed this altogether - not important to specify here. > =20 > M4.6. This text is not needed: =E2=80=9CIf certificate x uses the = original version of [RFC6487], then certificate x MUST be rejected.=E2=80=9D= This text is needed but I clarified. The validation algorithm proposed = can handle a mix of RFC6487 and =E2=80=98reconsidered=E2=80=99 = certificates. In a nutshell: it will warn on over-claims if = =E2=80=98reconsidered=E2=80=99 OIDs are used, and reject otherwise. This = allows for a gradual deployment in the RPKI where some issuing CAs opt = in to using this, and other don=E2=80=99t (yet). > =20 > M5. Section 4.2.5. (Changes to RFC6482). Same comment about not = needing an Update/replacing the text/=E2=80=A6 Done. However, since all resources on ROA prefixes would need to be part of = the VRS-IP for a ROA EE certificate, we might as well say that ROA EE = certificates MUST never use the reconsidered profile. It would be = pointless to accept the EE certificate with warnings about over-claim, = only to reject the ROA itself because it lists prefix that were = rejected. You didn=E2=80=99t mention, but I assume that the same comment applies = to section 4.2.6 (router certificates), so updated that as well. For the moment the document describes validation in case the = reconsidered OIDs *are* used for ROAs and Router Certificates - = personally I feel this is probably best because it=E2=80=99s explicit. = And it leaves the question whether the new OIDs MAY/MUST NOT be used in = these cases to the migration discussion we still need to have after this = work. > =20 > =20 > M6. Section 5. (Deployment Considerations). The timeline in Table 1 = shouldn=E2=80=99t appear in this specification. Migration is an = operational issue that the community should coordinate separately (and = not by specifying a normative timeline in an RFC). What should be = included here are any other migration considerations that should be = observed when making the transition =E2=80=93 if there=E2=80=99s = anything beyond what you already wrote. done=20 > =20 > =20 > M7. Section 6. (Security Considerations). Please point to the security = considerations in RFC3779, RFC6482, RFC6484 and RFC6487 as applying here = too. It might be beneficial to include a short discussion of why not = immediately rejecting the over-claiming certificates is not a security = issue done=20 > =20 > =20 > M8. IANA Considerations. TBD4/TBD5 are not for = IPAddrAndASCertExtn-*, but for the new id-mod-ip-addr-and-as-ident-*. done=20 > =20 > M9. References > - Please add a reference to RFC2119 and the corresponding boilerplate. We have this reference, am I am missing something? > - I don=E2=80=99t think that the reference to RFC6268 needs to me = Normative. > - We don=E2=80=99t need references to RFC3849, RFC5398 or RFC5737. > - RFC3280 was Obsoleted by RFC5280 done=20 > =20 > =20 > =20 > Minor: > =20 > P1. The example in Section 3 is meant to be a continuation from the = example in Section 2 (=E2=80=9CCertificate 2 from the previous example = was re-issued by TA to CA1 and the prefix 198.51.100.0/24 was removed. = However, CA1 failed to re-issue a new Certificate 3 to CA2.=E2=80=9D); = but Certificate 3 is not the same as the one shown in Section 2. I = think the example still gets the over-claiming point across, but it is = =E2=80=9Cwrong=E2=80=9D in that both Certificate 2 and Certificate 3 = (not just Certificate 2) would have to change for the problem to happen. > =20 > P2, Also in the example in Section 3. It might be beneficial for the = reader if the EE certificate was also marked as invalid; the text says = so, but the list of certificates doesn=E2=80=99t. > =20 > P3. In several places =E2=80=9C[this document]=E2=80=9D is used =E2=80=93= if the intent is to refer to a specific Section, please indicate which. = If not, then you should get rid of the brackets ([]). > =20 > P4. In 4.3: =E2=80=9CROA1 is considered valid because the prefix = matches the Verified Resource Set on the embedded EE certificate, as = required by RFC 6482.=E2=80=9D The VRS is introduced in this document, = not RFC6482. > =20 > =20 > =20 > Nits: > =20 > N1. =E2=80=9CThis document proposes=E2=80=A6=E2=80=9D and =E2=80=9CThe = changes proposed here=E2=80=A6=E2=80=9D. We=E2=80=99re past the = proposal phase: =E2=80=9CThis document specifies=E2=80=A6=E2=80=9D > =20 > N2. s/ maintaining Verified Resource Set/ maintaining a Verified = Resource Set > =20 > N3. s/ the loss of on IP address prefix/ the loss of one IP address = prefix > =20 > N4. s/ the 1988 ASN.1 modules for which we provided an update in = Section 4.2.2.7 remain the normative version/ the 1988 ASN.1 modules in = Section 4.2.2.7 remain the normative version > =20 > N5. s/ Furthermore we wish to note that operators MAY issue separate = BGPsec Router Certificates for different ASNs/ Operators MAY issue = separate BGPsec Router Certificates for different ASNs All done Thanks, Tim From nobody Mon Jun 26 18:46: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 2F65D1286CA; Mon, 26 Jun 2017 18:46:52 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 bfa-n_l8TfpU; Mon, 26 Jun 2017 18:46:45 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.219]) by ietfa.amsl.com (Postfix) with ESMTP id 08EE4127A91; Mon, 26 Jun 2017 18:46:44 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.218:45502.1131226809 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-219.142.69.75 (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with ESMTP id 6A6B02800C5; Tue, 27 Jun 2017 09:46:34 +0800 (CST) Received: from ip<219.142.69.75> ([172.18.0.218]) by App0025 with ESMTP id 3c95bc2f-8c9a-401c-b830-efcc90b9e8c2 for sandy@tislabs.com; Tue Jun 27 09:46:39 2017 0/X-Total-Score: 0: X-Real-From: xiechf.bri@chinatelecom.cn X-Receive-IP: 172.18.0.218 X-MEDUSA-Status: 0 Date: Tue, 27 Jun 2017 09:46:29 +0800 From: "xiechf.bri@chinatelecom.cn" To: "sandy@tislabs.com" Cc: "sidr@ietf.org" , "sidr-chairs@ietf.org" X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 8, 379[cn] Mime-Version: 1.0 Message-ID: <2017062709462906675410@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart448347673047_=----" Archived-At: Subject: Re: [sidr] once more with feeling! WGLC for draft-ietf-sidr-slurm-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 01:46:52 -0000 This is a multi-part message in MIME format. ------=_001_NextPart448347673047_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 DQpIaSwgZm9sa3MsDQoNCiBJIHRoaW5rIHRoZSBsb2NhbCByZXNvdXJjZSBtYW5hZ2VtZW50IG9m IHJlc291cmNlIHdpdGggUFJLSSAgaW4gdGhpcyBkcmFmdCB3aWxsIGJlIHZlcnkgZWZmZWN0aXZl IGFuZCB1c2VmdWwgdG8gc2VjdXJlIHRoZSBCR1Agcm91dGluZyBvZiBjYXJyaWVyIG5ldHdvcmss ICAgc28gSSBnaXZlIG15IHN1cHBvcnQgdG8gaXQuDQoNClRoYW5rIHlvdSENCg0KQ2hvbmdmZW5n IA0KICAgICAgIA0KICAgICANCg0K5Y+R5Lu25Lq6OiBTYW5kcmEgTXVycGh5IDxzYW5keUB0aXNs YWJzLmNvbT4NCuS4u+mimDogW3NpZHJdIG9uY2UgbW9yZSB3aXRoIGZlZWxpbmchIFdHTEMgZm9y IGRyYWZ0LWlldGYtc2lkci1zbHVybS0wNA0K5pel5pyfOiAyMDE35bm0NuaciDIx5pelIEdNVCs4 IDExOjM4OjQ0DQrmlLbku7bkuro6IENocmlzdG9waGVyIE1vcnJvdyA8bW9ycm93Yy5saXN0c0Bn bWFpbC5jb20+DQrmioTpgIE6IHNpZHIgPHNpZHJAaWV0Zi5vcmc+LCBzaWRyIGNoYWlycyA8c2lk ci1jaGFpcnNAaWV0Zi5vcmc+DQoNClRoZSDigJxub3QgaGF2ZSBnb3R0ZW4gbXVjaOKAnSB3YXMg b25lIHJlcXVlc3QgZnJvbSBhbiBhdXRob3IsIHdoaWNoIGdvdCBubyByZXNwb25zZSBmcm9tIHRo ZSB3b3JraW5nIGdyb3VwLg0KDQpDb21lIG9uLCBmb2xrcy4gIFdlIGNhbiBkbyB0aGlzLg0KDQpN YXliZSB0aGUgdXN1YWwgaW5jcmVhc2UgaW4gYXR0ZW50aW9uIGFuZCBlbmVyZ3kgb2YgYW4gYXBw cm9hY2hpbmcgbWVldGluZyB3aWxsIGhlbHAuDQoNClRoaXMgc3RhcnRzIGEgc2Vjb25kIHdnbGMg Zm9yIGRyYWZ0LWlldGYtc2lkci1zbHVybS0wNC4gIFNpbmNlIGl0IGlzIHRoZSBzZWNvbmQgd2ds YywgaXQgd2lsbCBiZSBzaG9ydCwgZW5kaW5nIDMwIEp1biAyMDE3Lg0KDQpTaWxlbmNlIGlzIG5v dCBjb25zZW50LiAgQ29uc2Vuc3VzIGZvciBwdWJsaWNhdGlvbiByZXF1aXJlcyBhY3R1YWwgY29t bWVudC4gIFJlYWQgaXQuICBTcGVhayB1cC4NCg0K4oCUU2FuZHksIHNwZWFraW5nIGFzIG9uZSBv ZiB0aGUgd2cgY28tY2hhaXJzDQoNCg0KT24gSnVuIDIwLCAyMDE3LCBhdCAxMTo1MiBBTSwgQ2hy aXN0b3BoZXIgTW9ycm93IDxtb3Jyb3djLmxpc3RzQGdtYWlsLmNvbT4gd3JvdGU6DQoNCkhvd2R5 IFdHIGZvbGtzLiB0aGlzIHNlZW1zIHRvIG5vdCBoYXZlIGdvdHRlbiBtdWNoIHJldmlldyAoYWZ0 ZXIgdGhlIGF1dGhvcnMgY2hhbmdlZCBhIGJ1bmNoKS4uIGNhbiB3ZSBnZXQgc29tZSByZWFkaW4v cmV2aWV3aW4vY29tbWVudGluIGdvaW5nIG9uIGhlcmUgcGxlYXNlPyA6KQ0KDQpPbiBNb24sIEFw ciAxNywgMjAxNyBhdCAyOjA2IFBNLCBUaW0gQnJ1aWpuemVlbHMgPHRpbUByaXBlLm5ldD4gd3Jv dGU6DQpEZWFyIFdHDQoNCk9uZSB0aGluZyB0aGUgYXV0aG9ycyBub3RlZCB3YXMgdGhhdCB0aGVy ZSBtYXkgYmUgZGlzY3Vzc2lvbiBuZWVkZWQgYXJvdW5kIHRoZSBmaWx0ZXJpbmcgb2YgQkdQU2Vj IGFzc2VydGlvbnMgYmFzZWQgb24gbWF0Y2hpbmcgU0tJIC0gYXMgdGhlIGRvY3VtZW50IGN1cnJl bnRseSBzYXlzLiBUaGlzIHdhcyBhZGRlZCBtYWlubHkgaW4gYW4gYXR0ZW1wdCB0byBtYWtlIHRo ZSBzcGVjIGZlYXR1cmUgY29tcGxldGUgYW5kIGdpdmUgYW4gb3BlcmF0b3IgZnVsbCBmcmVlZG9t IG9uIGZpbHRlciBydWxlcy4NCg0KU0tJcyB1c2UgU0hBLTEuIEFuZCByZWNlbnRseSBpdCBoYXMg YmVlbiBzaG93biB0aGF0IFNIQS0xIGNvbGxpc2lvbnMgY2FuIGJlIGdlbmVyYXRlZC4gVGhpcyBj b3VsZCBsZWFkIG9uZSB0byBiZWxpZXZlIHRoYXQgZmlsdGVyaW5nIG9mIGFzc2VydGlvbnMgYmFz ZWQgb24gYSBTS0lzIG1heSBub3QgYmUgYSBnb29kIGlkZWEuIEhvd2V2ZXIsIGl0IHNob3VsZCBi ZSBub3RlZCB0aGF0IHN1Y2ggY29sbGlzaW9ucyBhcmUgcHJvYmFibHkgaXJyZWxldmFudCBoZXJl LiBBIOKAmG1hbGljaW91cycgQ0EgY2FuIGFsd2F5cyBpc3N1ZSBhbm90aGVyIHJvdXRlciBjZXJ0 aWZpY2F0ZSBmb3IgYW4gZXhpc3RpbmcgKGFuZCByZXF1ZXN0ZWQpIHJvdXRlciBjZXJ0aWZpY2F0 ZSBTS0kgYW5kIHB1YmxpYyBrZXkuIFNvIOKAmGNvbGxpc2lvbnPigJkgY2FuIGV4aXN0IGFueXdh eSBhbmQgYSBtb3JlIHNlY3VyZSBoYXNoaW5nIGFsZ29yaXRobSB3b3VsZCBub3QgaGVscC4NCg0K VGhlIG1vcmUgZnVuZGFtZW50YWwgcXVlc3Rpb24gaGVyZSBpcyBpZiBpdCBpcyByZWFsbHkgdXNl ZnVsIHRvIGhhdmUgZmlsdGVyaW5nIGJhc2VkIG9uIHRoZSBrZXkgaXRzZWxmIC0gYW5kIGlmIHNv IC0gc2hvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGZpbHRlciBvbiB0aGUga2V5IGFsb25lIChhcyB0 aGUgZHJhZnQgYWxsb3dzKSBvciBvbmx5IGluIGNvbWJpbmF0aW9uIHdpdGggYW4gYXNzZXJ0ZWQg QVNOIGZvciB0aGF0IGtleSAoYWxzbyBhbGxvd2VkIGluIHRoaXMgZHJhZnQpPw0KDQpBcyBzYWlk IGl0IHdhcyBtYWlubHkgYWRkZWQgZm9yIGZlYXR1cmUgY29tcGxldGVuZXNzLCBidXQgaXQgd291 bGQgYmUgZ29vZCB0byBoZWFyIGZyb20gdGhpcyBXRyB3aGF0IHRoZSB0aG91Z2h0cyBhcmUuIFBl cnNvbmFsbHkgSSBkb27igJl0IHNlZSBhIGJpZyBpc3N1ZSBoZXJlIC0gYW5kIHdvdWxkIGxlYXZl IGl0IHRvIG9wZXJhdG9ycyB0byB1c2UgdGhlIG9wdGlvbnMgYXMgdGhleSBzZWUgZml0LiAgQnV0 IGlmIHRoZXJlIGFyZSBjb25jZXJucyBhbmQgdGhlcmUgaXMgbm8gY2xlYXIgdXNlIGNhc2UgdGhl biBJIGZvciBvbmUgd291bGQgYmUgaGFwcHkgdG8gdGFrZSBpdCBvdXQgYWdhaW4gaW4gd2hpY2gg Y2FzZSBCR1BTZWMgYXNzZXJ0aW9ucyBjYW4gb25seSBiZSBmaWx0ZXJlZCBvbiBtYXRjaGluZyBB U04uDQoNCkNoZWVycw0KVGltDQoNCk9uIDEwIEFwciAyMDE3LCBhdCAxNzo0OSwgU2FuZHJhIE11 cnBoeSA8c2FuZHlAdGlzbGFicy5jb20+IHdyb3RlOg0KDQpUaGUgYXV0aG9ycyBvZiBkcmFmdC1p ZXRmLXNpZHItc2x1cm0tMDQsICJTaW1wbGlmaWVkIExvY2FsIGludGVybmV0IG5VbWJlciBSZXNv dXJjZSBNYW5hZ2VtZW50IHdpdGggdGhlIFJQS0nigJ0sIGhhdmUgaW5kaWNhdGVkIHRoYXQgdGhl eSBiZWxpZXZlIHRoZSBjdXJyZW50IHZlcnNpb24gaW5jbHVkZXMgYWxsIHdnIGNvbW1lbnRzIGFu ZCBpcyBtYXR1cmUgYW5kIHJlYWR5IGZvciB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4NCg0KVGhp cyBtZXNzYWdlIHN0YXJ0cyBhIFdHTEMgZm9yIGRyYWZ0LWlldGYtc2lkci1zbHVybS0wNC4gIFRo ZSBXR0xDIHdpbGwgZW5kIDI0IEFwcmlsIDIwMTcuDQoNClRoZSBkcmFmdCBjYW4gYmUgZm91bmQg YXQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2lkci1zbHVybS0wNCBv ciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNpZHItc2x1cm0v Lg0KDQpQbGVhc2UgcmVwbHkgdG8gdGhlIGxpc3Qgd2hldGhlciB0aGUgZG9jdW1lbnQgaXMgcmVh ZHkgZm9yIHB1YmxpY2F0aW9uIG9yIHlvdSBoYXZlIGNvbW1lbnRzIHRoYXQgeW91IHRoaW5rIHNo b3VsZCBiZSBhZGRyZXNzZWQuDQoNClBsZWFzZSBkbyByZWFkIGFuZCByZXNwb25kIHRvIHRoZSBs aXN0LiAgUmVtZW1iZXIgdGhhdCByZXNwb25zZXMgYXJlIHJlcXVpcmVkIHRvIGdhdWdlIGNvbnNl bnN1cywgc2lsZW5jZSBpcyBub3QgY29uc2VudC4NCg0K4oCUU2FuZHksIHNwZWFraW5nIGFzIHdn IGNvLWNoYWlyDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kc2lkciBtYWlsaW5nIGxpc3QNCnNpZHJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2lkcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kc2lkciBtYWlsaW5nIGxpc3QNCnNpZHJAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkcg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaWRyIG1haWxpbmcgbGlzdA0Kc2lk ckBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyDQoN Cg== ------=_001_NextPart448347673047_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A

=0AHi, folks,

 I think the local resource man= agement of resource with PRKI  in this draft will be very effective a= nd useful to secure the BGP routing of carrier network,   so I give m= y support to it.

Thank you!

<= div>Chongfeng 
       
 =    

=E5=8F= =91=E4=BB=B6=E4=BA=BA: Sandra Murphy = <sandy@tislabs.com&= gt;
=E4=B8=BB=E9=A2=98: <= /span>[sidr] once more with feelin= g! WGLC for draft-ietf-sidr-slurm-04
<= b class=3D"">=E6=97=A5=E6=9C=9F: 2017= =E5=B9=B46=E6=9C=8821=E6=97=A5 GMT+8 11:38:44
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margi= n-left: 0px;" class=3D"">=E6=94=B6=E4=BB=B6=E4=BA=BA: Christopher Morrow <morrowc.lists@gmail.com>
=E6=8A=84=E9=80=81: si= dr <sidr@ietf.org>, = sidr chairs <sidr-ch= airs@ietf.org>

The =E2=80=9Cnot have gotten much=E2=80=9D was one r= equest from an author, which got no response from the working group.

Come on, folks.  We can do this.

Maybe the usual increase in attention and energy of an ap= proaching meeting will help.

This starts a se= cond wglc for draft-ietf-sidr-slurm-04.  Since it is the second wglc,= it will be short, ending 30 Jun 2017.

Silenc= e is not consent.  Consensus for publication requires actual comment.=  Read it.  Speak up.

=E2=80=94Sand= y, speaking as one of the wg co-chairs


O= n Jun 20, 2017, at 11:52 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:

Howdy WG folks. this seems to not have gotten mu= ch review (after the authors changed a bunch).. can we get some readin/rev= iewin/commentin going on here please? :)

On M= on, Apr 17, 2017 at 2:06 PM, Tim Bruijnzeels <tim@ripe.net> wrote:
Dear WG

One thing the authors noted was that there may be d= iscussion needed around the filtering of BGPSec assertions based on matchi= ng SKI - as the document currently says. This was added mainly in an attem= pt to make the spec feature complete and give an operator full freedom on = filter rules.

SKIs use SHA-1. And recently it= has been shown that SHA-1 collisions can be generated. This could lead on= e to believe that filtering of assertions based on a SKIs may not be a goo= d idea. However, it should be noted that such collisions are probably irre= levant here. A =E2=80=98malicious' CA can always issue another router cert= ificate for an existing (and requested) router certificate SKI and public = key. So =E2=80=98collisions=E2=80=99 can exist anyway and a more secure ha= shing algorithm would not help.

The more fund= amental question here is if it is really useful to have filtering based on= the key itself - and if so - should it be possible to filter on the key a= lone (as the draft allows) or only in combination with an asserted ASN for= that key (also allowed in this draft)?

As sa= id it was mainly added for feature completeness, but it would be good to h= ear from this WG what the thoughts are. Personally I don=E2=80=99t see a b= ig issue here - and would leave it to operators to use the options as they= see fit.  But if there are concerns and there is no clear use case t= hen I for one would be happy to take it out again in which case BGPSec ass= ertions can only be filtered on matching ASN.

Cheers
Tim

On 10 Apr 2017, at 17:49, San= dra Murphy <sandy@tisla= bs.com> wrote:

The authors of draft-ie= tf-sidr-slurm-04, "Simplified Local internet nUmber Resource Management wi= th the RPKI=E2=80=9D, have indicated that they believe the current version= includes all wg comments and is mature and ready for working group last c= all.

This message starts a WGLC for draft-iet= f-sidr-slurm-04.  The WGLC will end 24 April 2017.

The draft can be found at https://tools.ietf.org/html/draft-i= etf-sidr-slurm-04 or https://datatracker.ietf.org/doc/draft-ietf-= sidr-slurm/.

Please reply to the list whe= ther the document is ready for publication or you have comments that you t= hink should be addressed.

Please do read and = respond to the list.  Remember that responses are required to gauge c= onsensus, silence is not consent.

=E2=80=94Sa= ndy, speaking as wg co-chair
_______________________________= ________________
sidr mailing list
sidr@ietf.org
https://w= ww.ietf.org/mailman/listinfo/sidr

_______________________________________________
sidr maili= ng list
sidr@iet= f.org
https://www.ietf.org/mailman/listinfo/sidr


________________________= _______________________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr

=0A ------=_001_NextPart448347673047_=------ From nobody Mon Jun 26 21:20: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 21A94128B8E for ; Mon, 26 Jun 2017 21:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zdns.cn 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 Fi8Jr8vqm1JB for ; Mon, 26 Jun 2017 21:20:19 -0700 (PDT) Received: from mail.zdns.cn (smtp.zdns.cn [202.173.10.13]) (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 0E1A7128B8F for ; Mon, 26 Jun 2017 21:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zdns.cn; s=dkim; x=1499142019; i=madi@zdns.cn; h=Content-Type: Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; bh=go2q5fh4X TWskhAe2P/jwm+1C6/T9AIkWdcvWP6HIik=; b=skOjK63lj74tZ44tcKpStEqcv e+QA81lj2otsXBiOVpijL0TqUwJUmshx+4kqLm7BuWIOb5E+mx6e2mVy9EamT+ja 2+xwX1fea6lrMiby7m7kfOMIzY2hA6J/3gezxzcPidTsaHmuNjV79opxYf8vmRPy 9Vunlgljzqbeij4o+E= X-TM-DID: 40c5fd475c6cb531536af8ce44a29874 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Declan Ma In-Reply-To: <5D93CE9B-B802-4014-A3B8-F8B3A2F42456@antarateknik.com> Date: Tue, 27 Jun 2017 12:19:52 +0800 Cc: Sandra Murphy , Christopher Morrow , sidr chairs , sidr Content-Transfer-Encoding: quoted-printable Message-Id: <9ACE1099-C5F3-48A3-BE97-649BDA8123BC@zdns.cn> References: <801A5228-4DF6-4882-A2A9-77B9BAD58871@tislabs.com> <87ACB275-5A80-427B-A6D6-D888CC72E03C@tislabs.com> <5D93CE9B-B802-4014-A3B8-F8B3A2F42456@antarateknik.com> To: Mehmet Adalier X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sidr] once more with feeling! WGLC for draft-ietf-sidr-slurm-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 04:20:22 -0000 Mehmet, Thanks very much for your feedback. See my comments in lines.=20 > =E5=9C=A8 2017=E5=B9=B46=E6=9C=8821=E6=97=A5=EF=BC=8C14:07=EF=BC=8CMehme= t Adalier =E5=86=99=E9=81=93=EF=BC=9A >=20 > In my opinion: >=20 > 1) Irrelevant of the underlying hash function, BGPSec assertions based = on =E2=80=9Conly with matching SKI=E2=80=9D should not be = recommended/possible I believe that SKI collision issues is an inherited problem from SHA-1, = not an issue SLURM brings about. Nevertheless, I agree with your opinion since SLURM is intended to be a = sort of RPKI safeguard in local networks.=20 > 2) Regarding keys, =E2=80=9Conly in combination with an asserted ASN = for that key,=E2=80=9D not on the key alone I think it=E2=80=99s reasonable to make it obliged to do filtering on = the SKI in combination with an asserted ASN.=20 We authors will be figuring out how to get this done after WGLC. Di >=20 > mehmet >=20 > On 6/20/17, 8:38 PM, "sidr on behalf of Sandra Murphy" = wrote: >=20 > The =E2=80=9Cnot have gotten much=E2=80=9D was one request from an = author, which got no response from the working group. >=20 > Come on, folks. We can do this. >=20 > Maybe the usual increase in attention and energy of an approaching = meeting will help. >=20 > This starts a second wglc for draft-ietf-sidr-slurm-04. Since it = is the second wglc, it will be short, ending 30 Jun 2017. >=20 > Silence is not consent. Consensus for publication requires actual = comment. Read it. Speak up. >=20 > =E2=80=94Sandy, speaking as one of the wg co-chairs >=20 >=20 >> On Jun 20, 2017, at 11:52 AM, Christopher Morrow = wrote: >>=20 >> Howdy WG folks. this seems to not have gotten much review (after the = authors changed a bunch).. can we get some readin/reviewin/commentin = going on here please? :) >>=20 >> On Mon, Apr 17, 2017 at 2:06 PM, Tim Bruijnzeels = wrote: >> Dear WG >>=20 >> One thing the authors noted was that there may be discussion needed = around the filtering of BGPSec assertions based on matching SKI - as the = document currently says. This was added mainly in an attempt to make the = spec feature complete and give an operator full freedom on filter rules. >>=20 >> SKIs use SHA-1. And recently it has been shown that SHA-1 collisions = can be generated. This could lead one to believe that filtering of = assertions based on a SKIs may not be a good idea. However, it should be = noted that such collisions are probably irrelevant here. A =E2=80=98malici= ous' CA can always issue another router certificate for an existing (and = requested) router certificate SKI and public key. So =E2=80=98collisions=E2= =80=99 can exist anyway and a more secure hashing algorithm would not = help. >>=20 >> The more fundamental question here is if it is really useful to have = filtering based on the key itself - and if so - should it be possible to = filter on the key alone (as the draft allows) or only in combination = with an asserted ASN for that key (also allowed in this draft)? >>=20 >> As said it was mainly added for feature completeness, but it would be = good to hear from this WG what the thoughts are. Personally I don=E2=80=99= t see a big issue here - and would leave it to operators to use the = options as they see fit. But if there are concerns and there is no = clear use case then I for one would be happy to take it out again in = which case BGPSec assertions can only be filtered on matching ASN. >>=20 >> Cheers >> Tim >>=20 >>> On 10 Apr 2017, at 17:49, Sandra Murphy wrote: >>>=20 >>> The authors of draft-ietf-sidr-slurm-04, "Simplified Local internet = nUmber Resource Management with the RPKI=E2=80=9D, have indicated that = they believe the current version includes all wg comments and is mature = and ready for working group last call. >>>=20 >>> This message starts a WGLC for draft-ietf-sidr-slurm-04. The WGLC = will end 24 April 2017. >>>=20 >>> The draft can be found at = https://tools.ietf.org/html/draft-ietf-sidr-slurm-04 or = https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/. >>>=20 >>> Please reply to the list whether the document is ready for = publication or you have comments that you think should be addressed. >>>=20 >>> Please do read and respond to the list. Remember that responses are = required to gauge consensus, silence is not consent. >>>=20 >>> =E2=80=94Sandy, speaking as wg co-chair >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Tue Jun 27 04: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 55ADF12955F; Tue, 27 Jun 2017 04:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 5jc-JsYTsfpg; Tue, 27 Jun 2017 04:04:12 -0700 (PDT) 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 4C521126B6E; Tue, 27 Jun 2017 04:04:12 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dPoHw-0002ti-KX; Tue, 27 Jun 2017 13:04:09 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-35.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dPoHw-0003UY-D2; Tue, 27 Jun 2017 13:04:08 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Bruijnzeels In-Reply-To: <9ACE1099-C5F3-48A3-BE97-649BDA8123BC@zdns.cn> Date: Tue, 27 Jun 2017 13:04:07 +0200 Cc: Mehmet Adalier , sidr , sidr chairs Content-Transfer-Encoding: quoted-printable Message-Id: <184B0473-C763-495C-92F2-8C93B303E4B5@ripe.net> References: <801A5228-4DF6-4882-A2A9-77B9BAD58871@tislabs.com> <87ACB275-5A80-427B-A6D6-D888CC72E03C@tislabs.com> <5D93CE9B-B802-4014-A3B8-F8B3A2F42456@antarateknik.com> <9ACE1099-C5F3-48A3-BE97-649BDA8123BC@zdns.cn> To: Declan Ma X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719c3295e58993c5384debde18958d38759 Archived-At: Subject: Re: [sidr] once more with feeling! WGLC for draft-ietf-sidr-slurm-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 11:04:14 -0000 > On 27 Jun 2017, at 06:19, Declan Ma wrote: >=20 >> 2) Regarding keys, =E2=80=9Conly in combination with an asserted ASN = for that key,=E2=80=9D not on the key alone >=20 >=20 > I think it=E2=80=99s reasonable to make it obliged to do filtering on = the SKI in combination with an asserted ASN.=20 >=20 > We authors will be figuring out how to get this done after WGLC. Or.. should we only allow filtering on asserted ASN? Is there a good use = case for saying: =E2=80=9CI know *this* key is bad for *this* ASN, but I = am willing to accept assertions by this same ASN for other keys?=E2=80=9D I kind of suspect that if you don=E2=80=99t trust one of the assertions = made by the ASN (for whatever reason), you probably don=E2=80=99t want = to trust any of their assertions. Tim From nobody Tue Jun 27 04:16: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 D3E7B1296C9 for ; Tue, 27 Jun 2017 04:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zdns.cn 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 Z88dxTfQZf7F for ; Tue, 27 Jun 2017 04:16:08 -0700 (PDT) Received: from mail.zdns.cn (smtp.zdns.cn [202.173.10.13]) (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 D10DB1286D6 for ; Tue, 27 Jun 2017 04:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zdns.cn; s=dkim; x=1499166968; i=madi@zdns.cn; h=Content-Type: Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; bh=XWF1kOnsV iPRP/vVKh+gqabMxm0fEY+iNPSnUHCiYtw=; b=VqegbR5IZ8Y+MJ1BM5/CpPdJL G+XG5p5+I0MQx9JyRKbdLfMEiv+udggP/B9XRnrbnirVWzVFdWxMC6wxaMSF7IN5 a2joVDTSgrhOzF5l8tnZ8iz4zGmgZiqOPWuEfB5OgjED21ChCpVvcSj04yJyPr3D OkZs3UFtYTpo7ixJHI= X-TM-DID: 7b9e397347d80c854e4f54186c401e41 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Declan Ma In-Reply-To: <184B0473-C763-495C-92F2-8C93B303E4B5@ripe.net> Date: Tue, 27 Jun 2017 19:15:40 +0800 Cc: Mehmet Adalier , sidr , sidr chairs Content-Transfer-Encoding: quoted-printable Message-Id: <1926242A-6DE6-457D-97F3-C012613F720E@zdns.cn> References: <801A5228-4DF6-4882-A2A9-77B9BAD58871@tislabs.com> <87ACB275-5A80-427B-A6D6-D888CC72E03C@tislabs.com> <5D93CE9B-B802-4014-A3B8-F8B3A2F42456@antarateknik.com> <9ACE1099-C5F3-48A3-BE97-649BDA8123BC@zdns.cn> <184B0473-C763-495C-92F2-8C93B303E4B5@ripe.net> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sidr] once more with feeling! WGLC for draft-ietf-sidr-slurm-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 11:16:11 -0000 > =D4=DA 2017=C4=EA6=D4=C227=C8=D5=A3=AC19:04=A3=ACTim Bruijnzeels = =D0=B4=B5=C0=A3=BA >=20 >=20 >> On 27 Jun 2017, at 06:19, Declan Ma wrote: >>=20 >>> 2) Regarding keys, =A1=B0only in combination with an asserted ASN = for that key,=A1=B1 not on the key alone >>=20 >>=20 >> I think it=A1=AFs reasonable to make it obliged to do filtering on = the SKI in combination with an asserted ASN.=20 >>=20 >> We authors will be figuring out how to get this done after WGLC. >=20 > Or.. should we only allow filtering on asserted ASN? Is there a good = use case for saying: =A1=B0I know *this* key is bad for *this* ASN, but = I am willing to accept assertions by this same ASN for other keys?=A1=B1 There is a use case. An ASN holder authorized more than one routers to do BGP announcements. = Yet the peering ISP just wants to ignore one of the routers, with other = authorized routers remaining unaffected. >=20 > I kind of suspect that if you don=A1=AFt trust one of the assertions = made by the ASN (for whatever reason), you probably don=A1=AFt want to = trust any of their assertions. It has nothing to do with the trust on ASN. I believe we should keep = this as a chance for local control. Di= From nobody Tue Jun 27 04:55: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 945F3129AD3; Tue, 27 Jun 2017 04:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 gip_-KbXPKm8; Tue, 27 Jun 2017 04:55:40 -0700 (PDT) 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 3F76F129AD0; Tue, 27 Jun 2017 04:55:40 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dPp5l-0004ce-7F; Tue, 27 Jun 2017 13:55:37 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-35.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dPp5l-00014t-1S; Tue, 27 Jun 2017 13:55:37 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Bruijnzeels In-Reply-To: <1926242A-6DE6-457D-97F3-C012613F720E@zdns.cn> Date: Tue, 27 Jun 2017 13:55:36 +0200 Cc: Mehmet Adalier , sidr , sidr chairs Content-Transfer-Encoding: quoted-printable Message-Id: <3B35C337-D848-4995-A238-9DEBEB36920F@ripe.net> References: <801A5228-4DF6-4882-A2A9-77B9BAD58871@tislabs.com> <87ACB275-5A80-427B-A6D6-D888CC72E03C@tislabs.com> <5D93CE9B-B802-4014-A3B8-F8B3A2F42456@antarateknik.com> <9ACE1099-C5F3-48A3-BE97-649BDA8123BC@zdns.cn> <184B0473-C763-495C-92F2-8C93B303E4B5@ripe.net> <1926242A-6DE6-457D-97F3-C012613F720E@zdns.cn> To: Declan Ma X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07194b0432086b150926e9081678198c7597 Archived-At: Subject: Re: [sidr] once more with feeling! WGLC for draft-ietf-sidr-slurm-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 11:55:42 -0000 > On 27 Jun 2017, at 13:15, Declan Ma wrote: >=20 >=20 >> =E5=9C=A8 2017=E5=B9=B46=E6=9C=8827=E6=97=A5=EF=BC=8C19:04=EF=BC=8CTim = Bruijnzeels =E5=86=99=E9=81=93=EF=BC=9A >>=20 >>=20 >>> On 27 Jun 2017, at 06:19, Declan Ma wrote: >>>=20 >>>> 2) Regarding keys, =E2=80=9Conly in combination with an asserted = ASN for that key,=E2=80=9D not on the key alone >>>=20 >>>=20 >>> I think it=E2=80=99s reasonable to make it obliged to do filtering = on the SKI in combination with an asserted ASN.=20 >>>=20 >>> We authors will be figuring out how to get this done after WGLC. >>=20 >> Or.. should we only allow filtering on asserted ASN? Is there a good = use case for saying: =E2=80=9CI know *this* key is bad for *this* ASN, = but I am willing to accept assertions by this same ASN for other = keys?=E2=80=9D >=20 > There is a use case. >=20 > An ASN holder authorized more than one routers to do BGP = announcements. Yet the peering ISP just wants to ignore one of the = routers, with other authorized routers remaining unaffected. >=20 >=20 >>=20 >> I kind of suspect that if you don=E2=80=99t trust one of the = assertions made by the ASN (for whatever reason), you probably don=E2=80=99= t want to trust any of their assertions. >=20 > It has nothing to do with the trust on ASN. I believe we should keep = this as a chance for local control. >=20 > Di Thanks for explaining, makes sense to me :) Tim