From nobody Mon Jul 2 05:57:38 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E67E12F1AC for ; Mon, 2 Jul 2018 05:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 YP2MNpCDR54Y for ; Mon, 2 Jul 2018 05:57:34 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 6D0E51292AD for ; Mon, 2 Jul 2018 05:57:34 -0700 (PDT) Received: from [IPv6:2a04:b900::1:55e4:e020:65be:3b61] (unknown [IPv6:2a04:b900:0:1:55e4:e020:65be:3b61]) by dicht.nlnetlabs.nl (Postfix) with ESMTPS id E41B9DA5A; Mon, 2 Jul 2018 14:57:32 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl From: Tim Bruijnzeels Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D2115097-5BBA-4467-8903-213A5D6F56E1" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 2 Jul 2018 14:57:32 +0200 In-Reply-To: Cc: "sidrops@ietf.org" To: Keyur Patel References: X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 12:57:37 -0000 --Apple-Mail=_D2115097-5BBA-4467-8903-213A5D6F56E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Keyer, WG, Time permitting I would like to present on the Signed TAL document = again. I have done so before, e.g. asking for input whether unplanned = rolls should be supported. But.. I found I did not get a very clear = response from the WG on this. To make things more tangible I want to focus on: 1) limiting the scope to just planned key rolls (as the -01 document = does) 2) lessons from 5011 (and I will be doing some more homework on that = between now and 16 July..) Kind regards Tim Bruijnzeels > On 27 Jun 2018, at 18:41, Keyur Patel > wrote: >=20 > Hi folks, > =20 > SIDROPS will meet at IETF-102 on Monday, July 16th from 1:30 pm - 3:30 = pm. Please forward any SIDROPS agenda items you may have to Chris and = me. Please also make sure that your slides are available to the chairs = by Friday morning (07/13/2018). Slides received after the deadline may = not be available for use during the meeting. > =20 > Regards, > Chris and Keyur > =20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops = --Apple-Mail=_D2115097-5BBA-4467-8903-213A5D6F56E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Keyer, WG,

Time permitting I would = like to present on the Signed TAL document again. I have done so before, = e.g. asking for input whether unplanned rolls should be supported. But.. = I found I did not get a very clear response from the WG on = this.

To make = things more tangible I want to focus on:
1) = limiting the scope to just planned key rolls (as the -01 document = does)
2) lessons from 5011 (and I will be doing = some more homework on that between now and 16 July..)


Kind regards

Tim Bruijnzeels


On 27 Jun 2018, at 18:41, Keyur Patel <keyur@arrcus.com> = wrote:

Hi folks,
 
SIDROPS will meet at IETF-102 on Monday, July 16th from 1:30 = pm - 3:30 pm. Please forward any SIDROPS agenda items you may have to = Chris and me. Please also make sure that your slides are available to = the chairs by Friday morning (07/13/2018). Slides received after the = deadline may not be available for use during the meeting.
 
Regards,
Chris = and Keyur
 
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

= --Apple-Mail=_D2115097-5BBA-4467-8903-213A5D6F56E1-- From nobody Mon Jul 2 08:23:07 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D40C130E67 for ; Mon, 2 Jul 2018 08:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=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 LUcrn8BAEC1x for ; Mon, 2 Jul 2018 08:23:02 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0084.outbound.protection.outlook.com [104.47.34.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5695512777C for ; Mon, 2 Jul 2018 08:23:02 -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:X-MS-Exchange-SenderADCheck; bh=dtomyMkiWCHEGGYIbNIqBqUTDMHGemc4YtPlMgFyctk=; b=kBbLpXUbfC26V7Vl3q52/+XIKtAf2l9f3AjJVTalxb1xGAGmEFI+OogMUjer2q6XKkSkblHbEyUBiWkA54KkFP9VODnPAwYruN8bVc0ByfgqR0yYph04/xUz2U6Dwi+R9VS3UYAZtgb9A+SuwdvysX0+Au24iOuzPrCPddD3eko= Received: from BY2PR18MB0328.namprd18.prod.outlook.com (10.163.192.30) by BY2PR18MB0247.namprd18.prod.outlook.com (10.163.72.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.25; Mon, 2 Jul 2018 15:22:59 +0000 Received: from BY2PR18MB0328.namprd18.prod.outlook.com ([fe80::490c:7a3a:e2b4:63e1]) by BY2PR18MB0328.namprd18.prod.outlook.com ([fe80::490c:7a3a:e2b4:63e1%5]) with mapi id 15.20.0906.026; Mon, 2 Jul 2018 15:22:59 +0000 From: Keyur Patel To: Tim Bruijnzeels CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] Call for SIDROPS WG Agenda Items Thread-Index: AQHUDjWkQ6ql/ANObkKLfHN2R3SZEaR76SAA//+2OAA= Date: Mon, 2 Jul 2018 15:22:59 +0000 Message-ID: <434C4E96-CB2B-4F6A-8971-41D701F1F420@arrcus.com> References: <2B88672A-8862-4B5A-ABAC-BEB582684678@opennetlabs.nl> In-Reply-To: <2B88672A-8862-4B5A-ABAC-BEB582684678@opennetlabs.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [75.8.210.205] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR18MB0247; 7:z0gfZApCSaCKoLXQq8TPe0gXTH1ZYQNhmhyujBydF+v3ydX5Bqm1ecbkEPG6yLfWs9nGgEu6VfOi93XwM2z/qKDxTeBbPnc0N0y6MWHyhSxgZudCTKE2AwA09CECpYMZIywBuPqkFYoogucYTybAIcl9YZ6C7wZzwZ4/MHURK8kVJXaiOyyyXZsZtjEonfwUKy2aUU8otv3H9dcrNXKDs0z/i/WzHep9WU1N8aJDhQz6bHboKiEWS0kDz+8Yyi9k x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 70fc9255-1cc7-471d-dadb-08d5e02fb1f0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989117)(5600053)(711020)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:BY2PR18MB0247; x-ms-traffictypediagnostic: BY2PR18MB0247: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(20161123564045)(20161123558120)(2016111802025)(20161123562045)(6072148)(6043046)(201708071742011)(7699016); SRVR:BY2PR18MB0247; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0247; x-forefront-prvs: 07215D0470 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39830400003)(136003)(366004)(396003)(199004)(189003)(8676002)(316002)(81156014)(81166006)(478600001)(966005)(2900100001)(26005)(6436002)(97736004)(606006)(14454004)(446003)(229853002)(36756003)(8936002)(6116002)(3846002)(11346002)(2616005)(256004)(99286004)(54896002)(5250100002)(6306002)(6512007)(83716003)(76176011)(236005)(6486002)(53546011)(6916009)(6506007)(33656002)(102836004)(486006)(53936002)(186003)(68736007)(25786009)(106356001)(476003)(2906002)(5660300001)(86362001)(82746002)(7736002)(105586002)(6246003)(4326008)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0247; H:BY2PR18MB0328.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: rpd4nY9FyTGFNPIZoLly4E+mIYPRq15bV25Qt9zMv2C20YB+Fj/KCTqs0DErzca9H2hT50jmdFUvoIVUVHi4Fn9Hyqw8OXk8XTyassq6YDtuHkBN9nXbmkfbcZ5DLuOPBMq/fztWkO225aG4CTJMabRx0Q4FtVE4VaxT4k4Ub/8mEpQrK9VauyBYIYWJKuoY017ri8r/7dhJz8twVSsmWP9BlOoU7z3G7Q3M2Ie8Xm8jRs1H7NVpWo5fZOcrUl2yufjEr2fobRJXkxwOD+lOtwM3wdwSph00Z+87B9GYUEOpgmieUByP0seBYIFYeyEYQ7KMNAJnYhwAyvDmvi5eK02/8GiNgmKhDXPTtosxSKs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_434C4E96CB2B4F6A897141D701F1F420arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: 70fc9255-1cc7-471d-dadb-08d5e02fb1f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2018 15:22:59.4558 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0247 Archived-At: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 15:23:05 -0000 --_000_434C4E96CB2B4F6A897141D701F1F420arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9uZS4gVGhhbmtzLg0KDQpSZWdhcmRzLA0KS2V5dXINCg0KRnJvbTogVGltIEJydWlqbnplZWxz IDx0aW1Ab3Blbm5ldGxhYnMubmw+DQpEYXRlOiBNb25kYXksIEp1bHkgMiwgMjAxOCBhdCA1OjQ3 IEFNDQpUbzogS2V5dXIgUGF0ZWwgPGtleXVyQGFycmN1cy5jb20+DQpDYzogInNpZHJvcHNAaWV0 Zi5vcmciIDxzaWRyb3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtTaWRyb3BzXSBDYWxsIGZv ciBTSURST1BTIFdHIEFnZW5kYSBJdGVtcw0KDQpIaSBLZXllciwgV0csDQoNClRpbWUgcGVybWl0 dGluZyBJIHdvdWxkIGxpa2UgdG8gcHJlc2VudCBvbiB0aGUgU2lnbmVkIFRBTCBkb2N1bWVudCBh Z2Fpbi4gSSBoYXZlIGRvbmUgc28gYmVmb3JlLCBlLmcuIGFza2luZyBmb3IgaW5wdXQgd2hldGhl ciB1bnBsYW5uZWQgcm9sbHMgc2hvdWxkIGJlIHN1cHBvcnRlZC4gQnV0Li4gSSBmb3VuZCBJIGRp ZCBub3QgZ2V0IGEgdmVyeSBjbGVhciByZXNwb25zZSBmcm9tIHRoZSBXRyBvbiB0aGlzLg0KDQpU byBtYWtlIHRoaW5ncyBtb3JlIHRhbmdpYmxlIEkgd2FudCB0byBmb2N1cyBvbjoNCjEpIGxpbWl0 aW5nIHRoZSBzY29wZSB0byBqdXN0IHBsYW5uZWQga2V5IHJvbGxzIChhcyB0aGUgLTAxIGRvY3Vt ZW50IGRvZXMpDQoyKSBsZXNzb25zIGZyb20gNTAxMSAoYW5kIEkgd2lsbCBiZSBkb2luZyBzb21l IG1vcmUgaG9tZXdvcmsgb24gdGhhdCBiZXR3ZWVuIG5vdyBhbmQgMTYgSnVseS4uKQ0KDQoNCktp bmQgcmVnYXJkcw0KDQpUaW0gQnJ1aWpuemVlbHMNCg0KDQoNCk9uIDI3IEp1biAyMDE4LCBhdCAx ODo0MSwgS2V5dXIgUGF0ZWwgPGtleXVyQGFycmN1cy5jb208bWFpbHRvOmtleXVyQGFycmN1cy5j b20+PiB3cm90ZToNCg0KSGkgZm9sa3MsDQoNClNJRFJPUFMgd2lsbCBtZWV0IGF0IElFVEYtMTAy IG9uIE1vbmRheSwgSnVseSAxNnRoIGZyb20gMTozMCBwbSAtIDM6MzAgcG0uIFBsZWFzZSBmb3J3 YXJkIGFueSBTSURST1BTIGFnZW5kYSBpdGVtcyB5b3UgbWF5IGhhdmUgdG8gQ2hyaXMgYW5kIG1l LiBQbGVhc2UgYWxzbyBtYWtlIHN1cmUgdGhhdCB5b3VyIHNsaWRlcyBhcmUgYXZhaWxhYmxlIHRv IHRoZSBjaGFpcnMgYnkgRnJpZGF5IG1vcm5pbmcgKDA3LzEzLzIwMTgpLiBTbGlkZXMgcmVjZWl2 ZWQgYWZ0ZXIgdGhlIGRlYWRsaW5lIG1heSBub3QgYmUgYXZhaWxhYmxlIGZvciB1c2UgZHVyaW5n IHRoZSBtZWV0aW5nLg0KDQpSZWdhcmRzLA0KQ2hyaXMgYW5kIEtleXVyDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTaWRyb3BzIG1haWxpbmcgbGlz dA0KU2lkcm9wc0BpZXRmLm9yZzxtYWlsdG86U2lkcm9wc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkcm9wcw0KDQo= --_000_434C4E96CB2B4F6A897141D701F1F420arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <8EEDCBB672FC3649A1BD0D5539C859C0@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG9uZS4gVGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2V5dXI8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlRpbSBCcnVpam56ZWVs cyAmbHQ7dGltQG9wZW5uZXRsYWJzLm5sJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIEp1 bHkgMiwgMjAxOCBhdCA1OjQ3IEFNPGJyPg0KPGI+VG86IDwvYj5LZXl1ciBQYXRlbCAmbHQ7a2V5 dXJAYXJyY3VzLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3NpZHJvcHNAaWV0Zi5vcmcm cXVvdDsgJmx0O3NpZHJvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBb U2lkcm9wc10gQ2FsbCBmb3IgU0lEUk9QUyBXRyBBZ2VuZGEgSXRlbXM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxPcmln aW5hbEJvZHkiPkhpIEtleWVyLCBXRywgPG86cD48L286cD48L2E+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PlRpbWUgcGVybWl0dGluZyBJIHdvdWxkIGxpa2UgdG8gcHJlc2VudCBvbiB0aGUgU2lnbmVkIFRB TCBkb2N1bWVudCBhZ2Fpbi4gSSBoYXZlIGRvbmUgc28gYmVmb3JlLCBlLmcuIGFza2luZyBmb3Ig aW5wdXQgd2hldGhlciB1bnBsYW5uZWQgcm9sbHMgc2hvdWxkIGJlIHN1cHBvcnRlZC4gQnV0Li4g SSBmb3VuZCBJIGRpZCBub3QgZ2V0DQogYSB2ZXJ5IGNsZWFyIHJlc3BvbnNlIGZyb20gdGhlIFdH IG9uIHRoaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+VG8g bWFrZSB0aGluZ3MgbW9yZSB0YW5naWJsZSBJIHdhbnQgdG8gZm9jdXMgb246PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+MSkgbGltaXRpbmcgdGhlIHNjb3Bl IHRvIGp1c3QgcGxhbm5lZCBrZXkgcm9sbHMgKGFzIHRoZSAtMDEgZG9jdW1lbnQgZG9lcyk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4yKSBsZXNzb25zIGZy b20gNTAxMSAoYW5kIEkgd2lsbCBiZSBkb2luZyBzb21lIG1vcmUgaG9tZXdvcmsgb24gdGhhdCBi ZXR3ZWVuIG5vdyBhbmQgMTYgSnVseS4uKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPktpbmQgcmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPlRpbSBCcnVpam56ZWVsczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij5PbiAyNyBKdW4gMjAxOCwgYXQgMTg6NDEsIEtleXVyIFBhdGVsICZsdDs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOmtleXVyQGFycmN1cy5jb20iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPmtleXVyQGFycmN1cy5jb208L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mZ3Q7DQogd3JvdGU6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPkhpIGZvbGtzLDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86 cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPlNJRFJPUFMgd2lsbCBtZWV0IGF0IElFVEYtMTAyIG9u IE1vbmRheSwgSnVseSAxNnRoIGZyb20gMTozMCBwbSAtIDM6MzAgcG0uIFBsZWFzZSBmb3J3YXJk IGFueSBTSURST1BTIGFnZW5kYSBpdGVtcyB5b3UgbWF5IGhhdmUgdG8gQ2hyaXMgYW5kIG1lLiBQ bGVhc2UgYWxzbyBtYWtlIHN1cmUgdGhhdCB5b3VyIHNsaWRlcyBhcmUgYXZhaWxhYmxlDQogdG8g dGhlIGNoYWlycyBieSBGcmlkYXkgbW9ybmluZyAoMDcvMTMvMjAxOCkuIFNsaWRlcyByZWNlaXZl ZCBhZnRlciB0aGUgZGVhZGxpbmUgbWF5IG5vdCBiZSBhdmFpbGFibGUgZm9yIHVzZSBkdXJpbmcg dGhlIG1lZXRpbmcuPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9z cGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5DaHJpcyBhbmQmbmJzcDtL ZXl1cjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KU2lkcm9wcyBtYWlsaW5n IGxpc3Q8YnI+DQo8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86U2lkcm9wc0BpZXRmLm9yZyI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6Izk1NEY3MiI+U2lkcm9w c0BpZXRmLm9yZzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl dGljYSI+PGJyPg0KPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij48L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zaWRyb3BzIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj YTtjb2xvcjojOTU0RjcyIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Np ZHJvcHM8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_434C4E96CB2B4F6A897141D701F1F420arrcuscom_-- From nobody Mon Jul 2 09:50:16 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A25130DDE; Fri, 29 Jun 2018 10:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfAaRoUDBZvt; Fri, 29 Jun 2018 10:14:25 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 37C6F130DDC; Fri, 29 Jun 2018 10:14:25 -0700 (PDT) Received: from correu-1.ac.upc.es (correu-1.ac.upc.es [147.83.30.91]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id w5THEDQn030964; Fri, 29 Jun 2018 19:14:13 +0200 Received: from [147.83.35.225] (dync-35-225.ac.upc.es [147.83.35.225]) by correu-1.ac.upc.es (Postfix) with ESMTPSA id 851D21D8; Fri, 29 Jun 2018 19:14:08 +0200 (CEST) References: <153028668788.30332.9615982545028670114.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Jordi_Pailliss=c3=a9_Vilanova?= To: sidrops@ietf.org, din@irtf.org, Stephane Bortzmeyer , sandy@tislabs.com, Greg Skinner , leo@vegoda.org, "natal@cisco.com" , Vina Ermagan , Fabio Maino , Albert Cabellos , opsec@ietf.org X-Forwarded-Message-Id: <153028668788.30332.9615982545028670114.idtracker@ietfa.amsl.com> Message-ID: Date: Fri, 29 Jun 2018 19:14:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <153028668788.30332.9615982545028670114.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------6517C357FD281E5EC18C425E" Content-Language: en-US Archived-At: X-Mailman-Approved-At: Mon, 02 Jul 2018 09:50:14 -0700 Subject: [Sidrops] blockchain for IP addresses draft update X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 17:14:30 -0000 This is a multi-part message in MIME format. --------------6517C357FD281E5EC18C425E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit (apologies for cross-posting) Dear all, We have submitted a new version of the draft addressing comments received both on the mailing list and IETF meetings. Thanks to all of you for taking the time to read the draft :) Regards, Jordi -------- Missatge reenviat -------- Assumpte: New Version Notification for draft-paillisse-sidrops-blockchain-02.txt Data: Fri, 29 Jun 2018 08:38:07 -0700 De: internet-drafts@ietf.org A: Alberto Rodriguez-Natal , Vina Ermagan , Leo Vegoda , Albert Cabellos , Albert Cabellos-Aparicio , Jordi Paillisse , Fabio Maino A new version of I-D, draft-paillisse-sidrops-blockchain-02.txt has been successfully submitted by Jordi Paillisse and posted to the IETF repository. Name: draft-paillisse-sidrops-blockchain Revision: 02 Title: An analysis of the applicability of blockchain to secure IP addresses allocation, delegation and bindings. Document date: 2018-06-28 Group: Individual Submission Pages: 30 URL: https://www.ietf.org/internet-drafts/draft-paillisse-sidrops-blockchain-02.txt Status: https://datatracker.ietf.org/doc/draft-paillisse-sidrops-blockchain/ Htmlized: https://tools.ietf.org/html/draft-paillisse-sidrops-blockchain-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-paillisse-sidrops-blockchain Diff: https://www.ietf.org/rfcdiff?url2=draft-paillisse-sidrops-blockchain-02 Abstract: This document analyzes how blockchain technology can be used to secure the allocation, delegation and binding to topological information of the IP address space. The main outcomes of the analysis are that blockchain is suitable in environments with multiple distrusting parties and that Proof of Stake is a potential candidate for a consensus algorithm. 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. The IETF Secretariat --------------6517C357FD281E5EC18C425E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

(apologies for cross-posting)

Dear all,

We have submitted a new version of the draft addressing comments received both on the mailing list and IETF meetings.

Thanks to all of you for taking the time to read the draft :)

Regards,

Jordi

-------- Missatge reenviat --------
Assumpte: New Version Notification for draft-paillisse-sidrops-blockchain-02.txt
Data: Fri, 29 Jun 2018 08:38:07 -0700
De: internet-drafts@ietf.org
A: Alberto Rodriguez-Natal <natal@cisco.com>, Vina Ermagan <vermagan@cisco.com>, Leo Vegoda <leo@vegoda.org>, Albert Cabellos <acabello@ac.upc.edu>, Albert Cabellos-Aparicio <acabello@ac.upc.edu>, Jordi Paillisse <jordip@ac.upc.edu>, Fabio Maino <fmaino@cisco.com> 


A new version of I-D, draft-paillisse-sidrops-blockchain-02.txt
has been successfully submitted by Jordi Paillisse and posted to the
IETF repository.

Name:		draft-paillisse-sidrops-blockchain
Revision:	02
Title:		An analysis of the applicability of blockchain to secure IP addresses allocation, delegation and bindings.
Document date:	2018-06-28
Group:		Individual Submission
Pages:		30
URL:            https://www.ietf.org/internet-drafts/draft-paillisse-sidrops-blockchain-02.txt
Status:         https://datatracker.ietf.org/doc/draft-paillisse-sidrops-blockchain/
Htmlized:       https://tools.ietf.org/html/draft-paillisse-sidrops-blockchain-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-paillisse-sidrops-blockchain
Diff:           https://www.ietf.org/rfcdiff?url2=draft-paillisse-sidrops-blockchain-02

Abstract:
   This document analyzes how blockchain technology can be used to
   secure the allocation, delegation and binding to topological
   information of the IP address space.  The main outcomes of the
   analysis are that blockchain is suitable in environments with
   multiple distrusting parties and that Proof of Stake is a potential
   candidate for a consensus algorithm.

                                                                                  


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.

The IETF Secretariat
--------------6517C357FD281E5EC18C425E-- From nobody Mon Jul 2 09:50:21 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45010131232; Mon, 2 Jul 2018 08:59:21 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=scs.stanford.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFQIl9RJswMN; Mon, 2 Jul 2018 08:59:19 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (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 498901311F7; Mon, 2 Jul 2018 08:59:19 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.16.0.21/8.16.0.21) with ESMTP id w62Fx78L007573; Mon, 2 Jul 2018 08:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scs.stanford.edu; s=scs; t=1530547147; bh=J4+IAUYnsSmQd294Zlx/YfbQ+1TD14gjIJI2Wd5xxJs=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version; b=D3iOOmqNAhcS+RbA53lbjOlCFukofkhdErCxcUvj2banA7eKdsvlDgSz1+8bJbIRQ 35fyD7N4w7TO0bR11pqudzygknnPAhAVTfZWAIrLgRJ6tijB8618gPiaygtA0Iuw5d PTuwVQVtmfjcjPrXHv59bxqlGfonVPwSztelDJr8= Received: (from dm@localhost) by market.scs.stanford.edu (8.16.0.21/8.16.0.21/Submit) id w62Fx52u043820; Mon, 2 Jul 2018 08:59:05 -0700 (PDT) From: David Mazieres To: Jordi =?utf-8?Q?Pailliss=C3=A9?= Vilanova , sidrops@ietf.org, din@irtf.org, Stephane Bortzmeyer , sandy@tislabs.com, Greg Skinner , leo@vegoda.org, "natal\@cisco.com" , Vina Ermagan , Fabio Maino , Albert Cabellos , opsec@ietf.org In-Reply-To: References: <153028668788.30332.9615982545028670114.idtracker@ietfa.amsl.com> Reply-To: David Mazieres expires 2018-09-30 PDT Date: Mon, 02 Jul 2018 08:59:10 -0700 Message-ID: <87lgat633l.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Mon, 02 Jul 2018 09:50:14 -0700 Subject: Re: [Sidrops] [Din] blockchain for IP addresses draft update X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 15:59:30 -0000 Jordi Pailliss=C3=A9 Vilanova writes: > (apologies for cross-posting) > > Dear all, > > We have submitted a new version of the draft addressing comments=20 > received both on the mailing list and IETF meetings. > > Thanks to all of you for taking the time to read the draft :) > > Regards, > > Jordi Very interesting draft. One high-level comment, I would avoid terms like "tamper-proof" or really anything-"proof" except possibly in the context of information-theoretic security, in favor of tamper-resistant. This is particularly important in the context of blockchains that have experienced a number of forks in practice and where it would likely take only a few tens of millions of dollars a day to tamper with history. I think the draft would benefit from a much finer-grained consideration of several different forms of proof-of-stake, because there are a number of assertions that do not hold for all forms of proof of stake. E.g., will there be delegation like peercoin, randomization like algorand, penalties like Casper, sleepy nodes like snowwhite? And while of course I'm biased on this issue, I think that a Byzantine-agreement-based approach like SCP (https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/) would work better than PoS. SCP is well matched to the Internet peering model, which we already know is a workable decentralized governance model. You may not agree, but it would at least be nice for the document to explain why you reject this approach. David From nobody Mon Jul 2 16:46:16 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA24B13148B for ; Mon, 2 Jul 2018 16:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-k74xXtL16Z for ; Mon, 2 Jul 2018 16:46:05 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 6AA36131459 for ; Mon, 2 Jul 2018 16:45:56 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id 69-v6so377070wmf.3 for ; Mon, 02 Jul 2018 16:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zUGSPvUNDdOAhbpzy0prz6Cx8UK2EWx1rVr4DdmLGtI=; b=VTASbRJazSmEUGk9d+zxFBfNKIGSJ3/eHnAWbbZxwheeXcwetMdFSjQxTKBKvLUIFB Dihv9mocf9NDKAq6rYyiQusQjy5SN0MY/1N8tmpBxxELhrQBgEHSuRePmRK3zFJQqmMg 3Gm5GYSCfCq5NMlrZ6WOK32knKVXqJwubbl0qmYAhaUTeqjeL0oQwzni+kCIhUrrB/L/ F3NI20ojdCJz8kuU4rbS/Oc/Md9gITLH/gVY/A4a5fYVMxYU8LiMOZU3VsHRHE1cdKBo SxWQtWZV+hXPUvwY6kP638A/8nStryAIm+1S18PGupUjVCPzJvw9alkW9Kci0uNDt30b hsIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zUGSPvUNDdOAhbpzy0prz6Cx8UK2EWx1rVr4DdmLGtI=; b=ayKnZeeTU1yeTt8WmiSqFC7qu1+ZuM5HZdPBTSOay7Gt2b7wJplMMZdOfvilkokMz+ 1GAiYTrR+u7U+VLKOlUnNzwjMhmRgLzJ1rAqKSWmOKVO53kw2jfDZBJ8UpB4F32KMUwx fuoortUwRqfqz+yjK6miqX046ZocHEUe9Kh6lk6KT6P5rIjNtkWNX0ZBbqzi9aB1on05 Pd6NxdKH44vnD1v/LuM35tPfXOe5JWfpg1I/abo2jh0J0zEiRCzfztewN7sOjlgrJy/d CWJQytSPteMiU3ON83mFBDyLC7u5wKo0V+r68qTkIxYapNdlGzXOXJrkcxHQJI606hh1 n+Ig== X-Gm-Message-State: APt69E0NDyyhazJOXygGhHMJORexagiLyJbRTT+hw0AS46V9EtNtb8at 3JhbhYUIDGTR0sn0bOKDy1U1z6JqdPQdK+l6CEezaTUV X-Google-Smtp-Source: AAOMgpc73mud2DpNCNC3rUN0KCeoO2TDOf+bc4WYgMi5IZRPwX3K1vB8IKp8NHtSMIVW3xkhjQIBjYwBkg9l3SJV7cw= X-Received: by 2002:a1c:b609:: with SMTP id g9-v6mr8721985wmf.73.1530575154957; Mon, 02 Jul 2018 16:45:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:12cb:0:0:0:0:0 with HTTP; Mon, 2 Jul 2018 16:45:54 -0700 (PDT) X-Originating-IP: [2001:dc0:2001:210:b0e6:8ae3:c68e:4a98] In-Reply-To: <434C4E96-CB2B-4F6A-8971-41D701F1F420@arrcus.com> References: <2B88672A-8862-4B5A-ABAC-BEB582684678@opennetlabs.nl> <434C4E96-CB2B-4F6A-8971-41D701F1F420@arrcus.com> From: George Michaelson Date: Tue, 3 Jul 2018 09:45:54 +1000 Message-ID: To: Keyur Patel Cc: Tim Bruijnzeels , "sidrops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 23:46:15 -0000 we aren't presenting a draft at this time, I just have slides. Its a conversation. -George On Tue, Jul 3, 2018 at 1:22 AM, Keyur Patel wrote: > Done. Thanks. > > > > Regards, > > Keyur > > > > From: Tim Bruijnzeels > Date: Monday, July 2, 2018 at 5:47 AM > To: Keyur Patel > Cc: "sidrops@ietf.org" > Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items > > > > Hi Keyer, WG, > > > > Time permitting I would like to present on the Signed TAL document again. I > have done so before, e.g. asking for input whether unplanned rolls should be > supported. But.. I found I did not get a very clear response from the WG on > this. > > > > To make things more tangible I want to focus on: > > 1) limiting the scope to just planned key rolls (as the -01 document does) > > 2) lessons from 5011 (and I will be doing some more homework on that between > now and 16 July..) > > > > > > Kind regards > > > > Tim Bruijnzeels > > > > > > On 27 Jun 2018, at 18:41, Keyur Patel wrote: > > > > Hi folks, > > > > SIDROPS will meet at IETF-102 on Monday, July 16th from 1:30 pm - 3:30 pm. > Please forward any SIDROPS agenda items you may have to Chris and me. Please > also make sure that your slides are available to the chairs by Friday > morning (07/13/2018). Slides received after the deadline may not be > available for use during the meeting. > > > > Regards, > > Chris and Keyur > > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > > > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > From nobody Tue Jul 3 09:02:19 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE78130FEB; Tue, 3 Jul 2018 09:00:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: sidrops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063361437.4893.13840992872522722818.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:14 -0700 Archived-At: Subject: [Sidrops] sidrops - Requested session has been scheduled for IETF 102 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.26 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:00:22 -0000 Dear Chris Morrow, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sidrops Session 1 (1:30 requested) Monday, 16 July 2018, Afternoon Session I 1330-1530 Room Name: Viger size: 200 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/sidrops.ics Request Information: --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Chris Morrow Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: idr grow Second Priority: opsarea opsec Third Priority: opsawg People who must be present: Keyur Patel Alvaro Retana Chris Morrow Warren Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jul 3 16:02:01 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64AB130E20 for ; Tue, 3 Jul 2018 16:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vwu-M1Y82jO0 for ; Tue, 3 Jul 2018 16:01:56 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A6F130E11 for ; Tue, 3 Jul 2018 16:01:56 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id s11-v6so3456912wra.13 for ; Tue, 03 Jul 2018 16:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GobGYBLywDM9Z3H8hPEIOUXq8oqcwWqysLUGJXCo4uM=; b=y45T1IPamunPahTx5fYwrjmvJaZd96Ro3NI6H21ygGSmlzG9li/yEQjU9MUSHlexV5 mrKNTwwpQkmnJOf3210xTRpoBxOQDo7l9VJJ+BIwAmoIIyoxO6oK4RHKjueuRylHb89H 7cjcaNDBPV2USP4ShdwYX9ltVNM+ygOelmbKX2ZFqZ4QJhudTlbF6wRlBLdmLmkt3eqc u/X3Q+qIQ86r4cq+CpIQm4+hAEEZMBDpGXao6qNVhDuI14DySS/wlCwDyay1Szh4gOWU 98B/TBXBNUd2pnP6h0Aq33qToEH0bpWbrEDvOgFo3zbH80Hjz+5NYnViwt2YL1ssowPT J45g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GobGYBLywDM9Z3H8hPEIOUXq8oqcwWqysLUGJXCo4uM=; b=K/GAmmzIOeaMIcdll2RyJEhEtdktJ6S0c0bNr6sev7FbmtfgOwT/qiHmIeLW/yclMx LHFGZEf5XIBy2jqor4v8qX9L5pkaGRRQ9N0AL3EBvAn1xddyJvmeqC0OAM9ycU7S3q6B ShUtp2g7don9pPu3QWrq0rkMxNOzfc+MwO/vQ7TlxvwGXDLrjyjisc3QIlxg5VgR5/w5 yXPERyq+LnjSxoJ1h7oNoaFujOFmObdXIYlA9eHH2od/BfphlIC5bJO8XKD7f43n8JR5 nxO2mxC9Ehk+UVBApD/S+pJEBosGoMoxA8WF43YhLQ6XJw1GIUM52ZcOVgwD3/dA3HvM LlmA== X-Gm-Message-State: APt69E0yW7SH0JN728dlkhA+Hl+rN6zA14eeGtSz1o6kIXxQOiO8v4DM aN88zxGGK5rDkXv9bgCw3tm3TxRbiV/pxXMxm5d/Vba6 X-Google-Smtp-Source: AAOMgpeEgJxnJ1P+QkWkoYPhNf7dbnq+JzU7upjBgNEwXazeH9nLvPYBhyux1TZm0Iu3aLT3tfPbEH+sjBbxlfhTmrA= X-Received: by 2002:adf:fe46:: with SMTP id m6-v6mr23171806wrs.171.1530658915102; Tue, 03 Jul 2018 16:01:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:12cb:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 16:01:54 -0700 (PDT) X-Originating-IP: [2001:dc0:2001:210:8197:399f:317b:d6b0] In-Reply-To: References: <2B88672A-8862-4B5A-ABAC-BEB582684678@opennetlabs.nl> <434C4E96-CB2B-4F6A-8971-41D701F1F420@arrcus.com> From: George Michaelson Date: Wed, 4 Jul 2018 09:01:54 +1000 Message-ID: To: Tim Bruijnzeels Cc: Keyur Patel , "sidrops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 23:02:00 -0000 On Tue, Jul 3, 2018 at 5:55 PM, Tim Bruijnzeels wrote: > Hi George, > > Just to be clear. You are referring here to validation deployment planning, right. yes. I have asked for 5-10 minutes to talk about validation deployment planning, there is no published draft to be presented at this meeting on that topic, its just a conversation right now. -George > > Tim > >> On 3 Jul 2018, at 01:45, George Michaelson wrote: >> >> we aren't presenting a draft at this time, I just have slides. Its a >> conversation. >> >> -George >> >> On Tue, Jul 3, 2018 at 1:22 AM, Keyur Patel wrote: >>> Done. Thanks. >>> >>> >>> >>> Regards, >>> >>> Keyur >>> >>> >>> >>> From: Tim Bruijnzeels >>> Date: Monday, July 2, 2018 at 5:47 AM >>> To: Keyur Patel >>> Cc: "sidrops@ietf.org" >>> Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items >>> >>> >>> >>> Hi Keyer, WG, >>> >>> >>> >>> Time permitting I would like to present on the Signed TAL document again. I >>> have done so before, e.g. asking for input whether unplanned rolls should be >>> supported. But.. I found I did not get a very clear response from the WG on >>> this. >>> >>> >>> >>> To make things more tangible I want to focus on: >>> >>> 1) limiting the scope to just planned key rolls (as the -01 document does) >>> >>> 2) lessons from 5011 (and I will be doing some more homework on that between >>> now and 16 July..) >>> >>> >>> >>> >>> >>> Kind regards >>> >>> >>> >>> Tim Bruijnzeels >>> >>> >>> >>> >>> >>> On 27 Jun 2018, at 18:41, Keyur Patel wrote: >>> >>> >>> >>> Hi folks, >>> >>> >>> >>> SIDROPS will meet at IETF-102 on Monday, July 16th from 1:30 pm - 3:30 pm. >>> Please forward any SIDROPS agenda items you may have to Chris and me. Please >>> also make sure that your slides are available to the chairs by Friday >>> morning (07/13/2018). Slides received after the deadline may not be >>> available for use during the meeting. >>> >>> >>> >>> Regards, >>> >>> Chris and Keyur >>> >>> >>> >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >>> >>> >>> >>> >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >>> > From nobody Thu Jul 5 03:01:56 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7674130DC1 for ; Thu, 5 Jul 2018 03:01:53 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 JRl5lRXBzP_L for ; Thu, 5 Jul 2018 03:01:50 -0700 (PDT) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 4BCC1130EA3 for ; Thu, 5 Jul 2018 03:01:50 -0700 (PDT) Received: from [IPv6:2a04:b900::1:f59a:a5aa:f298:6f81] (unknown [IPv6:2a04:b900:0:1:f59a:a5aa:f298:6f81]) by dicht.nlnetlabs.nl (Postfix) with ESMTPS id 9831989B4; Thu, 5 Jul 2018 12:01:48 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl From: Tim Bruijnzeels Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1078071B-9A9E-4310-A1C7-3976DE8F76DE" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 5 Jul 2018 12:01:48 +0200 In-Reply-To: Cc: Keyur Patel , "sidrops@ietf.org" , George Michaelson To: Alexander Azimov References: <6065B77B-9981-4273-82CD-A13C3151EA24@arrcus.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 10:01:54 -0000 --Apple-Mail=_1078071B-9A9E-4310-A1C7-3976DE8F76DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alexander, Nice drafts! I have some questions that may come back when you present, = but let me ask here as well. In-line > On 28 Jun 2018, at 15:57, Alexander Azimov wrote: >=20 > I would like to reserve 15 minutes for: > https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-profile/ = Since it=E2=80=99s the customer ASN who signs would it be a good idea if = they listed all provider ASNs in a single object? There is no fate = sharing risk like we have in ROAs when including multiple signing = prefixes. On the other hand this would guarantee atomicity. One small thing, eventually this will need a filename extension to be = included in the IANA =E2=80=9CRPKI Repository Name Scheme=E2=80=9D = registry. See also: https://tools.ietf.org/html/rfc6481#section-7.2 = > = https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-verification/ = = I am not entirely clear on the AS_PATH verification in section 5. It = reads to me like the outcome is invalid, or unverifiable if not all of = the ASNs on the path have published ASPAs. And that unverifiable is = considered close to invalid. But I may have misunderstood.. so I would = be particularly interested in this part of your presentation. All that said, I think that it would be extremely useful if a partial, = incremental deployment can be supported. IMHO one of the big issues with = BGPSec deployment is that it=E2=80=99s all or nothing, so there really = is no incentive to deploy until everybody else has done so. With ASPAs = you could argue that a route should be dropped if any of the pairs in = the path turns out to be invalid, but it=E2=80=99s okay to accept = unknowns. This would allow ASNs to get benefits from publishing ASPAs = without requiring that everyone else does so as well. Of course things = will be better when they do as well, but until that time there still is = a benefit. So, there is incentive for ASNs to be pro-active. But as I said.. I am not sure that I got this section 5 completely.. Regards, Tim >=20 > 2018-06-28 1:33 GMT+03:00 Keyur Patel >: > Done. Thanks. >=20 > Regards, > Keyur >=20 > > On Jun 27, 2018, at 3:32 PM, George Michaelson > wrote: > >=20 > > I have been asked by my RIR colleagues to talk about modified > > validation deployment planning. I think about 10 minutes should do = it. > >=20 > > cheers > >=20 > > -george > >=20 > >> On Thu, Jun 28, 2018 at 6:34 AM, Keyur Patel > wrote: > >> Done. Thanks. > >>=20 > >> Regards, > >> Keyur > >>=20 > >> =EF=BB=BFOn 6/27/18, 1:32 PM, "Randy Bush" > wrote: > >>=20 > >>> SIDROPS will meet at IETF-102 on Monday, July 16th from 1:30 pm - = 3:30 > >>> pm. Please forward any SIDROPS agenda items you may have to Chris = and > >>> me. Please also make sure that your slides are available to the = chairs > >>> by Friday morning (07/13/2018). Slides received after the deadline = may > >>> not be available for use during the meeting. > >>=20 > >> i would appreciate 10-15 minutes to discuss > >>=20 > >> draft-ymbk-sidrops-ov-signal-01 > >>=20 > >> i do NOT plan to present it. folk who want to discuss it and/or = have > >> questions MUST have read it beforehand. > >>=20 > >> randy > >>=20 > >>=20 > >> _______________________________________________ > >> Sidrops mailing list > >> Sidrops@ietf.org > >> https://www.ietf.org/mailman/listinfo/sidrops = > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops = >=20 >=20 >=20 > --=20 > | Alexander Azimov | HLL l QRATOR > | tel.: +7 499 241 81 92 > | mob.: +7 915 360 08 86 > | skype: mitradir > | mailto: aa@qrator.net > | visit: www.qrator.net = _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --Apple-Mail=_1078071B-9A9E-4310-A1C7-3976DE8F76DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Alexander,

Nice = drafts! I have some questions that may come back when you present, but = let me ask here as well.

In-line

On 28 Jun 2018, at 15:57, = Alexander Azimov <aa@qrator.net> wrote:

I would like to reserve 15 minutes for:
https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-prof= ile/

Since it=E2=80=99s the customer ASN who signs = would it be a good idea if they listed all provider ASNs in a single = object? There is no fate sharing risk like we have in ROAs when = including multiple signing prefixes. On the other hand this would = guarantee atomicity.

One small = thing, eventually this will need a filename extension to be included in = the IANA =E2=80=9CRPKI Repository Name Scheme=E2=80=9D registry. See = also:
<= br class=3D"">
https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-veri= fication/

I am not entirely clear on the AS_PATH = verification in section 5. It reads to me like the outcome is invalid, = or unverifiable if not all of the ASNs on the path have published ASPAs. = And that unverifiable is considered close to invalid. But I may have = misunderstood.. so I would be particularly interested in this part of = your presentation.

All that said, I = think that it would be extremely useful if a partial, incremental = deployment can be supported. IMHO one of the big issues with BGPSec = deployment is that it=E2=80=99s all or nothing, so there really is no = incentive to deploy until everybody else has done so. With ASPAs you = could argue that a route should be dropped if any of the pairs in the = path turns out to be invalid, but it=E2=80=99s okay to accept unknowns. = This would allow ASNs to get benefits from publishing ASPAs without = requiring that everyone else does so as well. Of course things will be = better when they do as well, but until that time there still is a = benefit. So, there is incentive for ASNs to be pro-active.

But as I said.. I am not sure that I got this = section 5 completely..

Regards,

Tim



2018-06-28= 1:33 GMT+03:00 Keyur Patel <keyur@arrcus.com>:
Done. Thanks.

Regards,
Keyur

> On Jun 27, 2018, at 3:32 PM, George Michaelson <ggm@algebras.org> = wrote:
>
> I have been asked by my RIR colleagues to talk about modified
> validation deployment planning. I think about 10 minutes should do = it.
>
> cheers
>
> -george
>
>> On Thu, Jun 28, 2018 at 6:34 AM, Keyur Patel <keyur@arrcus.com> = wrote:
>> Done. Thanks.
>>
>> Regards,
>> Keyur
>>
>> =EF=BB=BFOn 6/27/18, 1:32 PM, "Randy Bush" <randy@psg.com> wrote:
>>
>>> SIDROPS will meet at IETF-102 on Monday, July 16th from = 1:30 pm - 3:30
>>> pm. Please forward any SIDROPS agenda items you may have to = Chris and
>>> me. Please also make sure that your slides are available to = the chairs
>>> by Friday morning (07/13/2018). Slides received after the = deadline may
>>> not be available for use during the meeting.
>>
>>    i would appreciate 10-15 minutes to discuss
>>
>>        draft-ymbk-sidrops-ov-signal-01
>>
>>    i do NOT plan to present it.  folk who want = to discuss it and/or have
>>    questions MUST have read it beforehand.
>>
>>    randy
>>
>>
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidrops
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops



--
| Alexander Azimov  | = HLL l QRATOR
| tel.: +7 499 241 81 = 92
| mob.: +7 915 360 08 = 86
| skype: = mitradir
| mailto: aa@qrator.net
| visit: www.qrator.net
_______________________________________________
Sidrops = mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

= --Apple-Mail=_1078071B-9A9E-4310-A1C7-3976DE8F76DE-- From nobody Fri Jul 6 09:43:43 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51AD130E3B; Wed, 4 Jul 2018 04:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7RDy6qVhZrF; Wed, 4 Jul 2018 04:28:33 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8F952130DCE; Wed, 4 Jul 2018 04:28:32 -0700 (PDT) Received: from correu-2.ac.upc.es (correu-2.ac.upc.es [147.83.30.92]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id w64BSGja007150; Wed, 4 Jul 2018 13:28:16 +0200 Received: from [147.83.35.225] (dync-35-225.ac.upc.es [147.83.35.225]) by correu-2.ac.upc.es (Postfix) with ESMTPSA id 5EC98165; Wed, 4 Jul 2018 13:28:11 +0200 (CEST) To: David Mazieres expires 2018-09-30 PDT , sidrops@ietf.org, din@irtf.org, Stephane Bortzmeyer , sandy@tislabs.com, Greg Skinner , leo@vegoda.org, "natal@cisco.com" , Vina Ermagan , Fabio Maino , Albert Cabellos , opsec@ietf.org References: <153028668788.30332.9615982545028670114.idtracker@ietfa.amsl.com> <87lgat633l.fsf@ta.scs.stanford.edu> From: =?UTF-8?Q?Jordi_Pailliss=c3=a9_Vilanova?= Message-ID: Date: Wed, 4 Jul 2018 13:28:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <87lgat633l.fsf@ta.scs.stanford.edu> Content-Type: multipart/alternative; boundary="------------556A0A05FB0DA42423EC9986" Content-Language: en-GB Archived-At: X-Mailman-Approved-At: Fri, 06 Jul 2018 09:43:41 -0700 Subject: Re: [Sidrops] [Din] blockchain for IP addresses draft update X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 11:28:37 -0000 This is a multi-part message in MIME format. --------------556A0A05FB0DA42423EC9986 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi David, Indeed, we did not delve deeper into the PoS algorithm. This depends on the specific implementation, our opinion is that an Algroand-like would be a good option, and if it can tolerate a large portion of offline participants even better. In addition, we think that punishing or deposit mechanisms are not desirable because they don't fit the characteristics of the scenario. Overall the incentive is "a more secure Internet", we believe that this is well-aligned with the economical interests of the participants. Regarding SCP, the fact that you only need to trust your neighbours may prove very convenient in this scenario. As you said, it reflects current Internet trust schemes, this basically means that BGP Peering = Trust = Stellar quorum slices. We'll look into this for the next iteration of the draft. Thanks Jordi El 02/07/18 a les 17:59, David Mazieres ha escrit: > Jordi Paillissé Vilanova writes: > >> (apologies for cross-posting) >> >> Dear all, >> >> We have submitted a new version of the draft addressing comments >> received both on the mailing list and IETF meetings. >> >> Thanks to all of you for taking the time to read the draft :) >> >> Regards, >> >> Jordi > Very interesting draft. One high-level comment, I would avoid terms > like "tamper-proof" or really anything-"proof" except possibly in the > context of information-theoretic security, in favor of tamper-resistant. > This is particularly important in the context of blockchains that have > experienced a number of forks in practice and where it would likely take > only a few tens of millions of dollars a day to tamper with history. > > I think the draft would benefit from a much finer-grained consideration > of several different forms of proof-of-stake, because there are a number > of assertions that do not hold for all forms of proof of stake. E.g., > will there be delegation like peercoin, randomization like algorand, > penalties like Casper, sleepy nodes like snowwhite? > > And while of course I'm biased on this issue, I think that a > Byzantine-agreement-based approach like SCP > (https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/) would work > better than PoS. SCP is well matched to the Internet peering model, > which we already know is a workable decentralized governance model. You > may not agree, but it would at least be nice for the document to explain > why you reject this approach. > > David --------------556A0A05FB0DA42423EC9986 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi David,

Indeed, we did not delve deeper into the PoS algorithm. This depends on the specific implementation, our opinion is that an Algroand-like would be a good option, and if it can tolerate a large portion of offline participants even better. In addition, we think that punishing or deposit mechanisms are not desirable because they don't fit the characteristics of the scenario. Overall the incentive is "a more secure Internet", we believe that this is well-aligned with the economical interests of the participants.

Regarding SCP, the fact that you only need to trust your neighbours may prove very convenient in this scenario. As you said, it reflects current Internet trust schemes, this basically means that BGP Peering = Trust = Stellar quorum slices. We'll look into this for the next iteration of the draft.

Thanks

Jordi


El 02/07/18 a les 17:59, David Mazieres ha escrit:
Jordi Paillissé Vilanova <jordip@ac.upc.edu> writes:


(apologies for cross-posting)

Dear all,

We have submitted a new version of the draft addressing comments 
received both on the mailing list and IETF meetings.

Thanks to all of you for taking the time to read the draft :)

Regards,

Jordi

Very interesting draft.  One high-level comment, I would avoid terms
like "tamper-proof" or really anything-"proof" except possibly in the
context of information-theoretic security, in favor of tamper-resistant.
This is particularly important in the context of blockchains that have
experienced a number of forks in practice and where it would likely take
only a few tens of millions of dollars a day to tamper with history.

I think the draft would benefit from a much finer-grained consideration
of several different forms of proof-of-stake, because there are a number
of assertions that do not hold for all forms of proof of stake.  E.g.,
will there be delegation like peercoin, randomization like algorand,
penalties like Casper, sleepy nodes like snowwhite?

And while of course I'm biased on this issue, I think that a
Byzantine-agreement-based approach like SCP
(https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/) would work
better than PoS.  SCP is well matched to the Internet peering model,
which we already know is a workable decentralized governance model.  You
may not agree, but it would at least be nice for the document to explain
why you reject this approach.

David

--------------556A0A05FB0DA42423EC9986-- From nobody Fri Jul 6 09:43:49 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E298130E06; Wed, 4 Jul 2018 05:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 Gpcqgx3vDYUb; Wed, 4 Jul 2018 05:09:10 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B438D130DC2; Wed, 4 Jul 2018 05:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17626; q=dns/txt; s=iport; t=1530706150; x=1531915750; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=NzkZmiVK3+330cARcbpPSwcOWYOZKWcGM2QJj2AEWNk=; b=HWeSp3aT1ZNNlX1tgLC7HfNEpei1HhuUGVTJPZHNoFVGrYvPORkWHgjQ f7uBZ8OsTHUF4XjNfW+fKWgsTppTzxxCShAjumgGEPun3KAHWhe4Damor DupmMimKmKxIJyR5KV6wdvm8TkBC3uBBu0PWKaYOf7LZG06ofEaGb8qVa E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAgA1uDxb/5tdJa1cDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGCU3ZifygKg3CUIRmCB5AfhQ4UgWYLI4RJAheCDCE1FwE?= =?us-ascii?q?CAQECAQECbRwMhTYBAQEEI0cEGwIBCBEDAQIoAwICAjAUCQgCBAESgyABgRt?= =?us-ascii?q?kD6gughyDegEBhFeBNQWIRyaBVj+BNoFqUC6DGAIDAYEkWBaCSzGCJAKHQIo?= =?us-ascii?q?nh2UJAoYEiRqBQIZ3hSCHe4I6hy0CERMBgSQeATaBPQ0IcBU7KgGCPoIkF4h?= =?us-ascii?q?ZhQQEATVvAY5hAiQEA4EBgRoBAQ?= X-IronPort-AV: E=Sophos;i="5.51,306,1526342400"; d="scan'208,217";a="138540286" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2018 12:09:09 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w64C99s7017895 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Jul 2018 12:09:09 GMT Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 4 Jul 2018 08:09:08 -0400 Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1320.000; Wed, 4 Jul 2018 08:09:08 -0400 From: "Roque Gagliano (rogaglia)" To: =?utf-8?B?Sm9yZGkgUGFpbGxpc3PDqSBWaWxhbm92YQ==?= , David Mazieres expires 2018-09-30 PDT , "sidrops@ietf.org" , "din@irtf.org" , Stephane Bortzmeyer , "sandy@tislabs.com" , Greg Skinner , "leo@vegoda.org" , "Alberto Rodriguez Natal (natal)" , "Vina Ermagan (vermagan)" , "Fabio Maino (fmaino)" , Albert Cabellos , "opsec@ietf.org" Thread-Topic: [OPSEC] [Din] blockchain for IP addresses draft update Thread-Index: AQHUEh4PNQ99JdAUUUS0yUmJnadF4KR/Mv+AgAAs94A= Date: Wed, 4 Jul 2018 12:09:08 +0000 Message-ID: <9BC0DE80-D827-414B-916B-C102C3460563@cisco.com> References: <153028668788.30332.9615982545028670114.idtracker@ietfa.amsl.com> <87lgat633l.fsf@ta.scs.stanford.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.172.244] Content-Type: multipart/alternative; boundary="_000_9BC0DE80D827414B916BC102C3460563ciscocom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 06 Jul 2018 09:43:41 -0700 Subject: Re: [Sidrops] [OPSEC] [Din] blockchain for IP addresses draft update X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 12:09:15 -0000 --_000_9BC0DE80D827414B916BC102C3460563ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9yZGksDQoNClZlcnkgZ29vZCBkb2N1bWVudC4NCg0KSSBoYXRlIHRvIGFzayB0aGluZ3Mg d2l0aG91dCBwcm92aWRpbmcgY29kZSBidXQgSSBiZWxpZXZlIGl0IHdvdWxkIGJlIGdyZWF0IGlm IHlvdSBhZGQgYSBzZWN0aW9uIHJlZ2FyZGluZyB0aGUg4oCccmVseWluZyBwYXJ0eeKAnSwgaG93 IHdvdWxkIHRoZSB2YWxpZGF0aW9uIGFsZ29yaXRobSB3b3VsZCBsb29rIGxpa2UgYW5kIHdoYXQg aXMgdGhlIGJvb3RzdHJhcCBwcm9jZXNzLiBJIGNhbiBzZWUgdGhhdCBzb21lIHB1YmxpYyBrZXkg aW5mbyB3b3VsZCBuZWVkIHRvIGJlIGtub3duIGJ5IHRoZSBSUC4NCg0KUmVnYXJkcywNClJvcXVl DQoNCg0KRnJvbTogT1BTRUMgPG9wc2VjLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBK b3JkaSBQYWlsbGlzc8OpIFZpbGFub3ZhIDxqb3JkaXBAYWMudXBjLmVkdT4NCkRhdGU6IFdlZG5l c2RheSA0IEp1bHkgMjAxOCBhdCAxMzoyOA0KVG86IERhdmlkIE1hemllcmVzIGV4cGlyZXMgMjAx OC0wOS0zMCBQRFQgPG1hemllcmVzLXBlYmFncjd5c2pnaHdwcWtjcXFuampmNHRhQHRlbXBvcmFy eS1hZGRyZXNzLnNjcy5zdGFuZm9yZC5lZHU+LCAic2lkcm9wc0BpZXRmLm9yZyIgPHNpZHJvcHNA aWV0Zi5vcmc+LCAiZGluQGlydGYub3JnIiA8ZGluQGlydGYub3JnPiwgU3RlcGhhbmUgQm9ydHpt ZXllciA8Ym9ydHptZXllckBuaWMuZnI+LCAic2FuZHlAdGlzbGFicy5jb20iIDxzYW5keUB0aXNs YWJzLmNvbT4sIEdyZWcgU2tpbm5lciA8Z3JlZ3NraW5uZXIwQGljbG91ZC5jb20+LCAibGVvQHZl Z29kYS5vcmciIDxsZW9AdmVnb2RhLm9yZz4sICJBbGJlcnRvIFJvZHJpZ3VleiBOYXRhbCAobmF0 YWwpIiA8bmF0YWxAY2lzY28uY29tPiwgIlZpbmEgRXJtYWdhbiAodmVybWFnYW4pIiA8dmVybWFn YW5AY2lzY28uY29tPiwgIkZhYmlvIE1haW5vIChmbWFpbm8pIiA8Zm1haW5vQGNpc2NvLmNvbT4s IEFsYmVydCBDYWJlbGxvcyA8YWNhYmVsbG9AYWMudXBjLmVkdT4sICJvcHNlY0BpZXRmLm9yZyIg PG9wc2VjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPUFNFQ10gW0Rpbl0gYmxvY2tjaGFpbiBm b3IgSVAgYWRkcmVzc2VzIGRyYWZ0IHVwZGF0ZQ0KDQoNCkhpIERhdmlkLA0KDQpJbmRlZWQsIHdl IGRpZCBub3QgZGVsdmUgZGVlcGVyIGludG8gdGhlIFBvUyBhbGdvcml0aG0uIFRoaXMgZGVwZW5k cyBvbiB0aGUgc3BlY2lmaWMgaW1wbGVtZW50YXRpb24sIG91ciBvcGluaW9uIGlzIHRoYXQgYW4g QWxncm9hbmQtbGlrZSB3b3VsZCBiZSBhIGdvb2Qgb3B0aW9uLCBhbmQgaWYgaXQgY2FuIHRvbGVy YXRlIGEgbGFyZ2UgcG9ydGlvbiBvZiBvZmZsaW5lIHBhcnRpY2lwYW50cyBldmVuIGJldHRlci4g SW4gYWRkaXRpb24sIHdlIHRoaW5rIHRoYXQgcHVuaXNoaW5nIG9yIGRlcG9zaXQgbWVjaGFuaXNt cyBhcmUgbm90IGRlc2lyYWJsZSBiZWNhdXNlIHRoZXkgZG9uJ3QgZml0IHRoZSBjaGFyYWN0ZXJp c3RpY3Mgb2YgdGhlIHNjZW5hcmlvLiBPdmVyYWxsIHRoZSBpbmNlbnRpdmUgaXMgImEgbW9yZSBz ZWN1cmUgSW50ZXJuZXQiLCB3ZSBiZWxpZXZlIHRoYXQgdGhpcyBpcyB3ZWxsLWFsaWduZWQgd2l0 aCB0aGUgZWNvbm9taWNhbCBpbnRlcmVzdHMgb2YgdGhlIHBhcnRpY2lwYW50cy4NCg0KUmVnYXJk aW5nIFNDUCwgdGhlIGZhY3QgdGhhdCB5b3Ugb25seSBuZWVkIHRvIHRydXN0IHlvdXIgbmVpZ2hi b3VycyBtYXkgcHJvdmUgdmVyeSBjb252ZW5pZW50IGluIHRoaXMgc2NlbmFyaW8uIEFzIHlvdSBz YWlkLCBpdCByZWZsZWN0cyBjdXJyZW50IEludGVybmV0IHRydXN0IHNjaGVtZXMsIHRoaXMgYmFz aWNhbGx5IG1lYW5zIHRoYXQgQkdQIFBlZXJpbmcgPSBUcnVzdCA9IFN0ZWxsYXIgcXVvcnVtIHNs aWNlcy4gV2UnbGwgbG9vayBpbnRvIHRoaXMgZm9yIHRoZSBuZXh0IGl0ZXJhdGlvbiBvZiB0aGUg ZHJhZnQuDQoNClRoYW5rcw0KDQpKb3JkaQ0KDQpFbCAwMi8wNy8xOCBhIGxlcyAxNzo1OSwgRGF2 aWQgTWF6aWVyZXMgaGEgZXNjcml0Og0KDQpKb3JkaSBQYWlsbGlzc8OpIFZpbGFub3ZhIDxqb3Jk aXBAYWMudXBjLmVkdT48bWFpbHRvOmpvcmRpcEBhYy51cGMuZWR1PiB3cml0ZXM6DQoNCg0KDQoo YXBvbG9naWVzIGZvciBjcm9zcy1wb3N0aW5nKQ0KDQoNCg0KRGVhciBhbGwsDQoNCg0KDQpXZSBo YXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBhZGRyZXNzaW5nIGNvbW1l bnRzDQoNCnJlY2VpdmVkIGJvdGggb24gdGhlIG1haWxpbmcgbGlzdCBhbmQgSUVURiBtZWV0aW5n cy4NCg0KDQoNClRoYW5rcyB0byBhbGwgb2YgeW91IGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcmVh ZCB0aGUgZHJhZnQgOikNCg0KDQoNClJlZ2FyZHMsDQoNCg0KDQpKb3JkaQ0KDQpWZXJ5IGludGVy ZXN0aW5nIGRyYWZ0LiAgT25lIGhpZ2gtbGV2ZWwgY29tbWVudCwgSSB3b3VsZCBhdm9pZCB0ZXJt cw0KDQpsaWtlICJ0YW1wZXItcHJvb2YiIG9yIHJlYWxseSBhbnl0aGluZy0icHJvb2YiIGV4Y2Vw dCBwb3NzaWJseSBpbiB0aGUNCg0KY29udGV4dCBvZiBpbmZvcm1hdGlvbi10aGVvcmV0aWMgc2Vj dXJpdHksIGluIGZhdm9yIG9mIHRhbXBlci1yZXNpc3RhbnQuDQoNClRoaXMgaXMgcGFydGljdWxh cmx5IGltcG9ydGFudCBpbiB0aGUgY29udGV4dCBvZiBibG9ja2NoYWlucyB0aGF0IGhhdmUNCg0K ZXhwZXJpZW5jZWQgYSBudW1iZXIgb2YgZm9ya3MgaW4gcHJhY3RpY2UgYW5kIHdoZXJlIGl0IHdv dWxkIGxpa2VseSB0YWtlDQoNCm9ubHkgYSBmZXcgdGVucyBvZiBtaWxsaW9ucyBvZiBkb2xsYXJz IGEgZGF5IHRvIHRhbXBlciB3aXRoIGhpc3RvcnkuDQoNCg0KDQpJIHRoaW5rIHRoZSBkcmFmdCB3 b3VsZCBiZW5lZml0IGZyb20gYSBtdWNoIGZpbmVyLWdyYWluZWQgY29uc2lkZXJhdGlvbg0KDQpv ZiBzZXZlcmFsIGRpZmZlcmVudCBmb3JtcyBvZiBwcm9vZi1vZi1zdGFrZSwgYmVjYXVzZSB0aGVy ZSBhcmUgYSBudW1iZXINCg0Kb2YgYXNzZXJ0aW9ucyB0aGF0IGRvIG5vdCBob2xkIGZvciBhbGwg Zm9ybXMgb2YgcHJvb2Ygb2Ygc3Rha2UuICBFLmcuLA0KDQp3aWxsIHRoZXJlIGJlIGRlbGVnYXRp b24gbGlrZSBwZWVyY29pbiwgcmFuZG9taXphdGlvbiBsaWtlIGFsZ29yYW5kLA0KDQpwZW5hbHRp ZXMgbGlrZSBDYXNwZXIsIHNsZWVweSBub2RlcyBsaWtlIHNub3d3aGl0ZT8NCg0KDQoNCkFuZCB3 aGlsZSBvZiBjb3Vyc2UgSSdtIGJpYXNlZCBvbiB0aGlzIGlzc3VlLCBJIHRoaW5rIHRoYXQgYQ0K DQpCeXphbnRpbmUtYWdyZWVtZW50LWJhc2VkIGFwcHJvYWNoIGxpa2UgU0NQDQoNCihodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tYXppZXJlcy1kaW5yZy1zY3AvKSB3b3Vs ZCB3b3JrDQoNCmJldHRlciB0aGFuIFBvUy4gIFNDUCBpcyB3ZWxsIG1hdGNoZWQgdG8gdGhlIElu dGVybmV0IHBlZXJpbmcgbW9kZWwsDQoNCndoaWNoIHdlIGFscmVhZHkga25vdyBpcyBhIHdvcmth YmxlIGRlY2VudHJhbGl6ZWQgZ292ZXJuYW5jZSBtb2RlbC4gIFlvdQ0KDQptYXkgbm90IGFncmVl LCBidXQgaXQgd291bGQgYXQgbGVhc3QgYmUgbmljZSBmb3IgdGhlIGRvY3VtZW50IHRvIGV4cGxh aW4NCg0Kd2h5IHlvdSByZWplY3QgdGhpcyBhcHByb2FjaC4NCg0KDQoNCkRhdmlkDQoNCg0K --_000_9BC0DE80D827414B916BC102C3460563ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <00879672BE7E5B4392948F6B3925BC61@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5pbQ0KCXttc28tc3R5bGUtbmFtZTppbTt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEpvcmRpLDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5WZXJ5IGdvb2QgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgaGF0ZSB0byBhc2sgdGhpbmdzIHdpdGhvdXQgcHJvdmlkaW5nIGNvZGUgYnV0IEkg YmVsaWV2ZSBpdCB3b3VsZCBiZSBncmVhdCBpZiB5b3UgYWRkIGEgc2VjdGlvbiByZWdhcmRpbmcg dGhlIOKAnHJlbHlpbmcgcGFydHnigJ0sIGhvdyB3b3VsZCB0aGUgdmFsaWRhdGlvbiBhbGdvcml0 aG0gd291bGQgbG9vayBsaWtlIGFuZCB3aGF0IGlzIHRoZSBib290c3RyYXAgcHJvY2Vzcy4gSSBj YW4gc2VlIHRoYXQgc29tZSBwdWJsaWMNCiBrZXkgaW5mbyB3b3VsZCBuZWVkIHRvIGJlIGtub3du IGJ5IHRoZSBSUC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJvcXVlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5PUFNFQyAmbHQ7b3BzZWMtYm91bmNlc0Bp ZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEpvcmRpIFBhaWxsaXNzw6kgVmlsYW5vdmEgJmx0O2pv cmRpcEBhYy51cGMuZWR1Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXkgNCBKdWx5IDIw MTggYXQgMTM6Mjg8YnI+DQo8Yj5UbzogPC9iPkRhdmlkIE1hemllcmVzIGV4cGlyZXMgMjAxOC0w OS0zMCBQRFQgJmx0O21hemllcmVzLXBlYmFncjd5c2pnaHdwcWtjcXFuampmNHRhQHRlbXBvcmFy eS1hZGRyZXNzLnNjcy5zdGFuZm9yZC5lZHUmZ3Q7LCAmcXVvdDtzaWRyb3BzQGlldGYub3JnJnF1 b3Q7ICZsdDtzaWRyb3BzQGlldGYub3JnJmd0OywgJnF1b3Q7ZGluQGlydGYub3JnJnF1b3Q7ICZs dDtkaW5AaXJ0Zi5vcmcmZ3Q7LCBTdGVwaGFuZSBCb3J0em1leWVyICZsdDtib3J0em1leWVyQG5p Yy5mciZndDssICZxdW90O3NhbmR5QHRpc2xhYnMuY29tJnF1b3Q7ICZsdDtzYW5keUB0aXNsYWJz LmNvbSZndDssDQogR3JlZyBTa2lubmVyICZsdDtncmVnc2tpbm5lcjBAaWNsb3VkLmNvbSZndDss ICZxdW90O2xlb0B2ZWdvZGEub3JnJnF1b3Q7ICZsdDtsZW9AdmVnb2RhLm9yZyZndDssICZxdW90 O0FsYmVydG8gUm9kcmlndWV6IE5hdGFsIChuYXRhbCkmcXVvdDsgJmx0O25hdGFsQGNpc2NvLmNv bSZndDssICZxdW90O1ZpbmEgRXJtYWdhbiAodmVybWFnYW4pJnF1b3Q7ICZsdDt2ZXJtYWdhbkBj aXNjby5jb20mZ3Q7LCAmcXVvdDtGYWJpbyBNYWlubyAoZm1haW5vKSZxdW90OyAmbHQ7Zm1haW5v QGNpc2NvLmNvbSZndDssIEFsYmVydCBDYWJlbGxvcyAmbHQ7YWNhYmVsbG9AYWMudXBjLmVkdSZn dDssDQogJnF1b3Q7b3BzZWNAaWV0Zi5vcmcmcXVvdDsgJmx0O29wc2VjQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09QU0VDXSBbRGluXSBibG9ja2NoYWluIGZvciBJUCBh ZGRyZXNzZXMgZHJhZnQgdXBkYXRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkhp IERhdmlkLDxicj4NCjxicj4NCkluZGVlZCwgd2UgZGlkIG5vdCBkZWx2ZSBkZWVwZXIgaW50byB0 aGUgUG9TIGFsZ29yaXRobS4gVGhpcyBkZXBlbmRzIG9uIHRoZSBzcGVjaWZpYyBpbXBsZW1lbnRh dGlvbiwgb3VyIG9waW5pb24gaXMgdGhhdCBhbg0KPHNwYW4gY2xhc3M9ImltIj5BbGdyb2FuZC1s aWtlIHdvdWxkIGJlIGEgZ29vZCBvcHRpb24sIGFuZCBpZiBpdCBjYW4gdG9sZXJhdGUgYSBsYXJn ZSBwb3J0aW9uIG9mIG9mZmxpbmUgcGFydGljaXBhbnRzIGV2ZW4gYmV0dGVyLiBJbiBhZGRpdGlv biwgd2UgdGhpbmsgdGhhdCBwdW5pc2hpbmcgb3IgZGVwb3NpdCBtZWNoYW5pc21zIGFyZSBub3Qg ZGVzaXJhYmxlIGJlY2F1c2UgdGhleQ0KPC9zcGFuPmRvbid0IGZpdCB0aGUgY2hhcmFjdGVyaXN0 aWNzIG9mIHRoZSBzY2VuYXJpby4gT3ZlcmFsbCB0aGUgaW5jZW50aXZlIGlzICZxdW90O2EgbW9y ZSBzZWN1cmUgSW50ZXJuZXQmcXVvdDssIHdlIGJlbGlldmUgdGhhdCB0aGlzIGlzIHdlbGwtYWxp Z25lZCB3aXRoIHRoZSBlY29ub21pY2FsIGludGVyZXN0cyBvZiB0aGUgcGFydGljaXBhbnRzLg0K PGJyPg0KPGJyPg0KUmVnYXJkaW5nIFNDUCwgdGhlIGZhY3QgdGhhdCB5b3Ugb25seSBuZWVkIHRv IHRydXN0IHlvdXIgbmVpZ2hib3VycyA8c3BhbiBjbGFzcz0iaW0iPg0KbWF5IHByb3ZlIHZlcnkg Y29udmVuaWVudCBpbiB0aGlzIHNjZW5hcmlvLiBBcyB5b3Ugc2FpZCwgaXQgcmVmbGVjdHMgPC9z cGFuPmN1cnJlbnQgSW50ZXJuZXQgdHJ1c3Qgc2NoZW1lcywgdGhpcyBiYXNpY2FsbHkgbWVhbnMg dGhhdCBCR1AgUGVlcmluZyA9IFRydXN0ID0gU3RlbGxhciBxdW9ydW0gc2xpY2VzLiBXZSdsbCBs b29rIGludG8gdGhpcyBmb3IgdGhlIG5leHQgaXRlcmF0aW9uIG9mIHRoZSBkcmFmdC48YnI+DQo8 YnI+DQpUaGFua3M8YnI+DQo8YnI+DQpKb3JkaTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ RWwgMDIvMDcvMTggYSBsZXMgMTc6NTksIERhdmlkIE1hemllcmVzIGhhIGVzY3JpdDo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkpvcmRp IFBhaWxsaXNzw6kgVmlsYW5vdmEgPGEgaHJlZj0ibWFpbHRvOmpvcmRpcEBhYy51cGMuZWR1Ij4m bHQ7am9yZGlwQGFjLnVwYy5lZHUmZ3Q7PC9hPiB3cml0ZXM6PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4oYXBvbG9naWVzIGZvciBjcm9zcy1wb3N0 aW5nKTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkRl YXIgYWxsLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGFkZHJlc3Npbmcg Y29tbWVudHMgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+cmVjZWl2ZWQgYm90aCBvbiB0aGUgbWFpbGluZyBsaXN0IGFuZCBJRVRGIG1lZXRpbmdzLjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoYW5rcyB0 byBhbGwgb2YgeW91IGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcmVhZCB0aGUgZHJhZnQgOik8bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5SZWdhcmRzLDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkpvcmRpPG86 cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+VmVyeSBpbnRlcmVzdGluZyBkcmFmdC4mbmJzcDsgT25lIGhpZ2gtbGV2ZWwgY29tbWVu dCwgSSB3b3VsZCBhdm9pZCB0ZXJtczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPmxpa2UgJnF1b3Q7dGFtcGVyLXByb29mJnF1b3Q7IG9yIHJlYWxseSBh bnl0aGluZy0mcXVvdDtwcm9vZiZxdW90OyBleGNlcHQgcG9zc2libHkgaW4gdGhlPG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Y29udGV4dCBvZiBpbmZv cm1hdGlvbi10aGVvcmV0aWMgc2VjdXJpdHksIGluIGZhdm9yIG9mIHRhbXBlci1yZXNpc3RhbnQu PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhpcyBp cyBwYXJ0aWN1bGFybHkgaW1wb3J0YW50IGluIHRoZSBjb250ZXh0IG9mIGJsb2NrY2hhaW5zIHRo YXQgaGF2ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PmV4cGVyaWVuY2VkIGEgbnVtYmVyIG9mIGZvcmtzIGluIHByYWN0aWNlIGFuZCB3aGVyZSBpdCB3 b3VsZCBsaWtlbHkgdGFrZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPm9ubHkgYSBmZXcgdGVucyBvZiBtaWxsaW9ucyBvZiBkb2xsYXJzIGEgZGF5IHRv IHRhbXBlciB3aXRoIGhpc3RvcnkuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+SSB0aGluayB0aGUgZHJhZnQgd291bGQgYmVuZWZpdCBmcm9tIGEgbXVj aCBmaW5lci1ncmFpbmVkIGNvbnNpZGVyYXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5vZiBzZXZlcmFsIGRpZmZlcmVudCBmb3JtcyBvZiBwcm9v Zi1vZi1zdGFrZSwgYmVjYXVzZSB0aGVyZSBhcmUgYSBudW1iZXI8bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5vZiBhc3NlcnRpb25zIHRoYXQgZG8gbm90 IGhvbGQgZm9yIGFsbCBmb3JtcyBvZiBwcm9vZiBvZiBzdGFrZS4mbmJzcDsgRS5nLiw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij53aWxsIHRoZXJlIGJl IGRlbGVnYXRpb24gbGlrZSBwZWVyY29pbiwgcmFuZG9taXphdGlvbiBsaWtlIGFsZ29yYW5kLDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnBlbmFsdGll cyBsaWtlIENhc3Blciwgc2xlZXB5IG5vZGVzIGxpa2Ugc25vd3doaXRlPzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkFuZCB3aGlsZSBvZiBjb3Vyc2Ug SSdtIGJpYXNlZCBvbiB0aGlzIGlzc3VlLCBJIHRoaW5rIHRoYXQgYTxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkJ5emFudGluZS1hZ3JlZW1lbnQtYmFz ZWQgYXBwcm9hY2ggbGlrZSBTQ1A8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4oPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtbWF6aWVyZXMtZGlucmctc2NwLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtbWF6aWVyZXMtZGlucmctc2NwLzwvYT4pIHdvdWxkIHdvcms8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5iZXR0ZXIgdGhhbiBQb1MuJm5i c3A7IFNDUCBpcyB3ZWxsIG1hdGNoZWQgdG8gdGhlIEludGVybmV0IHBlZXJpbmcgbW9kZWwsPG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+d2hpY2ggd2Ug YWxyZWFkeSBrbm93IGlzIGEgd29ya2FibGUgZGVjZW50cmFsaXplZCBnb3Zlcm5hbmNlIG1vZGVs LiZuYnNwOyBZb3U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij5tYXkgbm90IGFncmVlLCBidXQgaXQgd291bGQgYXQgbGVhc3QgYmUgbmljZSBmb3IgdGhl IGRvY3VtZW50IHRvIGV4cGxhaW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij53aHkgeW91IHJlamVjdCB0aGlzIGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkRhdmlkPG86cD48L286cD48L3By ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_9BC0DE80D827414B916BC102C3460563ciscocom_-- From nobody Fri Jul 6 09:43:56 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C054130E6C; Wed, 4 Jul 2018 08:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zOPeRILVRne; Wed, 4 Jul 2018 08:50:33 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 93CF112785F; Wed, 4 Jul 2018 08:50:32 -0700 (PDT) Received: from correu-1.ac.upc.es (correu-1.ac.upc.es [147.83.30.91]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id w64FoIqD012465; Wed, 4 Jul 2018 17:50:18 +0200 Received: from [147.83.35.232] (dync-35-232.ac.upc.es [147.83.35.232]) by correu-1.ac.upc.es (Postfix) with ESMTPSA id 1CED1283; Wed, 4 Jul 2018 17:50:13 +0200 (CEST) To: "Roque Gagliano (rogaglia)" , David Mazieres expires 2018-09-30 PDT , "sidrops@ietf.org" , "din@irtf.org" , Stephane Bortzmeyer , "sandy@tislabs.com" , Greg Skinner , "leo@vegoda.org" , "Alberto Rodriguez Natal (natal)" , "Vina Ermagan (vermagan)" , "Fabio Maino (fmaino)" , Albert Cabellos , "opsec@ietf.org" References: <153028668788.30332.9615982545028670114.idtracker@ietfa.amsl.com> <87lgat633l.fsf@ta.scs.stanford.edu> <9BC0DE80-D827-414B-916B-C102C3460563@cisco.com> From: =?UTF-8?Q?Jordi_Pailliss=c3=a9_Vilanova?= Message-ID: <56694f02-cf91-8569-c57f-7f3c319a7e9f@ac.upc.edu> Date: Wed, 4 Jul 2018 17:50:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <9BC0DE80-D827-414B-916B-C102C3460563@cisco.com> Content-Type: multipart/alternative; boundary="------------C635D4B6DCE5FBC5E32EEF32" Content-Language: en-US Archived-At: X-Mailman-Approved-At: Fri, 06 Jul 2018 09:43:41 -0700 Subject: Re: [Sidrops] [OPSEC] [Din] blockchain for IP addresses draft update X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 15:50:40 -0000 This is a multi-part message in MIME format. --------------C635D4B6DCE5FBC5E32EEF32 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Roque, We have built an open-source prototype [1], and it works like you mentioned: the genesis block includes the public keys that the RP has to trust. It is a one-time action in which you trust the source code and the keys contained in it. Thanks for your comments, we'll include them in the next version. Regards, Jordi [1] https://github.com/OpenOverlayRouter/blockchain-mapping-system El 04/07/18 a les 14:09, Roque Gagliano (rogaglia) ha escrit: > > Hi Jordi, > > Very good document. > > I hate to ask things without providing code but I believe it would be > great if you add a section regarding the “relying party”, how would > the validation algorithm would look like and what is the bootstrap > process. I can see that some public key info would need to be known by > the RP. > > Regards, > > Roque > > *From: *OPSEC on behalf of Jordi Paillissé > Vilanova > *Date: *Wednesday 4 July 2018 at 13:28 > *To: *David Mazieres expires 2018-09-30 PDT > , > "sidrops@ietf.org" , "din@irtf.org" , > Stephane Bortzmeyer , "sandy@tislabs.com" > , Greg Skinner , > "leo@vegoda.org" , "Alberto Rodriguez Natal (natal)" > , "Vina Ermagan (vermagan)" , > "Fabio Maino (fmaino)" , Albert Cabellos > , "opsec@ietf.org" > *Subject: *Re: [OPSEC] [Din] blockchain for IP addresses draft update > > Hi David, > > Indeed, we did not delve deeper into the PoS algorithm. This depends > on the specific implementation, our opinion is that an Algroand-like > would be a good option, and if it can tolerate a large portion of > offline participants even better. In addition, we think that punishing > or deposit mechanisms are not desirable because they don't fit the > characteristics of the scenario. Overall the incentive is "a more > secure Internet", we believe that this is well-aligned with the > economical interests of the participants. > > Regarding SCP, the fact that you only need to trust your neighbours > may prove very convenient in this scenario. As you said, it reflects > current Internet trust schemes, this basically means that BGP Peering > = Trust = Stellar quorum slices. We'll look into this for the next > iteration of the draft. > > Thanks > > Jordi > > El 02/07/18 a les 17:59, David Mazieres ha escrit: > > Jordi Paillissé Vilanova writes: > > (apologies for cross-posting) > > Dear all, > > We have submitted a new version of the draft addressing comments > > received both on the mailing list and IETF meetings. > > Thanks to all of you for taking the time to read the draft :) > > Regards, > > Jordi > > Very interesting draft.  One high-level comment, I would avoid terms > > like "tamper-proof" or really anything-"proof" except possibly in the > > context of information-theoretic security, in favor of tamper-resistant. > > This is particularly important in the context of blockchains that have > > experienced a number of forks in practice and where it would likely take > > only a few tens of millions of dollars a day to tamper with history. > > I think the draft would benefit from a much finer-grained consideration > > of several different forms of proof-of-stake, because there are a number > > of assertions that do not hold for all forms of proof of stake.  E.g., > > will there be delegation like peercoin, randomization like algorand, > > penalties like Casper, sleepy nodes like snowwhite? > > And while of course I'm biased on this issue, I think that a > > Byzantine-agreement-based approach like SCP > > (https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/) would work > > better than PoS.  SCP is well matched to the Internet peering model, > > which we already know is a workable decentralized governance model.  You > > may not agree, but it would at least be nice for the document to explain > > why you reject this approach. > > David > > > --------------C635D4B6DCE5FBC5E32EEF32 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Roque,

We have built an open-source prototype [1], and it works like you mentioned: the genesis block includes the public keys that the RP has to trust. It is a one-time action in which you trust the source code and the keys contained in it.

Thanks for your comments, we'll include them in the next version.

Regards,

Jordi

[1] https://github.com/OpenOverlayRouter/blockchain-mapping-system


El 04/07/18 a les 14:09, Roque Gagliano (rogaglia) ha escrit:

Hi Jordi,

 

Very good document.

 

I hate to ask things without providing code but I believe it would be great if you add a section regarding the “relying party”, how would the validation algorithm would look like and what is the bootstrap process. I can see that some public key info would need to be known by the RP.

 

Regards,

Roque

 

 

From: OPSEC <opsec-bounces@ietf.org> on behalf of Jordi Paillissé Vilanova <jordip@ac.upc.edu>
Date: Wednesday 4 July 2018 at 13:28
To: David Mazieres expires 2018-09-30 PDT <mazieres-pebagr7ysjghwpqkcqqnjjf4ta@temporary-address.scs.stanford.edu>, "sidrops@ietf.org" <sidrops@ietf.org>, "din@irtf.org" <din@irtf.org>, Stephane Bortzmeyer <bortzmeyer@nic.fr>, "sandy@tislabs.com" <sandy@tislabs.com>, Greg Skinner <gregskinner0@icloud.com>, "leo@vegoda.org" <leo@vegoda.org>, "Alberto Rodriguez Natal (natal)" <natal@cisco.com>, "Vina Ermagan (vermagan)" <vermagan@cisco.com>, "Fabio Maino (fmaino)" <fmaino@cisco.com>, Albert Cabellos <acabello@ac.upc.edu>, "opsec@ietf.org" <opsec@ietf.org>
Subject: Re: [OPSEC] [Din] blockchain for IP addresses draft update

 

Hi David,

Indeed, we did not delve deeper into the PoS algorithm. This depends on the specific implementation, our opinion is that an Algroand-like would be a good option, and if it can tolerate a large portion of offline participants even better. In addition, we think that punishing or deposit mechanisms are not desirable because they don't fit the characteristics of the scenario. Overall the incentive is "a more secure Internet", we believe that this is well-aligned with the economical interests of the participants.

Regarding SCP, the fact that you only need to trust your neighbours may prove very convenient in this scenario. As you said, it reflects current Internet trust schemes, this basically means that BGP Peering = Trust = Stellar quorum slices. We'll look into this for the next iteration of the draft.

Thanks

Jordi

 

El 02/07/18 a les 17:59, David Mazieres ha escrit:

Jordi Paillissé Vilanova <jordip@ac.upc.edu> writes:
 
(apologies for cross-posting)
 
Dear all,
 
We have submitted a new version of the draft addressing comments 
received both on the mailing list and IETF meetings.
 
Thanks to all of you for taking the time to read the draft :)
 
Regards,
 
Jordi
Very interesting draft.  One high-level comment, I would avoid terms
like "tamper-proof" or really anything-"proof" except possibly in the
context of information-theoretic security, in favor of tamper-resistant.
This is particularly important in the context of blockchains that have
experienced a number of forks in practice and where it would likely take
only a few tens of millions of dollars a day to tamper with history.
 
I think the draft would benefit from a much finer-grained consideration
of several different forms of proof-of-stake, because there are a number
of assertions that do not hold for all forms of proof of stake.  E.g.,
will there be delegation like peercoin, randomization like algorand,
penalties like Casper, sleepy nodes like snowwhite?
 
And while of course I'm biased on this issue, I think that a
Byzantine-agreement-based approach like SCP
(https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/) would work
better than PoS.  SCP is well matched to the Internet peering model,
which we already know is a workable decentralized governance model.  You
may not agree, but it would at least be nice for the document to explain
why you reject this approach.
 
David




--------------C635D4B6DCE5FBC5E32EEF32-- From nobody Fri Jul 6 13:07:07 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919DA130F08 for ; Fri, 6 Jul 2018 13:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=highloadlab-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wyq3l3F-aBH9 for ; Fri, 6 Jul 2018 13:07:03 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28811130EEF for ; Fri, 6 Jul 2018 13:07:03 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id u16-v6so9233839pfh.3 for ; Fri, 06 Jul 2018 13:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=highloadlab-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RX6jwbA275V5M4yCiGFaiIfKFQnEuRiIfgTkHfT9wGw=; b=v5grveivejksAnDvN7H9Aq4nhxbKwSk8xorzmyi9Ft9nJ6TvrQ93jU0UUd+hliifJV efcPje/aI1YPZ20EDROk5ggofTNVE6FGJ3fdRmDoPqP34FKyvO92c6qu2I5H1/VCH/FW s5DKcQAUG9x/Ndh05iTpM1qb1QeW2ErWbD0gmydGOEVe7tQxZsXrXEXoUbAmxZojrVhu G7fmrmdkFeGEPDyZdhysV8ELxtWi0heYuffg3654yB9ToL4J6FGWKD87yF7B/+nd2fsB e8O76YEgeqIIzDiWItDYtLMVL3upY+x6OIBbVNO3ITeIq/Ts5qE0o9v5GRRxER+Co4jE X69A== 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=RX6jwbA275V5M4yCiGFaiIfKFQnEuRiIfgTkHfT9wGw=; b=DwIeMlUzWRJcRz5eNjEW2a6K8m2SDRnD8pekljfyGUrJQvd5J5rBs/HBpCxoGWaIAm aZ8UbylWkO01sP3C14XjMA+YWiVqZKj3+iGc0sk8Tzh88FiGxwEztZL+LP5vPYi94jod r4KIQIF8YMuLfCFVNKy8Wr1TsTfgAEEJbpC5/J0fbk9ViZf1dwWlpnu7QvtbPQYQ/mIB ohMJgjMQIMwLIx5pVrMqGLuLL0VgTD8oD7aqBiWcAoZ06rg5ziw+yQTs4c9GyxBwqN/0 4i9hR05lH7cfy8O+ciOE4RiVw36hjSacq7NXAjQHeVhj7FeRemUWH+hldiyF3K+bjHmj XjHw== X-Gm-Message-State: APt69E1RFzvswoklJh04y4U9HZqBFi3r6u7W4+LwIVzbrRG1+1q6JI06 9StunoqvuveE7k+1SINkeMfesdam+NMuBW+qKHsY/g== X-Google-Smtp-Source: AAOMgpf1TmmaWq0rAgzWwcEjicfGx4hvZARiWKuYnGA8yioqXkCcAsipNbPWNyWSsQf9OymX8iSSklHRYXDlI4s88/s= X-Received: by 2002:a65:60d2:: with SMTP id r18-v6mr5962778pgv.306.1530907622681; Fri, 06 Jul 2018 13:07:02 -0700 (PDT) MIME-Version: 1.0 Sender: aa@highloadlab.com Received: by 2002:a17:90a:7e1:0:0:0:0 with HTTP; Fri, 6 Jul 2018 13:07:01 -0700 (PDT) X-Originating-IP: [195.175.53.234] In-Reply-To: References: <6065B77B-9981-4273-82CD-A13C3151EA24@arrcus.com> From: Alexander Azimov Date: Fri, 6 Jul 2018 23:07:01 +0300 X-Google-Sender-Auth: 3ly6ZW5HWxKD02FTjLQDBCBDyzc Message-ID: To: Tim Bruijnzeels Cc: Keyur Patel , "sidrops@ietf.org" , George Michaelson Content-Type: multipart/alternative; boundary="00000000000008c4f905705a3571" Archived-At: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 20:07:06 -0000 --00000000000008c4f905705a3571 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tim, Thank you for the feedback! Please see my inline comments 2018-07-05 13:01 GMT+03:00 Tim Bruijnzeels : > Since it=E2=80=99s the customer ASN who signs would it be a good idea if = they > listed all provider ASNs in a single object? There is no fate sharing ris= k > like we have in ROAs when including multiple signing prefixes. On the oth= er > hand this would guarantee atomicity. > Interesting point. We will consider changing it this way. > One small thing, eventually this will need a filename extension to be > included in the IANA =E2=80=9CRPKI Repository Name Scheme=E2=80=9D regist= ry. See also: > https://tools.ietf.org/html/rfc6481#section-7.2 > > https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-verification/ > > > I am not entirely clear on the AS_PATH verification in section 5. It read= s > to me like the outcome is invalid, or unverifiable if not all of the ASNs > on the path have published ASPAs. And that unverifiable is considered clo= se > to invalid. But I may have misunderstood.. so I would be particularly > interested in this part of your presentation. > > All that said, I think that it would be extremely useful if a partial, > incremental deployment can be supported. IMHO one of the big issues with > BGPSec deployment is that it=E2=80=99s all or nothing, so there really is= no > incentive to deploy until everybody else has done so. With ASPAs you coul= d > argue that a route should be dropped if any of the pairs in the path turn= s > out to be invalid, but it=E2=80=99s okay to accept unknowns. This would a= llow ASNs > to get benefits from publishing ASPAs without requiring that everyone els= e > does so as well. Of course things will be better when they do as well, bu= t > until that time there still is a benefit. So, there is incentive for ASNs > to be pro-active. > > But as I said.. I am not sure that I got this section 5 completely.. > Yes, it seems that here is a misunderstanding. Behind section 5 there is a simple idea: 1. If there is 'invalid' subpath - then the outcome is 'invalid'; 2. If the AS_PATH can't be fully verified even if all corresponding ASPAs exist (AS_SETs, AS_TRANS) - then the outcome is 'unverifiable'; 3. Otherwise - 'valid'. So, the procedure may return 'valid' also in case if part of AS_PATH isn't fully covered by ASPAs. And to support detection of intentionally malformed AS_PATH for selected ASN it's enough if all its upper providers create ASPAs. For transit-free networks this rule is even more simplified - they just need to create ASPA0. IMHO - it provides a quite powerful mechanism even at the state of partial deployment. --00000000000008c4f905705a3571 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tim,

Thank you for the feedback! Ple= ase see my inline comments

2018-07-05 13:01 GMT+03:00 Tim Bruijnzeels <tim@nlnetlabs.= nl>:
Since it= =E2=80=99s the customer ASN who signs would it be a good idea if they liste= d all provider ASNs in a single object? There is no fate sharing risk like = we have in ROAs when including multiple signing prefixes. On the other hand= this would guarantee atomicity.
<= div>Interesting point. We will consider changing it this way.=C2=A0


One small thing, eventually this will need a filename exte= nsion to be included in the IANA =E2=80=9CRPKI Repository Name Scheme=E2=80= =9D registry. See also:


I am not entirely clear on the AS_PATH = verification in section 5. It reads to me like the outcome is invalid, or u= nverifiable if not all of the ASNs on the path have published ASPAs. And th= at unverifiable is considered close to invalid. But I may have misunderstoo= d.. so I would be particularly interested in this part of your presentation= .

All that said, I think that it would be extremel= y useful if a partial, incremental deployment can be supported. IMHO one of= the big issues with BGPSec deployment is that it=E2=80=99s all or nothing,= so there really is no incentive to deploy until everybody else has done so= . With ASPAs you could argue that a route should be dropped if any of the p= airs in the path turns out to be invalid, but it=E2=80=99s okay to accept u= nknowns. This would allow ASNs to get benefits from publishing ASPAs withou= t requiring that everyone else does so as well. Of course things will be be= tter when they do as well, but until that time there still is a benefit. So= , there is incentive for ASNs to be pro-active.

Bu= t as I said.. I am not sure that I got this section 5 completely..
Yes, it seems that here is a misunderstanding. B= ehind section 5 there is a simple idea:
  1. If there is '= invalid' subpath - then the outcome is 'invalid';
  2. I= f the AS_PATH can't be fully verified even if all corresponding ASPAs e= xist (AS_SETs, AS_TRANS) - then the outcome is 'unverifiable';
    <= /li>
  3. Otherwise - 'valid'.
So, the p= rocedure may return 'valid' also in case if part of AS_PATH isn'= ;t fully covered by ASPAs.=C2=A0
And to support detection of inte= ntionally malformed AS_PATH for selected ASN it's enough if all its upp= er providers create ASPAs. For transit-free networks this rule is even more= simplified - they just need to create ASPA0. IMHO - it provides a quite po= werful mechanism even at the state of partial deployment.
=
--00000000000008c4f905705a3571-- From nobody Tue Jul 10 03:56:23 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B14130F81 for ; Tue, 10 Jul 2018 03:56:20 -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, FREEMAIL_FROM=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 KBLNjohgxGeH for ; Tue, 10 Jul 2018 03:56:18 -0700 (PDT) Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) (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 05F8F130F7C for ; Tue, 10 Jul 2018 03:56:18 -0700 (PDT) Received: by mail-ed1-x542.google.com with SMTP id v22-v6so16241586edq.4 for ; Tue, 10 Jul 2018 03:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=sywnZfO7+z+fR50KI8i3bR1OLty7daASKKUvjBvWN74=; b=HGA+PilvfIOopT/vqqbb0m0Vh6ddaOrb4bltQ5aeuVSx/ztDq7cptoXP7ERXraSOz4 Slf4gqdsj/c3mAGHPBmS+gvN9ilqesXK91AZijO+msWRlUjn6AVXKUi2HbAyQU6dwwVj /3bQNZmZp1ffoWlNz+mqSCeXUChFkXaE3wVP0EdhTl0dK9Qu+wTAXlRa8HgjoEy3f+xd L4zsGYqnck6VCJH+lfCRC0UMRvwF8sNAaQaJceR+bl2IzeZip+Ulpk684AE5pg/BGFkw 1srOkKI7uRQYgki2pTVVPRbrW5eGTpFGxBKidHizvfPZ1QJt1N1H7d94iAvJkn2gD6k6 RbYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=sywnZfO7+z+fR50KI8i3bR1OLty7daASKKUvjBvWN74=; b=EhaAG3jkER8twV9tuF0SjJ0qXoE9G4f+M3FwQNuDaDlyv7Z5m0LRb15+c503lMivmm wocqvzWOOgfVzkD7PLYt7A+DFjBRDMsq46cCoAa76h8Xpf9EHhoeA2TOtQoFOrwpmwAc 7pjWG2gV2zcKGZWX2bl0jb8LDzTNLetqNjXnJ7x9EsaN8yKjOz9prsKIW3r2QsUwVt5z ohbZE1W+DZPs0zWlD6EdfkuK5vDxQf+NDZNsnzLVisHrujqGS63qKuuCFggfLrrV6jEV 2tdlueBvQ4d5NNNADTRWPYRTnplg47U44T91uWVGeYR7IxuC+xf3i3jz4FxyhperxlX7 dH2A== X-Gm-Message-State: APt69E02IWYv9ZsS5em7rNJXH7Yq5P8kZo/yVmonOARXuFQWKv5mQv3G 5pvj0lcxLyGBwg5sGjWBOgWSzA== X-Google-Smtp-Source: AAOMgpe1NA7Ai3LguuKJOGwx3pwHZlyQlLOJCY7B/s0Fwz4YHXWySvAUHqUVZ0KLZcpscEjmXc4jqg== X-Received: by 2002:a50:80e6:: with SMTP id 93-v6mr25771747edb.252.1531220176644; Tue, 10 Jul 2018 03:56:16 -0700 (PDT) Received: from admins-MacBook-Pro-2.local (dhcp-077-250-131-147.chello.nl. [77.250.131.147]) by smtp.googlemail.com with ESMTPSA id 33-v6sm1458738edy.82.2018.07.10.03.56.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 03:56:15 -0700 (PDT) To: Alexander Azimov , Tim Bruijnzeels Cc: Keyur Patel , "sidrops@ietf.org" , George Michaelson References: <6065B77B-9981-4273-82CD-A13C3151EA24@arrcus.com> From: Andrei Robachevsky Openpgp: preference=signencrypt Autocrypt: addr=andrei.robachevsky@gmail.com; prefer-encrypt=mutual; keydata= xsDiBD8L4TQRBACI+LX/GwEK23h5OXLU7iPeZc8FJ0ywH1vVqY/gT8VCs7YzbG4GNV6omEqa 0sDBF/eYKzLC5PfaKkHeAJ51eVIcDqYDhqYNlaxr5XPWWYjOIGvVRDmp4RKxhhDgXgKMmisW RrMCCP1njNQEWYtuB64UUNit1VXbQXn2FBpEXisqxwCg6hZK7Seg5md07iu9lYQx5rng+C0D /2TkPt4t80x3Iw8WV7TSLKdEQMRG42FMIFbaZIKbiEwvfaZYNrOckxdTr8l8LvwxNxHePsVi 1sqjBR8iwtogvLhSudqXxXsj2BiYfGSpTJoiVRPKdlEzo3i1mFPV/dNTSjovzWz5c21nW9kK fUIY43sLD5aynB9WITl9O6iawOrxA/0cOwOOVrpwHdLg+Uxb9y8C/1mx3o307hZDbn84Zare aiQNOn+ETI45ucON72OoMnuaBs3fJOoreXoaOSIxuM5gSQDY/SyDqncPhZmQX8yA52fuc3Ol 8qBjEomymafFymRUFvphEr/KD9BpyBZqM41zrT5VEu2tk/ga5T+bC79W780xQW5kcmVpIFJv YmFjaGV2c2t5IDxhbmRyZWkucm9iYWNoZXZza3lAZ21haWwuY29tPsJ5BBMRCgA5AhsjBgsJ CAcDAgYVCAIJCgsEFgIDAQIeAQIXgBYhBGtZeFNYETVQoSYbeZY8+bWZrYo/BQJadGb/AAoJ EJY8+bWZrYo/pGgAoNlUk0Nu3km8dAtzOlrN5bveacodAJ4jwG65QN2EhvnTgHGQEybn9IjN 0M7ATQQ/C+E1EAQAvRN7YTDiGXS9OPLX5yDKBtvjQaR38t5zpi0ltuC5JITDKZdM6/9PCfJq QnMy+ngrI3VQdhxbduFrC5fBszo1vVMTwKrTD6D7BEsEgC3wNE5NzfzE/fjl0LkQMEf5Vxns jvbtYw2jfoyJFig2gdW4ojmBCge16RZwx7vK7Pn0z6MAAwYEAJ7zZZCCU2DZ/gPdfB3xPZVm 7XSMpG6GBz4mFGgJW/QeC2quqoKBeAEgf0icEM8ykEAPmpy8f6j0Fwe/qz/SgxOXfTlvH8O7 md6rx2t2D+1PM2PlYzwO37U5fqnPuzp5KMXlPPryuTWZmObgZMHHsko9BbpIcqNHqUNXzNwk +gjkwkYEGBECAAYFAj8L4TUACgkQljz5tZmtij/lFQCdGIvMimtJEiYiPIZYSvXI6hx8WOQA oMj/ni+WopJxWu947/5RyWR6AUpH Message-ID: <5ee309ea-a772-df45-96cc-152726e303a0@gmail.com> Date: Tue, 10 Jul 2018 12:55:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5RfOLOV2WJgftfVbsNVeznYDUFsAxQOCt" Archived-At: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 10:56:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5RfOLOV2WJgftfVbsNVeznYDUFsAxQOCt Content-Type: multipart/mixed; boundary="8QbJOFdljj9MlIcnTcQWUApTC96BVQvAR"; protected-headers="v1" From: Andrei Robachevsky To: Alexander Azimov , Tim Bruijnzeels Cc: Keyur Patel , "sidrops@ietf.org" , George Michaelson Message-ID: <5ee309ea-a772-df45-96cc-152726e303a0@gmail.com> Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items References: <6065B77B-9981-4273-82CD-A13C3151EA24@arrcus.com> In-Reply-To: --8QbJOFdljj9MlIcnTcQWUApTC96BVQvAR Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Alexander, Alexander Azimov wrote on 06/07/2018 22:07: > Yes, it seems that here is a misunderstanding. Behind section 5 there i= s > a simple idea: >=20 > 1. If there is 'invalid' subpath - then the outcome is 'invalid'; > 2. If the AS_PATH can't be fully verified even if all corresponding > ASPAs exist (AS_SETs, AS_TRANS) - then the outcome is 'unverifiable= '; In case the speaker understands 32-bit ASNs a path may be reconstructed using the AS4_PATH attribute. Do you refer to AS_PATH in a sense of constructed AS path (where AS_TRANS may be replaced), rather then the AS_PATH received from a neighbor who doesn't support 32-bit ASNs? > 3. Otherwise - 'valid'.> > So, the procedure may return 'valid' also in case if part of AS_PATH > isn't fully covered by ASPAs.=20 It doesn't make much sense to me to declare the path valid even if some of the segments cannot be verified. As opposed to BGPsec it is not all or nothing in this case, as I understand it. Valid ASPAs linking segments on both ends of the path provide value since an attacker cannot craft a shorter path, and will probably lose because of that. So in this sense every ASPA is an incremental improvement. > And to support detection of intentionally malformed AS_PATH for selecte= d > ASN it's enough if all its upper providers create ASPAs. For > transit-free networks this rule is even more simplified - they just nee= d > to create ASPA0. IMHO - it provides a quite powerful mechanism even at > the state of partial deployment. I like the simplicity of the approach, are different types of relationships between the two AS'es outside the scope? Thanks, Andrei --8QbJOFdljj9MlIcnTcQWUApTC96BVQvAR-- --5RfOLOV2WJgftfVbsNVeznYDUFsAxQOCt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iF0EARECAB0WIQRrWXhTWBE1UKEmG3mWPPm1ma2KPwUCW0SQvQAKCRCWPPm1ma2K Pz89AKCbIBrT1rSuN2uhMAUDTx5rr9+ulgCeIutCSRdGkUNonbM1zBquRjvu7Ek= =zFpQ -----END PGP SIGNATURE----- --5RfOLOV2WJgftfVbsNVeznYDUFsAxQOCt-- From nobody Tue Jul 10 11:25:50 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25498131041 for ; Tue, 10 Jul 2018 11:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 S3pijqlWabec for ; Tue, 10 Jul 2018 11:25:45 -0700 (PDT) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0135.outbound.protection.outlook.com [23.103.201.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30623131038 for ; Tue, 10 Jul 2018 11:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S3tA2GhKRKqMTj/0iZjmO8MHq+MN2MjUgn8M0P5zJAI=; b=S9Q3FVKxZzMyVWslDd5mtWr4EL38X14uVYlQRT+ubBO1ybtxBjVm4+9ner8kvPU4xcc458kHIwa3PLCZerTBYmj8xF/lQL9CkknL4ZPbs3M8ghVMSHI9J/OzA/3zl3j/3EH/xmR9srq+oRRnL11Hjb43Sq/6LbrFczNYcQlJRQk= Received: from SN6PR0901MB2366.namprd09.prod.outlook.com (52.132.115.159) by SN6PR0901MB2365.namprd09.prod.outlook.com (52.132.115.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.19; Tue, 10 Jul 2018 18:25:41 +0000 Received: from SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::3488:a44a:a9ce:6db7]) by SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::3488:a44a:a9ce:6db7%6]) with mapi id 15.20.0930.022; Tue, 10 Jul 2018 18:25:41 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "tim@nlnetlabs.nl" CC: Alexander Azimov , Keyur Patel , "sidrops@ietf.org" Thread-Topic: Re: [Sidrops] Call for SIDROPS WG Agenda Items Thread-Index: AdQYebDo5HUre4uJSriccjT1enEZAQ== Date: Tue, 10 Jul 2018 18:25:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR0901MB2365; 7:zJ7CFFbBsKtTCQs/rlQJaw1KC8wkm/ab7Dw3qloSoJf/UbWfhXzfeSUC3ivGL5vm1jawLsZ4Rr9JbXccMBbvo03dGK7rs7EFeFAHeSVDX/Tf+Zye2oFcDyj4Jkca0RzRQQhMQMmw6REcdva3E6ZFhYgee0DmEt4op7//r1UkmMX5YAQBL693VXA34EdbVe62ZWAYn53nqCAzfig75mqMBY67hzwMOGDIb1EF4PWs05R167O8iW1sMi6R7vzIPeVo x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8f4d39b1-9fa1-4b5b-7f2c-08d5e6928b3e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600053)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:SN6PR0901MB2365; x-ms-traffictypediagnostic: SN6PR0901MB2365: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:SN6PR0901MB2365; BCL:0; PCL:0; RULEID:; SRVR:SN6PR0901MB2365; x-forefront-prvs: 0729050452 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(396003)(136003)(376002)(39860400002)(199004)(189003)(486006)(26005)(476003)(6436002)(55016002)(4326008)(229853002)(81156014)(99286004)(7736002)(186003)(5250100002)(6306002)(966005)(14454004)(53936002)(2900100001)(1730700003)(6246003)(97736004)(2501003)(8676002)(6506007)(9686003)(81166006)(102836004)(478600001)(68736007)(6916009)(74316002)(3846002)(6116002)(7696005)(2351001)(5640700003)(2906002)(54906003)(106356001)(305945005)(256004)(105586002)(66066001)(14444005)(8936002)(25786009)(316002)(5660300001)(86362001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR0901MB2365; H:SN6PR0901MB2366.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: fxs4Qj71xP7PSRGkjwQl9J0JUip6HChKjp62X3DkTGT1sqGUbFlfTsPVCJ7CDbFsR4Br4L7lb71EHiQty2SaaTLqllWRcySh28lzQwOMtzRJyyIpJd9962X0/zAXHmg90BMeXBzP1kk9GkeAslwKuK7nLCPKUGq4YBKJPHhn8m4Ju2z3kS+ngd4yCxwUXWk7XGGUSPb710vyMR81xjq5fW8ECGofUr9wenrrlnCkLolEGqCfFX78z6B6iyKolygnUn6j6oKlEZk5vueZUvtDvmJdiEGKFrM3rXcp87H7h8auaAp7hl31roHvV3iAAhowQDHD8cZSPcCWbu310GHiaSx6CEhdUeXADOAF62/aif8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 8f4d39b1-9fa1-4b5b-7f2c-08d5e6928b3e X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2018 18:25:41.7545 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR0901MB2365 Archived-At: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:25:50 -0000 Tim, >IMHO one of the big issues with BGPSec deployment is that=20 >it's all or nothing, so there really is no incentive to deploy until every= body else has done so. IMO, these are two different goals: (1) All AS hops must be valid for the u= pdate to be valid,=20 and (2) the benefit of BGPsec for early adopters with incremental deploymen= t. BGPsec is successful on meeting both goals. SIDR path validation always had the requirement that the AS path in the announced update MUST be provably valid; not merely feasible (see 4.2 in RFC 7353).=20 SIDR WG ruled out partial path validation because that would keep the door open for cut-and-paste or forged path attacks. Without BGPsec, the following can happen. Even with checking all AS hops in the update against a database that provides a white list of peering relationships=20 (e.g., proposed ASPA, CAIDA peering data), an update with forged path is still possible. For example, consider a prefi= x that is multihomed and has two RAOs with ASNs of two different providers, and the prefix is only announced through one provider. An MITM attack is possible that exploits the other ROA and the white list to forge a route consisting of only valid AS hops (end-to-end). Regarding, (2) the benefit of BGPsec for early adopters and incremental dep= loyment, please see Section 6.3.2, RFC 8374 ( https://tools.ietf.org/html/rfc8374#pa= ge-26 ): 6.3.2. Discussion The partial-deployment approach to incremental deployment will result in "BGPsec islands". Updates that originate within a BGPsec island will generally propagate with signed AS paths to the edges of that island. As BGPsec adoption grows, the BGPsec islands will expand outward (subsuming non-BGPsec portions of the Internet) and/or pairs of islands may join to form larger BGPsec islands. The ASes within each BGPsec island are backward compatible with traditional BGP ASes that are outside the islands (see Section 4.4 of RFC 8= 205). =20 Sriram =20 =20 From nobody Tue Jul 10 12:03:00 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571EC127AC2 for ; Tue, 10 Jul 2018 12:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 imyzWNH0roK6 for ; Tue, 10 Jul 2018 12:02:55 -0700 (PDT) Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0131.outbound.protection.outlook.com [23.103.200.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78A8E12F1AC for ; Tue, 10 Jul 2018 12:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MF0wLH2yXVzRAYMHcKNo1j2B3vevGi1i9p5WTFsa0Dk=; b=Uaf/TBGz+pUAeMuNreqZGrGE8aSoybl1EdTep2J/BgFhAg3LkLtUX0T8Z81bz+CEUUueWtvZR5JkX8u5kZR3Hti0y7a7wSCpnXihC8GYCo/8Ig3sdUBFFqbddMwTz45qs4JoubL2XzuSHjcMxi83lyOzO9WbBt8z4pBz88c1buE= Received: from SN6PR0901MB2366.namprd09.prod.outlook.com (52.132.115.159) by SN6PR0901MB2365.namprd09.prod.outlook.com (52.132.115.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.19; Tue, 10 Jul 2018 19:02:53 +0000 Received: from SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::3488:a44a:a9ce:6db7]) by SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::3488:a44a:a9ce:6db7%6]) with mapi id 15.20.0930.022; Tue, 10 Jul 2018 19:02:53 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Alexander Azimov CC: Keyur Patel , "sidrops@ietf.org" , George Michaelson Thread-Topic: [Sidrops] Call for SIDROPS WG Agenda Items Thread-Index: AdQYgJWCEfJnjPxWRy6nlbFgYt4u+w== Date: Tue, 10 Jul 2018 19:02:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR0901MB2365; 7:r3FmM6uFE3ykGKdzNkB9fJNxuv5RFcx20XqCPne0vcrWWnkHZ0AjY6JhBOpnl+hDyLPSKt8FSrYOm6FKqVGN40A5esYbJiTzLyJxY8sIfOGHhwh855O/Jr3AFlU8QTkBGoCrEcXFLQYVlwvtPiYOVLSK+TzT+Ge3dK+Hvuv11j6Or8orjkBfUlHxF8gufHsG5qDR9qAxzIS/OX5nraBTczyf0YChBpNzeznEBQhQ/LNJ05PKPc9jfajMPLPfYZep x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b56f4ef1-cc02-464c-076e-08d5e697bd81 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600053)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:SN6PR0901MB2365; x-ms-traffictypediagnostic: SN6PR0901MB2365: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(2006787148836); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:SN6PR0901MB2365; BCL:0; PCL:0; RULEID:; SRVR:SN6PR0901MB2365; x-forefront-prvs: 0729050452 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(396003)(136003)(39860400002)(376002)(199004)(189003)(486006)(26005)(476003)(6436002)(55016002)(4326008)(229853002)(81156014)(99286004)(7736002)(186003)(5250100002)(6306002)(966005)(14454004)(53936002)(2900100001)(6246003)(97736004)(8676002)(6506007)(9686003)(81166006)(68736007)(102836004)(478600001)(6916009)(74316002)(3846002)(6116002)(7696005)(2906002)(54906003)(106356001)(305945005)(256004)(105586002)(66066001)(14444005)(8936002)(25786009)(316002)(5660300001)(86362001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR0901MB2365; H:SN6PR0901MB2366.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: pE4MHujkr/qLN0j0znxWdgjooQeUW/rVjTzgOwAljt9jQIYmt2J74qhFbQIUjKtt/Vtr1+OYJVL7nwaY5jG+nzJbTJx86OUZwRSppZ5+p91hiL38hxsk1Vjtw7NQPfuCotrpR/URehTVjv93VL12/QeKGUvShgD4gSASKJQ1Xsjr2T7O0ZzrrnqOlhxFOM+3D68uYS5rd4JkNEUiDKqfpwgyGVUGXtIE9f/OPrR1NHjZa3kreVmjuJqch7UTvNSIDUsA9Z8VNZCz1ijwrEwZinBt+3NvI6kUj/e+fhtEAvbBoWQpf3CTtVFOo+sf3aa76fUPrwTjNrf0US4o9FDxFos7+UEmcstkE6Xo9wwqAws= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: b56f4ef1-cc02-464c-076e-08d5e697bd81 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2018 19:02:53.5452 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR0901MB2365 Archived-At: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 19:02:59 -0000 >Yes, important notice. I was not aware of this draft. Of course, we should= mention it.=20 Let's discuss if there is something that is needed to be exported to ASPA-p= rofile or if we need a merge. >>ggm has pointed out some solid prior art, >> https://tools.ietf.org/html/draft-huston-sidr-aao-profile-03 The BGPsec design team had also considered two ideas that parallel ASPA. At the time, these were aimed at helping stub ASes get on board quickly=20 (without requiring them to upgrade to BGPsec), while still requiring full AS path validation. (1) Extended RAO -- see Section 6.5.2 (page 26) in https://tools.ietf.org/h= tml/rfc8374=20 (2) Proxy Signer Authorization -- see slide 26 in this BGPsec design team p= resentation: https://www.nist.gov/sites/default/files/documents/2018/04/19/= bgpsec-dynamics-oct16_2009.pdf=20 These were proposed signed RPKI objects. Sriram =20 From nobody Wed Jul 11 00:58:53 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45682130E09 for ; Wed, 11 Jul 2018 00:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 bZivrjX6I7gT for ; Wed, 11 Jul 2018 00:58:49 -0700 (PDT) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [185.49.140.10]) (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 A3B4A130E02 for ; Wed, 11 Jul 2018 00:58:48 -0700 (PDT) Received: from [IPv6:2a04:b900::1:d5d8:cd39:4ad6:993a] (unknown [IPv6:2a04:b900:0:1:d5d8:cd39:4ad6:993a]) by dicht.nlnetlabs.nl (Postfix) with ESMTPS id D21CD89C1; Wed, 11 Jul 2018 09:58:45 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Tim Bruijnzeels In-Reply-To: Date: Wed, 11 Jul 2018 09:58:45 +0200 Cc: Alexander Azimov , Keyur Patel , "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <55018984-81F3-48CA-B238-3BB8BC557596@nlnetlabs.nl> References: To: "Sriram, Kotikalapudi (Fed)" X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 07:58:51 -0000 Sriram, I have nothing against BGPSec deployment personally, on the contrary.. I = am well aware of the island theorem, but I just observe that years after = standardisation deployment is not happening. And I fear that it=E2=80=99s = largely because today such islands are hard to build, expensive, and = lack of support in hardware routers makes the mission all the more = difficult. And unless your neighbours also deploy there is no reward. = This is a hard sell. I am also well aware that with ASPA or similar approaches the path can = still be forged, especially under partial deployment - albeit that = it=E2=80=99s harder. I see the two techniques as orthogonal. BGPSec is what you would need to = be certain that the path is not forged, but it says nothing about = whether these paths are according to policy. A technique like ASPA = provides verifiable and light-weight (which is good!) policy, but no = absolute certainty of path correctness. So, I believe that ASPA has a valid place of its own. It will make = things better than today. Moreover it will be cheap to deploy. RPKI = validators can do the crypto and routers already have a lot (all?) of = the config hooks in place to use this information. It does not exclude future BGPSec deployment. To quote the little green = guy: Hard to see the future is. But I suspect that the chances of BGPSec = deployment will actually increase if RPKI has an ASPA like feature. It = allows for step by step improvements: origin (ROAs), policy (ASPA) and = then finally when there is significant uptake of the first two, it will = be easier to do the extra step and build bgpsec islands. Tim > On 10 Jul 2018, at 20:25, Sriram, Kotikalapudi (Fed) = wrote: >=20 > Tim, >=20 >> IMHO one of the big issues with BGPSec deployment is that=20 >> it's all or nothing, so there really is no incentive to deploy until = everybody else has done so. >=20 > IMO, these are two different goals: (1) All AS hops must be valid for = the update to be valid,=20 > and (2) the benefit of BGPsec for early adopters with incremental = deployment. > BGPsec is successful on meeting both goals. >=20 > SIDR path validation always had the requirement that the AS path in = the > announced update MUST be provably valid; not merely feasible > (see 4.2 in RFC 7353).=20 >=20 > SIDR WG ruled out partial path validation because that would > keep the door open for cut-and-paste or forged path attacks. >=20 > Without BGPsec, the following can happen. > Even with checking all AS hops in the update against a database > that provides a white list of peering relationships=20 > (e.g., proposed ASPA, CAIDA peering data), > an update with forged path is still possible. For example, consider a = prefix that is > multihomed and has two RAOs with ASNs of two different providers, > and the prefix is only announced through one provider. > An MITM attack is possible that exploits the other ROA and the white = list > to forge a route consisting of only valid AS hops (end-to-end). >=20 > Regarding, (2) the benefit of BGPsec for early adopters and = incremental deployment, > please see Section 6.3.2, RFC 8374 ( = https://tools.ietf.org/html/rfc8374#page-26 ): >=20 > 6.3.2. Discussion >=20 > The partial-deployment approach to incremental deployment will = result > in "BGPsec islands". Updates that originate within a BGPsec island > will generally propagate with signed AS paths to the edges of that > island. As BGPsec adoption grows, the BGPsec islands will expand > outward (subsuming non-BGPsec portions of the Internet) and/or pairs > of islands may join to form larger BGPsec islands. >=20 > The ASes within each BGPsec island are backward compatible with > traditional BGP ASes that are outside the islands (see Section 4.4 of = RFC 8205). =20 >=20 > Sriram >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 From nobody Wed Jul 11 07:36:24 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56DC130EB5 for ; Wed, 11 Jul 2018 07:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=highloadlab-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXYUvJCYMnS2 for ; Wed, 11 Jul 2018 07:36:12 -0700 (PDT) Received: from mail-pl0-x242.google.com (mail-pl0-x242.google.com [IPv6:2607:f8b0:400e:c01::242]) (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 30045130F66 for ; Wed, 11 Jul 2018 07:36:07 -0700 (PDT) Received: by mail-pl0-x242.google.com with SMTP id f4-v6so5056987plb.9 for ; Wed, 11 Jul 2018 07:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=highloadlab-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tLDZN8N7x/y6fNxlv2nQDOz36DqYNw1Oaf2Ivlt42Ao=; b=N6pph92g4HV7JWqw/p3aU2bXlg0xwLMI7zBQ6YQqzARDI/6LGmTduQWIUVsWoYRBVX xUajqOkCBhpGwfLIasBIz/XzpCmUcRq0C2durrJGoQdQP/EPtq0doPeQjXxbpOJP7bEC xPlsvZb+YaXpyVDONdwmXjxvlzamQtDeIL5LzR58u+rOYupynt5v2KSl4DNavPQCTt5D 3IYQd/4Dn75KMnglIH0PyDlaUti8hxz0y1CVoNRPP+8Gf+rfyvEf3I6bLIHYQkf/zDjX RkJvrb+lVjPaxoCowGmaJ7gAvES40JkmUwJWhamD2R56poIA5MQJQr++1618GhAcD4hx Lo/w== 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=tLDZN8N7x/y6fNxlv2nQDOz36DqYNw1Oaf2Ivlt42Ao=; b=ZnLykzu63OROQpPpL2ZdrSqjhScCLCrP+50/usuKlU08lSTEvAO4dLwFXitON+nkB9 fIk0T8meaBCTuwQ2m+vZTOxTfF/SkfMBZ++ZNIHHsRSdxloPModJWEscxVPxmll92MP6 wikDZlI7CKrHPi626MqmnkwU1tpOuyItvJwi0lACQszwscF9NS8GQBqrxZxIhfj3lTve nF5CzjFfX7wW3fAaQsjn6b7cz0JdBTAlcl6ceUSc++8gprb3CqxZhHUTqxuCsfnX7R/R 8ySIc9ixdHau5LPKgdBSalFltxnE19BW6VOZfHrN6+oXSiQUjgnR8q2/sao3vLb0ezwc 3dQg== X-Gm-Message-State: APt69E2UOlEiUFPwKab9OVLeMt+C63r4A3yyofWCP3uIIi4sbI0uwBeO WNxlrh3bbKuBfw+5bU13XhdFX6rYYj0/164ncwJhYg== X-Google-Smtp-Source: AAOMgpeO1gTpN0K6iArQGMnbqGqXUe+3Q+ph0FbNgSQbfITrvUncdKYCsNRjiyDYcCggSN96dleaIm1ktb9e/FT5GS0= X-Received: by 2002:a17:902:3c5:: with SMTP id d63-v6mr29642480pld.163.1531319766583; Wed, 11 Jul 2018 07:36:06 -0700 (PDT) MIME-Version: 1.0 Sender: aa@highloadlab.com Received: by 2002:a17:90a:7e1:0:0:0:0 with HTTP; Wed, 11 Jul 2018 07:36:05 -0700 (PDT) X-Originating-IP: [95.143.124.62] In-Reply-To: <5ee309ea-a772-df45-96cc-152726e303a0@gmail.com> References: <6065B77B-9981-4273-82CD-A13C3151EA24@arrcus.com> <5ee309ea-a772-df45-96cc-152726e303a0@gmail.com> From: Alexander Azimov Date: Wed, 11 Jul 2018 17:36:05 +0300 X-Google-Sender-Auth: UtKinADWfXbNm8Q29sXVDcKxr3o Message-ID: To: Andrei Robachevsky Cc: Tim Bruijnzeels , Keyur Patel , "sidrops@ietf.org" , George Michaelson Content-Type: multipart/alternative; boundary="000000000000b9a5160570ba2aee" Archived-At: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 14:36:22 -0000 --000000000000b9a5160570ba2aee Content-Type: text/plain; charset="UTF-8" Andrei, Thank you for the comments. 2018-07-10 13:55 GMT+03:00 Andrei Robachevsky : > Alexander, > > Alexander Azimov wrote on 06/07/2018 22:07: > > Yes, it seems that here is a misunderstanding. Behind section 5 there is > > a simple idea: > > > > 1. If there is 'invalid' subpath - then the outcome is 'invalid'; > > 2. If the AS_PATH can't be fully verified even if all corresponding > > ASPAs exist (AS_SETs, AS_TRANS) - then the outcome is 'unverifiable'; > > In case the speaker understands 32-bit ASNs a path may be reconstructed > using the AS4_PATH attribute. Do you refer to AS_PATH in a sense of > constructed AS path (where AS_TRANS may be replaced), rather then the > AS_PATH received from a neighbor who doesn't support 32-bit ASNs? > I had in mind two scenarios: - Provide a limited opportunity to 'old' BGP software to verify routes using ASPA; - Provide solution for a case when AS_PATH wasn't properly reconstructed and there are AS_TRANS left. > > 3. Otherwise - 'valid'.> > > So, the procedure may return 'valid' also in case if part of AS_PATH > > isn't fully covered by ASPAs. > > It doesn't make much sense to me to declare the path valid even if some > of the segments cannot be verified. As opposed to BGPsec it is not all > or nothing in this case, as I understand it. Valid ASPAs linking > segments on both ends of the path provide value since an attacker cannot > craft a shorter path, and will probably lose because of that. So in this > sense every ASPA is an incremental improvement. > Yes, each ISP by signing ASPA will improve the level of its own security and security of its customers - that's a really important motivation. If there is a complete sequence of signed ASPAs from edge to Tier1 - then the attacker will have no opportunity to create a valid AS_PATH in terms of the verification procedure. We can consider adding additional state 'unknown' or 'partial valid'. It will have similar semantics to 'unknown' output of ROA validation procedure. But as you know, the current practices are focussing on dropping 'invalid' routes, there is no difference in processing 'unknown' and 'valid' routes. > > > And to support detection of intentionally malformed AS_PATH for selected > > ASN it's enough if all its upper providers create ASPAs. For > > transit-free networks this rule is even more simplified - they just need > > to create ASPA0. IMHO - it provides a quite powerful mechanism even at > > the state of partial deployment. > > I like the simplicity of the approach, are different types of > relationships between the two AS'es outside the scope? > For me it seems that we don't need any additional information to verify routes received from customers and peers. So, I've tried to make it as simple as possible. -- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | mailto: aa@qrator.net | visit: www.qrator.net --000000000000b9a5160570ba2aee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Andrei,

Thank you for the comments.

2018-07-10 13:5= 5 GMT+03:00 Andrei Robachevsky <andrei.robachevsky@gmail.com>:
Alexande= r,

Alexander Azimov wrote on 06/07/2018 22:07:
> Yes, it seems that here is a misunderstanding. Behind section 5 there = is
> a simple idea:
>
>=C2=A0 1. If there is 'invalid' subpath - then the outco= me is 'invalid';
>=C2=A0 2. If the AS_PATH can't be fully verified even if all corres= ponding
>=C2=A0 =C2=A0 =C2=A0ASPAs exist (AS_SETs, AS_TRA= NS) - then the outcome is 'unverifiable';

In case the speaker understands 32-bit ASNs a path may be reconstruc= ted
using the AS4_PATH attribute. Do you refer to AS_PATH in a sense of
constructed AS path (where AS_TRANS may be replaced), rather then the
AS_PATH received from a neighbor who doesn't support 32-bit ASNs?
I had in mind two scenarios:
  • Provide a li= mited opportunity to 'old' BGP software to verify routes using ASPA= ;
  • Provide solution for a case when AS_PATH wasn't properly reco= nstructed and there are AS_TRANS left.
=C2=A0
>=C2=A0 3. Otherwise - 'valid'.>
> So, the procedure may return 'valid' al= so in case if part of AS_PATH
> isn't fully covered by ASPAs.

It doesn't make much sense to me to declare the path valid even = if some
of the segments cannot be verified. As opposed to BGPsec it is not all
or nothing in this case, as I understand it. Valid ASPAs linking
segments on both ends of the path provide value since an attacker cannot craft a shorter path, and will probably lose because of that. So in this sense every ASPA is an incremental improvement.
<= div>Yes, each ISP by signing ASPA will improve the level of its own securit= y and security of its customers - that's a really important motivation.= If there is a complete sequence of signed ASPAs from edge to Tier1 - then = the attacker will have no opportunity to create a valid AS_PATH in terms of= the verification procedure.


> And to support detection of intentionally malformed AS_PATH for select= ed
> ASN it's enough if all its upper providers create ASPAs. For
> transit-free networks this rule is even more simplified - they just ne= ed
> to create ASPA0. IMHO - it provides a quite powerful mechanism even at=
> the state of partial deployment.

I like the simplicity of the approach, are different types of
relationships between the two AS'es outside the scope?
=
For me it seems that we don't need any additional information= to verify routes received from customers and peers.
So, I've= tried to make it as simple as possible.

--=
--000000000000b9a5160570ba2aee-- From nobody Thu Jul 12 00:16:36 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC4F13107B for ; Thu, 12 Jul 2018 00:16:34 -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, FREEMAIL_FROM=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 OU2ZaDX0KVJq for ; Thu, 12 Jul 2018 00:16:33 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E75F131083 for ; Thu, 12 Jul 2018 00:16:32 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id s24-v6so4872813edr.8 for ; Thu, 12 Jul 2018 00:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=qWq37lKywuiIAyIm7L181rmGs9rBTr2UyL9wQ6tvGn0=; b=OTh0SpUWm+yaMqOMywXEkl/tjUlPHJWLLIhlqRPflA991yMXMp3xFDEpq1Hp/SjkmK KjwX6YQQe+zyVAqb+y673e1h8HBclUQossBA4IYg+/4eZINsIZa+RpflSEIUrTEOXhVf pf8REMKelAEYsEOwi1S8g0I0A6+w/6f9lQQCJnd50JNEqFYYoJvZI7BNOQm9DbeiDBnp R562ZzG3PAtdMWKYUvf2YPxDWpN1plHCeILuKv4Fhkhx6ZCwgeb0wQutUrcEwUN09uPN WSua0NQ9WzVAPZShmFXPRbGNvkRJMu8nMGqX4O14fMRh5/dx4BhodbwD5sbTJEbZ3hRg qj4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=qWq37lKywuiIAyIm7L181rmGs9rBTr2UyL9wQ6tvGn0=; b=kJk5PT90SGG5u6dUSo5cdw7lg7JkL+f9oHaWvgnC72wY0bmZChN5RfQU5fukWZ5ZpH iCtbmelo2I15pNEDfnxcli70coIu0Y4wdgCeTS0fl+R6pc0YJzvv7OTQtb93SQund+l9 qdZuBSegPw3+1SXzahEacgQzUmlD+ERghgIrkLIQLKOX9YOpAfyC7FB4DoZwtViwPcAY rq/k+Up9Hl8o0qMd4jQulrAcWVG/AH/cAqFBXyVNPUTl80IjbZTFsqf8k8s3Hlw+ebdM RyRR7allu6RXV76M+vMPuPaSnOKqwEecV3rZjvxla9niVjs7/ghb1h1iUl8iyEkfhJ+/ g1yA== X-Gm-Message-State: AOUpUlHq6w7WF9DA2seuSaOOzJOOG5lMHzj1AhAVgfH33Wn7HqftBOhd YYZU+cxj7wrlX5LMdYIY2wU= X-Google-Smtp-Source: AAOMgpfH2squbeFLsFL47IC4i8uDCfeufRoEVwzsIZe8cmJTg3n7Anr0f3RO5KSS6Ci/etYp3ZDLbA== X-Received: by 2002:a50:f9cb:: with SMTP id a11-v6mr1280079edq.26.1531379791261; Thu, 12 Jul 2018 00:16:31 -0700 (PDT) Received: from admins-MacBook-Pro-2.local (dhcp-077-250-131-147.chello.nl. [77.250.131.147]) by smtp.googlemail.com with ESMTPSA id j34-v6sm9428478edb.50.2018.07.12.00.16.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 00:16:30 -0700 (PDT) To: Alexander Azimov Cc: Tim Bruijnzeels , Keyur Patel , "sidrops@ietf.org" , George Michaelson References: <6065B77B-9981-4273-82CD-A13C3151EA24@arrcus.com> <5ee309ea-a772-df45-96cc-152726e303a0@gmail.com> From: Andrei Robachevsky Openpgp: preference=signencrypt Autocrypt: addr=andrei.robachevsky@gmail.com; prefer-encrypt=mutual; keydata= xsDiBD8L4TQRBACI+LX/GwEK23h5OXLU7iPeZc8FJ0ywH1vVqY/gT8VCs7YzbG4GNV6omEqa 0sDBF/eYKzLC5PfaKkHeAJ51eVIcDqYDhqYNlaxr5XPWWYjOIGvVRDmp4RKxhhDgXgKMmisW RrMCCP1njNQEWYtuB64UUNit1VXbQXn2FBpEXisqxwCg6hZK7Seg5md07iu9lYQx5rng+C0D /2TkPt4t80x3Iw8WV7TSLKdEQMRG42FMIFbaZIKbiEwvfaZYNrOckxdTr8l8LvwxNxHePsVi 1sqjBR8iwtogvLhSudqXxXsj2BiYfGSpTJoiVRPKdlEzo3i1mFPV/dNTSjovzWz5c21nW9kK fUIY43sLD5aynB9WITl9O6iawOrxA/0cOwOOVrpwHdLg+Uxb9y8C/1mx3o307hZDbn84Zare aiQNOn+ETI45ucON72OoMnuaBs3fJOoreXoaOSIxuM5gSQDY/SyDqncPhZmQX8yA52fuc3Ol 8qBjEomymafFymRUFvphEr/KD9BpyBZqM41zrT5VEu2tk/ga5T+bC79W780xQW5kcmVpIFJv YmFjaGV2c2t5IDxhbmRyZWkucm9iYWNoZXZza3lAZ21haWwuY29tPsJ5BBMRCgA5AhsjBgsJ CAcDAgYVCAIJCgsEFgIDAQIeAQIXgBYhBGtZeFNYETVQoSYbeZY8+bWZrYo/BQJadGb/AAoJ EJY8+bWZrYo/pGgAoNlUk0Nu3km8dAtzOlrN5bveacodAJ4jwG65QN2EhvnTgHGQEybn9IjN 0M7ATQQ/C+E1EAQAvRN7YTDiGXS9OPLX5yDKBtvjQaR38t5zpi0ltuC5JITDKZdM6/9PCfJq QnMy+ngrI3VQdhxbduFrC5fBszo1vVMTwKrTD6D7BEsEgC3wNE5NzfzE/fjl0LkQMEf5Vxns jvbtYw2jfoyJFig2gdW4ojmBCge16RZwx7vK7Pn0z6MAAwYEAJ7zZZCCU2DZ/gPdfB3xPZVm 7XSMpG6GBz4mFGgJW/QeC2quqoKBeAEgf0icEM8ykEAPmpy8f6j0Fwe/qz/SgxOXfTlvH8O7 md6rx2t2D+1PM2PlYzwO37U5fqnPuzp5KMXlPPryuTWZmObgZMHHsko9BbpIcqNHqUNXzNwk +gjkwkYEGBECAAYFAj8L4TUACgkQljz5tZmtij/lFQCdGIvMimtJEiYiPIZYSvXI6hx8WOQA oMj/ni+WopJxWu947/5RyWR6AUpH Message-ID: Date: Thu, 12 Jul 2018 09:16:29 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fwI3ke1u7ugJBN18Xx8AEZimQQMujEXwD" Archived-At: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 07:16:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fwI3ke1u7ugJBN18Xx8AEZimQQMujEXwD Content-Type: multipart/mixed; boundary="dSwXGmDQmPoEs7jqeG5Erth5ojAkUxd3n"; protected-headers="v1" From: Andrei Robachevsky To: Alexander Azimov Cc: Tim Bruijnzeels , Keyur Patel , "sidrops@ietf.org" , George Michaelson Message-ID: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items References: <6065B77B-9981-4273-82CD-A13C3151EA24@arrcus.com> <5ee309ea-a772-df45-96cc-152726e303a0@gmail.com> In-Reply-To: --dSwXGmDQmPoEs7jqeG5Erth5ojAkUxd3n Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Alexander Azimov wrote on 11/07/2018 16:36: [...] > We can consider adding additional state 'unknown' or 'partial valid'. I= t > will have similar semantics to 'unknown' output of ROA validation > procedure. But as you know, the current practices are focussing on > dropping 'invalid' routes, there is no difference in processing > 'unknown' and 'valid' routes.=20 Yes, and calling the "unknown" "valid" does not solve that problem :). You have already defined "unverifiable", which has the same meaning as "unknown". I just do not see much difference between gaps in the ASPA chain and the presence of AS_TRANS. Thanks, Andrei --dSwXGmDQmPoEs7jqeG5Erth5ojAkUxd3n-- --fwI3ke1u7ugJBN18Xx8AEZimQQMujEXwD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iF0EARECAB0WIQRrWXhTWBE1UKEmG3mWPPm1ma2KPwUCW0cATQAKCRCWPPm1ma2K P48CAKDAOEA4LPPEH8tIbmx/X9OSnHXKfgCdF2GvRvIWCLb9Ek4BVxedX0h7Hqc= =TwhI -----END PGP SIGNATURE----- --fwI3ke1u7ugJBN18Xx8AEZimQQMujEXwD-- From nobody Thu Jul 12 01:32:45 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7FB1310A9 for ; Thu, 12 Jul 2018 01:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 Sp_wT0ytXiOo for ; Thu, 12 Jul 2018 01:32:32 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 E569013107B for ; Thu, 12 Jul 2018 01:32:31 -0700 (PDT) Received: by dicht.nlnetlabs.nl (Postfix, from userid 58) id DF506D42D; Thu, 12 Jul 2018 10:32:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1531384349; bh=QHJnVTldYV+ZQsoxLwBrsybQjd5IQAViqbccDT3x/xg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=c1WI4JGYtlUiegToOwvxImd2AE9jX8bU6gt/S5JKlVHZfEry/zE9AF+MZZgB4GivW Pd8lQoyKYlZji/hehX5g5WwjRedzrrtT3iKLOjtCxVS91NJzsfTjk/eB/Go3CsWqbV BYkv8ysQq65uv8OhZU4YKYlS5ulcSBq5C2N7zBW0= Received: from [IPv6:2a04:b900::1:f1db:51dc:e61d:a983] (unknown [IPv6:2a04:b900:0:1:f1db:51dc:e61d:a983]) by dicht.nlnetlabs.nl (Postfix) with ESMTPS id E9565D421; Thu, 12 Jul 2018 10:32:28 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Tim Bruijnzeels In-Reply-To: Date: Thu, 12 Jul 2018 10:32:28 +0200 Cc: Alexander Azimov , Keyur Patel , "sidrops@ietf.org" , George Michaelson Content-Transfer-Encoding: quoted-printable Message-Id: References: <6065B77B-9981-4273-82CD-A13C3151EA24@arrcus.com> <5ee309ea-a772-df45-96cc-152726e303a0@gmail.com> To: Andrei Robachevsky X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 08:32:43 -0000 Hi, > On 12 Jul 2018, at 09:16, Andrei Robachevsky = wrote: >=20 > Alexander Azimov wrote on 11/07/2018 16:36: > [...] >> We can consider adding additional state 'unknown' or 'partial valid'. = It >> will have similar semantics to 'unknown' output of ROA validation >> procedure. But as you know, the current practices are focussing on >> dropping 'invalid' routes, there is no difference in processing >> 'unknown' and 'valid' routes.=20 >=20 > Yes, and calling the "unknown" "valid" does not solve that problem :). >=20 > You have already defined "unverifiable", which has the same meaning as > "unknown". I just do not see much difference between gaps in the ASPA > chain and the presence of AS_TRANS. It=E2=80=99s this paragraph in section 5 that threw me off a bit: If the output of the AS_PATH verification procedure is 'unverifiable' it means that AS_PATH can't be fully verified. Such routes should be treated with caution and MAY be processed the same way as "invalid" routes. 'MAY be processed the same way as =E2=80=9Cinvalid=E2=80=9D routes=E2=80=99= indicates a local choice, which is fine I believe. But, under partial = deployment this can lead to routes being dropped a little too = aggressively, no? Reading your comments in the email thread the advice = during partial deployment would be to accept, rather than drop, right? >=20 > Thanks, >=20 > Andrei >=20 From nobody Fri Jul 13 02:00:09 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48CD1277CC for ; Fri, 13 Jul 2018 02:00:07 -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, FREEMAIL_FROM=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 yyaiFecCM8uG for ; Fri, 13 Jul 2018 02:00:03 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86B5B130E30 for ; Fri, 13 Jul 2018 02:00:03 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id d3-v6so24048126edi.1 for ; Fri, 13 Jul 2018 02:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=ElymTOANP5ef2lIuKZM4L9fQEbtnE7OCB2VksANQkDU=; b=FRXb2CZMPFfDN/Px7Ew9kJWExDsQqZZrm0p2oq+iY8Y+XBa04BhXOCwnz3yIl56bwf IGjDS2sheZFe+nbp2QIZt/plrJkdPuhWwhaZtlGzmU+m601Zgq0Ge5xCNrEPYkaGNgFz KNcSxhzjgOAysvS0HAX2xxwbyKE5KLG++JHVw4SvNxkE8ksJM02T6CDhMwvgESTJ4Jqb nfGjoJYE0S8W04uCDy+n+iN/q+2kjxkJk8Pd29Viet+OHRjwBtqqfmqzdCrD+FfRR8lI MzyWWK8xKtct53tVuUnEbYtksQc4STzx+pPllFe7xfb1XNFP6rBaM45Hx7OHSLsE4AHz iEzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=ElymTOANP5ef2lIuKZM4L9fQEbtnE7OCB2VksANQkDU=; b=ApzrnogWscvbNJzV8deHKJ+bkZu6j2qX6qGnDPi7ysa4JSiB+YVgUrU/rq3neRHBGP RuFneDOQIMlxWCNoZrN2mHXsNFVUSZoQKbCs2H+edaHMR+vSSlE8qVDhWdAviz6Ow7bh p/+j6OMqRWOfOdgt/LPcORFt9Q6Mh6VoWWq6BSsCUleucrl+IR0MuZarjveYh6AWArXa jeLheY2URN4Zwq/SJ1CID8lhaaKQRgmAJWs/HWEdLSz6UwAww9Ve3xQQRZH2LBgV6LDm DLtIbsJDRphfYN508zJEHyDvVqO7y+SsHhAgl7JemP2Z4/eV+f/gWQa1kbYgX43Devti gd0Q== X-Gm-Message-State: AOUpUlGTK8G5pEa2QW4x+YaC4jjtmTAqVc21HGoDf1Exz4y8+EqEa1x0 fBQY+4n5qqJ6MW1IkHF2p6Y= X-Google-Smtp-Source: AAOMgpfZqbftmccdPvwztJ1Gj3S5PIdRbnTUL7OFljeZ/K09VqE3+xuPG/wsgyLCEGi6zLDboCFCxw== X-Received: by 2002:a50:bb41:: with SMTP id y59-v6mr6418980ede.10.1531472402153; Fri, 13 Jul 2018 02:00:02 -0700 (PDT) Received: from admins-MacBook-Pro-2.local (dhcp-077-250-131-147.chello.nl. [77.250.131.147]) by smtp.googlemail.com with ESMTPSA id r17-v6sm10199019edo.75.2018.07.13.02.00.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jul 2018 02:00:01 -0700 (PDT) To: Tim Bruijnzeels Cc: Alexander Azimov , Keyur Patel , "sidrops@ietf.org" , George Michaelson References: <6065B77B-9981-4273-82CD-A13C3151EA24@arrcus.com> <5ee309ea-a772-df45-96cc-152726e303a0@gmail.com> From: Andrei Robachevsky Openpgp: preference=signencrypt Autocrypt: addr=andrei.robachevsky@gmail.com; prefer-encrypt=mutual; keydata= xsDiBD8L4TQRBACI+LX/GwEK23h5OXLU7iPeZc8FJ0ywH1vVqY/gT8VCs7YzbG4GNV6omEqa 0sDBF/eYKzLC5PfaKkHeAJ51eVIcDqYDhqYNlaxr5XPWWYjOIGvVRDmp4RKxhhDgXgKMmisW RrMCCP1njNQEWYtuB64UUNit1VXbQXn2FBpEXisqxwCg6hZK7Seg5md07iu9lYQx5rng+C0D /2TkPt4t80x3Iw8WV7TSLKdEQMRG42FMIFbaZIKbiEwvfaZYNrOckxdTr8l8LvwxNxHePsVi 1sqjBR8iwtogvLhSudqXxXsj2BiYfGSpTJoiVRPKdlEzo3i1mFPV/dNTSjovzWz5c21nW9kK fUIY43sLD5aynB9WITl9O6iawOrxA/0cOwOOVrpwHdLg+Uxb9y8C/1mx3o307hZDbn84Zare aiQNOn+ETI45ucON72OoMnuaBs3fJOoreXoaOSIxuM5gSQDY/SyDqncPhZmQX8yA52fuc3Ol 8qBjEomymafFymRUFvphEr/KD9BpyBZqM41zrT5VEu2tk/ga5T+bC79W780xQW5kcmVpIFJv YmFjaGV2c2t5IDxhbmRyZWkucm9iYWNoZXZza3lAZ21haWwuY29tPsJ5BBMRCgA5AhsjBgsJ CAcDAgYVCAIJCgsEFgIDAQIeAQIXgBYhBGtZeFNYETVQoSYbeZY8+bWZrYo/BQJadGb/AAoJ EJY8+bWZrYo/pGgAoNlUk0Nu3km8dAtzOlrN5bveacodAJ4jwG65QN2EhvnTgHGQEybn9IjN 0M7ATQQ/C+E1EAQAvRN7YTDiGXS9OPLX5yDKBtvjQaR38t5zpi0ltuC5JITDKZdM6/9PCfJq QnMy+ngrI3VQdhxbduFrC5fBszo1vVMTwKrTD6D7BEsEgC3wNE5NzfzE/fjl0LkQMEf5Vxns jvbtYw2jfoyJFig2gdW4ojmBCge16RZwx7vK7Pn0z6MAAwYEAJ7zZZCCU2DZ/gPdfB3xPZVm 7XSMpG6GBz4mFGgJW/QeC2quqoKBeAEgf0icEM8ykEAPmpy8f6j0Fwe/qz/SgxOXfTlvH8O7 md6rx2t2D+1PM2PlYzwO37U5fqnPuzp5KMXlPPryuTWZmObgZMHHsko9BbpIcqNHqUNXzNwk +gjkwkYEGBECAAYFAj8L4TUACgkQljz5tZmtij/lFQCdGIvMimtJEiYiPIZYSvXI6hx8WOQA oMj/ni+WopJxWu947/5RyWR6AUpH Message-ID: Date: Fri, 13 Jul 2018 10:59:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hgfXn8Ttk3SDy8oRdJvR4WXVo9f9HYoWt" Archived-At: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 09:00:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hgfXn8Ttk3SDy8oRdJvR4WXVo9f9HYoWt Content-Type: multipart/mixed; boundary="vF2qP8BgMk2aYP6RuCapqgULEmhR5axw6"; protected-headers="v1" From: Andrei Robachevsky To: Tim Bruijnzeels Cc: Alexander Azimov , Keyur Patel , "sidrops@ietf.org" , George Michaelson Message-ID: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items References: <6065B77B-9981-4273-82CD-A13C3151EA24@arrcus.com> <5ee309ea-a772-df45-96cc-152726e303a0@gmail.com> In-Reply-To: --vF2qP8BgMk2aYP6RuCapqgULEmhR5axw6 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Tim Bruijnzeels wrote on 12/07/2018 10:32: > It=E2=80=99s this paragraph in section 5 that threw me off a bit: >=20 > If the output of the AS_PATH verification procedure is 'unverifiable= ' > it means that AS_PATH can't be fully verified. Such routes should b= e > treated with caution and MAY be processed the same way as "invalid" > routes. >=20 > 'MAY be processed the same way as =E2=80=9Cinvalid=E2=80=9D routes=E2=80= =99 indicates a local choice, which is fine I believe. But, under partial= deployment this can lead to routes being dropped a little too aggressive= ly, no? Reading your comments in the email thread the advice during parti= al deployment would be to accept, rather than drop, right? Yes, that is correct. A partly validated path is slightly better that non-validated and is much better than a path contradicting with ASPAs. Andrei --vF2qP8BgMk2aYP6RuCapqgULEmhR5axw6-- --hgfXn8Ttk3SDy8oRdJvR4WXVo9f9HYoWt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iF0EARECAB0WIQRrWXhTWBE1UKEmG3mWPPm1ma2KPwUCW0hqDQAKCRCWPPm1ma2K P5pKAKCgdQ/DlbibpW1lJ0kfB1ZDNg1ouACfaG0+bLWx8mJfYtzo5P4w3Q6LtT8= =aHEs -----END PGP SIGNATURE----- --hgfXn8Ttk3SDy8oRdJvR4WXVo9f9HYoWt-- From nobody Sun Jul 15 14:49:29 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE73130EF7 for ; Sun, 15 Jul 2018 14:49:19 -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 ro-2oYnYquyu for ; Sun, 15 Jul 2018 14:49:16 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0855130EDC for ; Sun, 15 Jul 2018 14:49:16 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id i4-v6so16792512uak.0 for ; Sun, 15 Jul 2018 14:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G8VET0Bl1ealFRfvhlrVmdymDvVL8XkXEzfZPH2ER4w=; b=ruH6YUYPLgJpuqeBSp+BgSSWfprcaqYnRze3BuFrn2svSrdoKbtgMnyzqe+NQJPXfg YqbpQO6RGFBbKbaRy+01S1GBNIs3YXW2Pb7vgTF2JZjQbXAnMWbP360pJnyyDQ6Mhxz1 6Zke3U9tAEuHqlEnRhb3KyNgwx1uY4SQyUk5bWTzKkk9SL97vO3L/PgC5BtNtlrD5wfe oWbXfQM6ip2AxLES60qh5BMPJltSHKJHlGYSiiJKAKflUkKRKfd3WxaDDSLYZCOBCGcX VpSNMMWlbKd3KjYVrs7cG1eRqpKqZLSlWhmzvdC5pvfuJaYlEGuL1SxGo4U0xrokex/j wFnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G8VET0Bl1ealFRfvhlrVmdymDvVL8XkXEzfZPH2ER4w=; b=SdexfXVt997tCkep9F/Uz27OHh9PgHufZAkS7m53qpMFSac26MKXX1ofBocsroLFbr 4Zcd5gIxtkEl09MNS3QCcwBBx/RzEmY+jrBh4M9SAQBs5f7M43AQC11KCoRI3yQuCGFu OkR6JIjBsPptcmkUyjNNr3ysSu4s18SgLx9FXUx7OOnwh5UgZpwGdl4sLvPp9DtFMTwS kg0FF0W5gCv0/NrOVO6liCMoj+Z/1uzTLFgwmLmW75En5bxwHg6iJNmWPsLSZ8FxfG5t vzF8dvQij4qNP3hw7w25rR9cGqySDG7ajq7maJntt12msxOl99fUH3pU3srxe0VV4k6z gw3A== X-Gm-Message-State: AOUpUlGLsE+OZkp0sk1oRsXCOUBude1BAnNi+Jqrblhz4DFwhosedB1s kJbT0toF/eoSQe9dA/GpUtg6eoMK2ItU2r+SJ0c= X-Google-Smtp-Source: AAOMgpc6osZPkeeoya3lZBgSoQIzD55cKvclxZ4eZIbWz2rFBCzGzmrj+mtut3CeV/v3eK7SEkoqI1z+OYYkcOjhKVo= X-Received: by 2002:a9f:2a89:: with SMTP id z9-v6mr9565949uai.6.1531691355599; Sun, 15 Jul 2018 14:49:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Morrow Date: Sun, 15 Jul 2018 17:49:03 -0400 Message-ID: To: Keyur Patel Cc: sidrops@ietf.org Content-Type: multipart/alternative; boundary="00000000000027f860057110af78" Archived-At: Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 21:49:27 -0000 --00000000000027f860057110af78 Content-Type: text/plain; charset="UTF-8" Last call for meeting slides... Send please, or I make ascii art .... Not of cats. On Wed, Jun 27, 2018, 12:41 Keyur Patel wrote: > Hi folks, > > > > SIDROPS will meet at IETF-102 on Monday, July 16th from 1:30 pm - 3:30 pm. > Please forward any SIDROPS agenda items you may have to Chris and me. > Please also make sure that your slides are available to the chairs by > Friday morning (07/13/2018). Slides received after the deadline may not be > available for use during the meeting. > > > > Regards, > > Chris and Keyur > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --00000000000027f860057110af78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Last call for meeting slides... Send please, or I make as= cii art .... Not of cats.

On Wed, Jun 27, 2018, 12:41 Keyur Patel <keyur@arrcus.com> wrote:

Hi folk= s,

=C2=A0<= /span>

SIDROPS= will meet at IETF-102 on Monday, July 16th from 1:30 pm - 3:30 pm. Please = forward any SIDROPS agenda items you may have to Chris and me. Please also = make sure that your slides are available to the chairs by Friday morning (07/13/2018). Slides received after the de= adline may not be available for use during the meeting.

=C2=A0<= /span>

Regards= ,

Chris a= nd=C2=A0Keyur

=C2=A0

_______________________________________________
Sidrops mailing list
Si= drops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrop= s
--00000000000027f860057110af78-- From nobody Mon Jul 16 11:03:36 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BCF130DC6 for ; Mon, 16 Jul 2018 11:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tah-HPL4DUwF for ; Mon, 16 Jul 2018 11:03:33 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 581DC130E0E for ; Mon, 16 Jul 2018 11:03:31 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id 72-v6so5972204itw.3 for ; Mon, 16 Jul 2018 11:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=jfTg8dlqU3QliDlmgBkmBxvcfNoyF/W1x85JfQiFo7Y=; b=re3rT4DUoTDiqE8ls2iT3RxMe4C9QBWfa3DwLgB4CAoF2vsA1iea8f04DhuDbrvfI0 H5B4p6FP2AoNbRgtkXEE+KfvXVh0fPQ0fkRgu/HbWu61XjVzTnvspoRs2NZs+090nJ7Z wPYm2ZyOqWvVEnJJP7kwQEf6cDqCJUfTCmMiJW35PqqTqPXVuGUA+nZOFJjs2eR5nT7c oNkaW5QTQznjVwOd3GywqSzo96qiscx2fGG3Np9486gd1ekPT+pcdyqSk/N8981pu2S/ KClwsuXsqMYrRXgFil8ZIDTyQJXsr75iju9d+xE8Pg3oD0Lwz45E1SFCpAgWVfynfEli i3cw== 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:from:date:message-id:subject :to:cc; bh=jfTg8dlqU3QliDlmgBkmBxvcfNoyF/W1x85JfQiFo7Y=; b=T98JDQ22HLa7MvJxyrd5T/FTtDvr0xGN8HtJORsMJUQsvfNY1Y+fllbL1qXhbBOGNI 4exrYYofNAWeN9fLgkCqWes/1o7eV/0eznx9bIyd2LbXN9ldrNiCY4fA2s8ncnbnNe4x RK0dcPBUdSbGRf+FOkXJweeWiUbGQpDwokB7OfnuP0DZ7dY+9ezXl9XG4vEMOBkgzXVV k+1RBgWF712xL3NjR0BBx1bc0JSSum3YA5goVOmiGhowiY2ESNwD2VLxXD6CX3Hnpp5U Uyhm3B+u6ViawcFs7AXYz3iBsZJ6TewHR9clcHBJMj93U3dHtSJQo+dX8duQ87QaHf2L noEg== X-Gm-Message-State: AOUpUlELBr7dMUY1V29zbLyQGjw7C9GBRGOZdyDOBlfpNLKFpqxuu+0x dGRR8wzV9fEAekSIuI3Qj1qyNNS5NHPUdXo7ZKBDpw== X-Google-Smtp-Source: AAOMgpcPL5PBysDLGP0gtNGo1e0tP+vomKKS04H7vIvm1aMFrs4sadGtysjQ6G288od8jzXTkg0YByXeOpoL5gPaeb4= X-Received: by 2002:a24:946:: with SMTP id 67-v6mr13428146itm.85.1531764210410; Mon, 16 Jul 2018 11:03:30 -0700 (PDT) MIME-Version: 1.0 Sender: sharon.goldbe@gmail.com Received: by 2002:a6b:2150:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 11:02:49 -0700 (PDT) From: Sharon Goldberg Date: Mon, 16 Jul 2018 14:02:49 -0400 X-Google-Sender-Auth: raqKEue0LqqrT4YYojDxv6Bpojs Message-ID: To: sidrops@ietf.org Cc: Yossi Gilad , Job Snijders , "Sriram, Kotikalapudi" , Ben Maddison Content-Type: multipart/alternative; boundary="000000000000a428d6057121a502" Archived-At: Subject: [Sidrops] draft-sidrops-rpkimaxlen-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 18:03:35 -0000 --000000000000a428d6057121a502 Content-Type: text/plain; charset="UTF-8" Dear sidrops, Drafts from my presentation today on maxlength best practices are here: http://www.cs.bu.edu/~goldbe/papers/anrwWelcome.pdf We will be revising the draft over the next month, so please let us know soon if you have comments: https://tools.ietf.org/html/draft-sidrops-rpkimaxlen-00 Thanks, Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --000000000000a428d6057121a502 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear sidrops,

Drafts from my= presentation today on maxlength best practices are here:


We will be revising the draft over the next month= , so please let us know soon if you have comments:

https://tools.ietf.org/html/draft-sidrops-rpkimaxlen-00

--000000000000a428d6057121a502-- From nobody Mon Jul 16 11:37:57 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3C2130FD9 for ; Mon, 16 Jul 2018 11:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 x8ZAyGrc8QE1 for ; Mon, 16 Jul 2018 11:37:50 -0700 (PDT) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0100.outbound.protection.outlook.com [23.103.201.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C96130EA5 for ; Mon, 16 Jul 2018 11:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xo8AlF3JSsCix8OIFTDAPjGLxXYTl75Yb7Zqjw4o71I=; b=xJ+LyIhG2WAKWM+d5cvL/TE+8/sMvUiFMwkM17EEBw72vazS9lB0uZH0NeEtH5SJdrQf36mgOVhkLfO7AbcypuhfQtUTeMEDq03HcgfwTMuHFhIiUhcnJw6cgXEEoU/4rFY93xS+2pVtqXm+G58dsfwCUSHm+CdcmTpGzvBHO+U= Received: from DM5PR0901MB2504.namprd09.prod.outlook.com (52.132.128.29) by DM5PR0901MB2504.namprd09.prod.outlook.com (52.132.128.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.20; Mon, 16 Jul 2018 18:37:48 +0000 Received: from DM5PR0901MB2504.namprd09.prod.outlook.com ([fe80::7cb3:f762:6dc3:626]) by DM5PR0901MB2504.namprd09.prod.outlook.com ([fe80::7cb3:f762:6dc3:626%2]) with mapi id 15.20.0952.021; Mon, 16 Jul 2018 18:37:48 +0000 From: "Montgomery, Douglas (Fed)" To: "sidrops@ietf.org" Thread-Topic: Off loading origin (and path) validation Thread-Index: AQHUHTQYup5AedBbvEy1/lgEQvWNuw== Date: Mon, 16 Jul 2018 18:37:48 +0000 Message-ID: <11A13993-9E51-4867-9257-CB3C66CA7C74@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180712 authentication-results: spf=none (sender IP is ) smtp.mailfrom=dougm@nist.gov; x-originating-ip: [2001:67c:370:128:9d:4a91:ef0d:43d4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR0901MB2504; 7:frGViJNQTquuN7Aq2xgvgn9ofU1vMMoE8wkcKbSmeyVrZ5XgHSJhxH/Ox/mrUZjEWKXX+ZbQbNktdIqxGkhBLuqPnrd2IWBGWWTpSlv0lJv8TFOpCWXMRXsT7YOnR1YvDwB+DUn46v+CI9gYLybXR5x64+LK+Su7m5UDfsT4L1tWdXhmv1ptkoXSijR6vvePPhuz274Z3DCqgkDL08T+w+jF94DYTxc4/sW+9fFWkGSxBu3/6e1eV8aNMOa3p+Og x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 524ba54b-00cb-4268-a8b4-08d5eb4b3b0a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:DM5PR0901MB2504; x-ms-traffictypediagnostic: DM5PR0901MB2504: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(65766998875637)(2006787148836); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:DM5PR0901MB2504; BCL:0; PCL:0; RULEID:; SRVR:DM5PR0901MB2504; x-forefront-prvs: 073515755F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(136003)(396003)(366004)(189003)(199004)(69234005)(99286004)(83716003)(5660300001)(53936002)(58126008)(6436002)(5640700003)(2351001)(316002)(97736004)(6486002)(6916009)(478600001)(6116002)(105586002)(36756003)(14454004)(106356001)(966005)(6512007)(33656002)(6306002)(25786009)(2501003)(81156014)(81166006)(476003)(46003)(2906002)(486006)(102836004)(2616005)(7736002)(186003)(8936002)(8676002)(256004)(14444005)(68736007)(5250100002)(82746002)(305945005)(2900100001)(1730700003)(6506007)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR0901MB2504; H:DM5PR0901MB2504.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: sg/juGLBA6tJgpbaoqF48/qz+6E/2Ipt809IG81a7FqrtgOiiOATymIZVsa+JKusTG9NJjc13qEXGkNm5xQnsOf2SYI0yvep+Tvx82QQv5AtGSEGUU3a0caXHW52BqJyQQ9vgEVa7xH2KxBGUBf9kloSXfmvrvGcunmBvQuQv0dBTbj28DiJUxDItYAAOLb9BHDG9OTGbSSs/t1b69akgnKTwZk8JkSwSpKGIt3Eybt2YDsrx/+FTO7IdENXNqqGJPFSnpO4hc/ySfT3ZyGZLt+Zjtw/2Rc+YW39dzmc6vSksQoBdAQIlWRqKokycL7Sw5OBxsmbD+AgVh82jWOw2ArM7Jv8kgtk52XRrlfPpiM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 524ba54b-00cb-4268-a8b4-08d5eb4b3b0a X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2018 18:37:48.7328 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0901MB2504 Archived-At: Subject: [Sidrops] Off loading origin (and path) validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 18:37:55 -0000 SnVzdCBhbiBGWUkuICANCg0KVGhlIE5JU1QgcHJvdG90eXBlIG9mIEJHUCBvcmlnaW4gdmFsaWRh dGlvbiBhbmQgcGF0aCB2YWxpZGF0aW9uIGhhcyBhbHdheXMgdXNlZCBhbiBleHRlcm5hbCB2YWxp ZGF0aW9uIGVuZ2luZSBhbmQgYSBzaW1wbGUgcHJvdG9jb2wgdG8gc2VuZCBwcmVmaXggLyBwYXRo IGluZm9ybWF0aW9uIHRvIHRoZSB2YWxpZGF0aW9uIHNlcnZlciBhbmQgcmVjZWl2ZSB2YWxpZGF0 aW9uIHJlc3VsdHMuDQoNClRoZSBwcm90b2NvbCB3ZSB1c2UgaXMgaGVyZTogDQpodHRwczovL2Jn cHNyeC5hbnRkLm5pc3QuZ292L2JncHNyeC9kb2N1bWVudHMvc3J4LXNlcnZlci1wcm90b2NvbC0x LTAudHh0LnBkZi4gIA0KDQrvu79XZSB0aG91Z2h0IGFib3V0IHVzaW5nIHJvdXRlIHJlZmxlY3Rv cnMgZm9yIHRoaXMsIGJ1dCBjaG9zZSB0aGUgYXBwcm9hY2ggYWJvdmUgaW5zdGVhZC4gICANCg0K SXQgaXMgYSBuZXcgcHJvdG9jb2wsIGJ1dCBpdCBhdm9pZHMgdGhlIGNvbXBsZXhpdHkgb2YgdHJ5 aW5nIHRvIG92ZXJsb2FkIHRoaXMgZnVuY3Rpb24gb24gZXhpc3RpbmcgcHJvdG9jb2xzLiAgIEl0 IGRvZXMgc3VwcG9ydHMgYm90aCBlLWJncCBhbmQgaS1iZ3AgcHJvY2Vzc2luZyBiZWZvcmUgUklC LUlOIChvciBhdCBsZWFzdCB0aGF0IGlzIGhvdyB3ZSB1c2UgaXQpLiAgVGhlcmUgaXMgc29tZSBj b21wbGV4aXR5IGluIHRoZSBwcm90b2NvbCB0byBzdXBwb3J0IGxhenkgZXZhbHVhdGlvbiAoaS5l LiwgdmFsaWRhdGlvbiByZXN1bHQgbWF5IGFzeW5jaHJvbm91c2x5IG5vdGlmeSByb3V0ZXIgb2Yg dmFsaWRhdGlvbiByZXN1bHQgY2hhbmdlIC0gZWl0aGVyIGZyb20gbGF6eSBldmFsdWF0aW9uLCBv ciBSUEtJIGNoYW5nZSBpbiB0aGUgYmFja2dyb3VuZCkuICBDbGVhcmx5IGlmIHlvdSBkaWQgbm90 IHdhbnQgYXN5bmNocm9ub3VzIG5vdGlmaWNhdGlvbnMsIG9yIHBhdGggdmFsaWRhdGlvbiBmcm9t IHRoZSBzZXJ2ZXIsIHRoZSBwcm90b2NvbCBjb3VsZCBiZSBtdWNoIHNpbXBsZXIuICANCg0KSSBh bSBqdXN0IHByb3ZpZGluZyB0aGlzIHBvaW50ZXIgYXMgaW5mb3JtYXRpb24gYXMgc29tZSBhdCB0 aGUgbWljIHN1Z2dlc3RlZCB0aGF0IGFuIG91dCBvZiBiYW5kIHByb3RvY29sIG1pZ2h0IGJlIGFu IGFsdGVybmF0aXZlIGFwcHJvYWNoIHRvIG9mZi1sb2FkaW5nIHZhbGlkYXRpb24uICAgIElmIHlv dSBhcmUgaW50ZXJlc3RlZCBpbiB0aGVzZSBpZGVhcywgdGhlIHNwZWMgYWJvdmUgYW5kIHRoZSBy dW5uaW5nIGNvZGUgYXQ6IGh0dHBzOi8vd3d3Lm5pc3QuZ292L3NlcnZpY2VzLXJlc291cmNlcy9z b2Z0d2FyZS9iZ3Atc2VjdXJlLXJvdXRpbmctZXh0ZW5zaW9uLWJncC1zcngtcHJvdG90eXBlIGlz IG9uZSBhcHByb2FjaCB0byBkb2luZyB0aGlzLiAgICBBY3R1YWxseSB0aGUgcnVubmluZyBjb2Rl IGhhcyBpbXByb3ZlbWVudHMgb24gdGhlIHNwZWMgYWJvdmUgYmFzZWQgdXBvbiBzY2FsaW5nIHRl c3RzLCBldGMuICBJZiB0aGVyZSBpcyBpbnRlcmVzdCB3ZSBjb3VsZCB1cGRhdGUgdGhlIHNwZWNz Lg0KDQpJIGFtIG5vdCBwcm9wb3NpbmcgdGhlIGFib3ZlIGFzIGFuIElELCBqdXN0IHByb3ZpZGlu ZyBzb21lIGZvb2QgZm9yIHRob3VnaHQgaWYgZm9sa3MgYXJlIGludGVyZXN0ZWQgaW4gb3RoZXIg YXBwcm9hY2hlcyB0byBvZmYtbG9hZGluZyBhbGwgQkdQIE9WIC8gUFYgY29tcHV0YXRpb24uICAg IA0KDQpkb3VnbQ0KLS0gIA0KRG91ZyBNb250Z29tZXJ5LCBNYW5hZ2VyIEludGVybmV0ICYgU2Nh bGFibGUgU3lzdGVtcyBSZXNlYXJjaCBAIE5JU1QNCiANCg0K From nobody Mon Jul 16 11:45:37 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7D7131184; Mon, 16 Jul 2018 11:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlrE9cIPde4Y; Mon, 16 Jul 2018 11:45:24 -0700 (PDT) Received: from mail-vk0-x242.google.com (mail-vk0-x242.google.com [IPv6:2607:f8b0:400c:c05::242]) (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 2804C13117A; Mon, 16 Jul 2018 11:45:24 -0700 (PDT) Received: by mail-vk0-x242.google.com with SMTP id l143-v6so14866053vke.1; Mon, 16 Jul 2018 11:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mngvErY3M6FP1KciCcBMv1Scw/59qmu5UHudSbUBTWI=; b=DxjwMgJPyc8CRkq2AHMNNTmVwQQtRpOhbrjG1QMTNwN/kytFmymzS0vvsttn/TWi0E E/2fQH9jGyLo0wmLdeXmQ/UksbSobhSoZIP5ZZD1SdmGcEud2xzSH/MT7i7TzNNOGAGZ mR8GvkFvBEB39eHuSwoj54cd7zDrxVW7xenVSPIH1jny8DD/BPArkDSzceW67ARCiouX HWAI9yuY1eadzGD8Dgau8ym0EUunhmELQbsuNMcNJ3Ku6FC2Ys5jY/IiLHM8sHsetu+z 1MS8V2eFfRcOnkIYkNQOppsxXhbsLqvcFwxyXWS4JMjV1pdY0ml6lwnkirf7iTni1102 LoiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mngvErY3M6FP1KciCcBMv1Scw/59qmu5UHudSbUBTWI=; b=KD62dDQbDpHjSk3DL2gLOtbP+qrqJ9wFf9p+SXdupuG0z9bJgL7ELMFGVQLv0xAP2W pFFUqhtw+NBJ5NPxIntd5eqWvaB5LjrfoYDJ4eyLCPLZAJ5nr2SjzAmhPXGZfC7VWV0l IflrBqQTn7rl1K+EGVwi6pTF0ftcgq9FQkqTCwojsxdAEw0hu2nkXNoIIaRx3lwkspVz lgBMAGUXZTjWjK2TGAOYdXJP6BRj1DGGAHbcS+CXNC7WWJY2+7GyQqBlu7XIORW97cWH Gtkb+m8ne7ZCCQT4aCPiw63XlCNC7XYRdCm2An1srMUAW9YCcl2zW5fX3r+O/WCXf4e3 SU0g== X-Gm-Message-State: AOUpUlGQSgGTuZyV6zo3vwHOIl1BrOgCoMGTyX252ISK1K3iqwZIcML/ 0ErW0kudpu2heBKGFCcGnrU8KlG0DeUN8zkn9OQ= X-Google-Smtp-Source: AAOMgpeK9XMDLcpwjzpc44BBUqgNWqDQ7c+XenMJ2rAtbRGmf463xsPM/Rrbq9fLGt46M+X6zeF+M/gbFYHsZRmq/ZI= X-Received: by 2002:a1f:8a08:: with SMTP id m8-v6mr10359398vkd.9.1531766722876; Mon, 16 Jul 2018 11:45:22 -0700 (PDT) MIME-Version: 1.0 References: <153027932808.30273.1351738789798164314@ietfa.amsl.com> <20180629135949.GA22196@hound.ripe.net> In-Reply-To: <20180629135949.GA22196@hound.ripe.net> From: Christopher Morrow Date: Mon, 16 Jul 2018 14:45:12 -0400 Message-ID: To: Oleg Muravskiy Cc: sidrops@ietf.org, sidrops-chairs@ietf.org, draft-ietf-sidrops-rpki-tree-validation@ietf.org Content-Type: multipart/alternative; boundary="00000000000065596b0571223b2b" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-tree-validation-02.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 18:45:35 -0000 --00000000000065596b0571223b2b Content-Type: text/plain; charset="UTF-8" argh, yes... this keeps falling off my plate :( Let's get the shepherds doc done and shipped. On Fri, Jun 29, 2018 at 10:00 AM Oleg Muravskiy wrote: > Dear WG, > > Since the WGLC for this document ended back in December, and there were no > objections, we'd like to finally publish it. > > I brought it back from expiration with this new version; the only > difference is Tim's new affiliation. > > Dear Chairs, > > Could you please move this document further? > > > Thanks, > > Oleg > > > On Fri, Jun 29, 2018 at 06:35:28AM -0700, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the SIDR Operations WG of the IETF. > > > > Title : RPKI Certificate Tree Validation by the RIPE > NCC RPKI Validator > > Authors : Oleg Muravskiy > > Tim Bruijnzeels > > Filename : draft-ietf-sidrops-rpki-tree-validation-02.txt > > Pages : 16 > > Date : 2018-06-29 > > > > Abstract: > > This document describes the approach to validate the content of the > > RPKI certificate tree, as it is implemented in the RIPE NCC RPKI > > Validator. This approach is independent of a particular object > > retrieval mechanism. This allows it to be used with repositories > > available over the rsync protocol, the RPKI Repository Delta > > Protocol, and repositories that use a mix of both. > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-tree-validation/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-sidrops-rpki-tree-validation-02 > > > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-tree-validation-02 > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpki-tree-validation-02 > > > > > > 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/ > > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > > > > -- > Oleg Muravskiy > RIPE NCC > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --00000000000065596b0571223b2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
argh, yes... this keeps falling off my plate :(
Let= 9;s get the shepherds doc done and shipped.


On Fri, Jun 29, 2018 at 10:00 AM Oleg M= uravskiy <oleg@ripe.net> wrote:<= br>
Dear WG,

Since the WGLC for this document ended back in December, and there were no<= br> objections, we'd like to finally publish it.

I brought it back from expiration with this new version; the only
difference is Tim's new affiliation.

Dear Chairs,

Could you please move this document further?


Thanks,

Oleg


On Fri, Jun 29, 2018 at 06:35:28AM -0700, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the SIDR Operations WG of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Oleg Muravskiy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Tim Bruijnzeels
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-sidrops-rpki-tree-validation-02.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 16
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2018-06-29
>
> Abstract:
>=C2=A0 =C2=A0 This document describes the approach to validate the cont= ent of the
>=C2=A0 =C2=A0 RPKI certificate tree, as it is implemented in the RIPE N= CC RPKI
>=C2=A0 =C2=A0 Validator.=C2=A0 This approach is independent of a partic= ular object
>=C2=A0 =C2=A0 retrieval mechanism.=C2=A0 This allows it to be used with= repositories
>=C2=A0 =C2=A0 available over the rsync protocol, the RPKI Repository De= lta
>=C2=A0 =C2=A0 Protocol, and repositories that use a mix of both.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ie= tf.org/doc/draft-ietf-sidrops-rpki-tree-validation/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/ht= ml/draft-ietf-sidrops-rpki-tree-validation-02
> https://datatra= cker.ietf.org/doc/html/draft-ietf-sidrops-rpki-tree-validation-02
>
> A diff from the previous version is available at:
> https://www.ietf.= org/rfcdiff?url2=3Ddraft-ietf-sidrops-rpki-tree-validation-02
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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/
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org=
> https://www.ietf.org/mailman/listinfo/sidrops<= br> >

--
Oleg Muravskiy
RIPE NCC

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--00000000000065596b0571223b2b-- From nobody Mon Jul 16 11:48:48 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D5513118A; Mon, 16 Jul 2018 11:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfrQwFjKh3hL; Mon, 16 Jul 2018 11:48:36 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423CD131185; Mon, 16 Jul 2018 11:48:33 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id s23-v6so22228168vks.7; Mon, 16 Jul 2018 11:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=17ED2XWePZETsXAtR77LHg69wmrJWdfbYOx/EPBb+zo=; b=JmM5k/IP5dWnXpsLxpoWOkzKLqSpO7My17vA+vU5x0Y5ETvXw12d2K9xiZpKcs1GJm Ku/hQY305Cdm5rbqY35aBi3fSudbOpWbl2dB6fYs5gHsZ8e83BIG70tJoUxC3Z1Q8mIB recA36mdZepJWseWp7kAmiqmq2LRP3E1F60YJW4u0S/gimsKlx2P3Vdgounw5id2qSUF 73RfZPWnRmexAtxNEBUNSG1ommUOmNJzLd0dPrb1XMTggCaK8KhgRm2kmwvB7wapccNW YJWGbdr3dw46YE3n2BSf0Nul0l70v8pU6abPa2Ot+d/VKHDRIycJFHMxgiCzjS5gNGgz /Q7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=17ED2XWePZETsXAtR77LHg69wmrJWdfbYOx/EPBb+zo=; b=RPrH6K+VX78Zz9LgXh7gYXVNuxbSHZpmdFvSNfcpaEwc6po52Pe6omTuJQSha5figD yCT3wnKV3TwVowgMKnMq9JBSa+eicGIhrOpRT8AGcYakShd7e/ROLWUlctsjUInnew61 T7LfTXTVFo+vcs1m97W732fbzCa21E1a/WgjLcwW8efF1vXIjijeGAxdX9LjCIYC4BGX WtV9nbC+OAWEoCYqjRXgzin5fZMuiCdPaaChfpiJZJ9zFETMHoJANbzI6cn3lpXYr9sm IFUrE3evJH/Vu9AAEYYmBojHrS5GrmIFux7DgiSkcJg0+162ZbTB2qENvhGx/Bx7WAb+ SPew== X-Gm-Message-State: AOUpUlE50X+uxZSluxC8qRK0vByBWa41vSgbh1OSdbTQhd1ucJv1RAHY tSDd4/vznBMU7RVa4S1p+DOA/ATPOQx8aBca2iJatQ== X-Google-Smtp-Source: AAOMgpcYUNGNeVN75n2/AulKiW2MsCtAaNlQVZoLzsABm4V8xHzWtylrJKjgN9x9vRv2zlKKuUYVV7w1GGeX1t+u3Lo= X-Received: by 2002:a1f:8a08:: with SMTP id m8-v6mr10364260vkd.9.1531766912240; Mon, 16 Jul 2018 11:48:32 -0700 (PDT) MIME-Version: 1.0 References: <4C633713-FC03-4C99-B8A6-C40F17D401E0@rpstir.net> In-Reply-To: <4C633713-FC03-4C99-B8A6-C40F17D401E0@rpstir.net> From: Christopher Morrow Date: Mon, 16 Jul 2018 14:48:21 -0400 Message-ID: To: Di Ma Cc: Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org, sidrops-ads@ietf.org Content-Type: multipart/alternative; boundary="000000000000aee06005712246f6" Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-rpki-tree-validation - ENDS 12/4/2017 (dec 4) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 18:48:47 -0000 --000000000000aee06005712246f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Apologies to the WG, this call ended with folk being in favor of publication. we'll get the next step started today. On Mon, Nov 13, 2017 at 4:17 AM Di Ma wrote: > I have read this document many times~ > > I think experiences from RIPE RPKI validator, as one of the RP > implementation pioneers, is worth sharing with the routing community. > > I support publication of this document. > > Di > > > =E5=9C=A8 2017=E5=B9=B411=E6=9C=8813=E6=97=A5=EF=BC=8C10:36=EF=BC=8CChr= is Morrow =E5=86=99=E9=81=93=EF=BC=9A > > > > Howdy SidrOps folks, > > > > Please consider this the WGLC for: > > draft-ietf-sidrops-rpki-tree-validation > > > > Abstract included: > > > > "This document describes the approach to validate the content of the > > RPKI certificate tree, as it is implemented in the RIPE NCC RPKI > > Validator. This approach is independent of a particular object > > retrieval mechanism. This allows it to be used with repositories > > available over the rsync protocol, the RPKI Repository Delta > > Protocol, and repositories that use a mix of both." > > > > I believe this is IETF week, plus a travel week, so the WGLC is 3wks > > long instead of the normal 2wks. Please read/review/comment on the > > document so the authors can adjust as necessary. > > > > -chris > > co-chair-person > > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --000000000000aee06005712246f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies to the WG, this call ended with folk being in fa= vor of publication. we'll get the next step started today.

On Mon, Nov 13, 2017 at 4:17 AM Di= Ma <madi@rpstir.net> wrote:
I have read this document many times= ~

I think experiences from RIPE RPKI validator, as one of the RP implementati= on pioneers, is worth sharing with the routing community.

I support publication of this document.

Di

> =E5=9C=A8 2017=E5=B9=B411=E6=9C=8813=E6=97=A5=EF=BC=8C10:36=EF=BC=8CCh= ris Morrow <= morrowc@ops-netman.net> =E5=86=99=E9=81=93=EF=BC=9A
>
> Howdy SidrOps folks,
>
> Please consider this the WGLC for:
>=C2=A0 draft-ietf-sidrops-rpki-tree-validation
>
> Abstract included:
>
> "This document describes the approach to validate the content of = the
>=C2=A0 RPKI certificate tree, as it is implemented in the RIPE NCC RPKI=
>=C2=A0 Validator.=C2=A0 This approach is independent of a particular ob= ject
>=C2=A0 retrieval mechanism.=C2=A0 This allows it to be used with reposi= tories
>=C2=A0 available over the rsync protocol, the RPKI Repository Delta
>=C2=A0 Protocol, and repositories that use a mix of both."
>
> I believe this is IETF week, plus a travel week, so the WGLC is 3wks > long instead of the normal 2wks. Please read/review/comment on the
> document so the authors can adjust as necessary.
>
> -chris
> co-chair-person
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org=
> https://www.ietf.org/mailman/listinfo/sidrops<= br>
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--000000000000aee06005712246f6-- From nobody Tue Jul 17 08:37:53 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C00D130EC2; Tue, 17 Jul 2018 08:37:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Chris Morrow To: X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Cc: sidrops-chairs@ietf.org, keyur@arrcus.com, sidrops@ietf.org, iesg-secretary@ietf.org, Keyur Patel Message-ID: <153184185443.12831.12173554729993254023.idtracker@ietfa.amsl.com> Date: Tue, 17 Jul 2018 08:37:34 -0700 Archived-At: Subject: [Sidrops] Publication has been requested for draft-ietf-sidrops-ov-clarify-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 15:37:49 -0000 Chris Morrow has requested publication of draft-ietf-sidrops-ov-clarify-02 as Internet Standard on behalf of the SIDROPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-clarify/ From nobody Tue Jul 17 08:50:19 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CA1130EE4; Tue, 17 Jul 2018 08:50:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Chris Morrow To: X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Cc: sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, iesg-secretary@ietf.org, Chris Morrow Message-ID: <153184260506.12756.16121848710362075794.idtracker@ietfa.amsl.com> Date: Tue, 17 Jul 2018 08:50:05 -0700 Archived-At: Subject: [Sidrops] Publication has been requested for draft-ietf-sidrops-rpki-tree-validation-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 15:50:16 -0000 Chris Morrow has requested publication of draft-ietf-sidrops-rpki-tree-validation-02 as Informational on behalf of the SIDROPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-tree-validation/ From nobody Tue Jul 17 09:39:28 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5C3130E80 for ; Tue, 17 Jul 2018 09:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7J3qHKB3fr6b for ; Tue, 17 Jul 2018 09:39:23 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C26A7130DCF for ; Tue, 17 Jul 2018 09:39:23 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id d191-v6so15070674ite.1 for ; Tue, 17 Jul 2018 09:39:23 -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=zbmlfnqcWH6vP54IJTy0+eXn/mEFKTzOTBQWAT0sUBQ=; b=DdxNppUggeUZqJ1G/q/DdA7Kkh26G1HL0HnVXHNIkliaDcR9ubug9PrJ473saUE8YW SKlnl+x/+7tOQP6UmSu47zmhHne/uKrMQnGO/1IYtmc3Zig5d/w4178Ewr4XoXpQj1sa +tuXV+6K0mmtHpy5u3enjSUsgGdT6kaMtnynX7PsnSUQBg8/n3MibYRO7mEsnz3w026U GFLTkdKk7FtcXDKd+W4/wuvihpNqZxpaYWstFdfHajTL/wy1uaZN3RV/OVLnm5MB444t v2rw4dmFhGLF/INpIqPJ5yLcmVc6H2YJWElS8hoHkF+CAQlKW9imZ02CzChRqtsiapX0 z4aA== 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=zbmlfnqcWH6vP54IJTy0+eXn/mEFKTzOTBQWAT0sUBQ=; b=sGNeuD0hyaCM3agcg2bDkSD/+Nb19rh9m0sUcY9xaOVad8Gj4BltnAzBX6+0S98TYP GYZvZBCS45r0yRI56eFdhetzg9Ry/OBmFKipDS//X7LrnuFSORv8z7v9HG3bnV12j6dP /0o17LMCNZcGSC9Vc8jQ4hf0nVY/NF/nK2KqNaiutHKbUncQnrUs0Wib+GSWElFqZoOg rqqHmDyxxsOtmmtvbnWrmKdveHKuwsi5NAxo38IPQ3Gfa9B9TRafhskyKl5r3TCIg7XC AFQUQRfGumRE5/vQ66LSXOFWYDOGCiebAo1g1H6tUSfCqClzV4zN52C4m7cMhyYQ9S5X /SzQ== X-Gm-Message-State: AOUpUlEZI+nujCnGa8ZTs1UJpjGHyAY+oOjNZG701/eQaAs+2qUtMTNx IjmcNggaQmvun8xcT7iT4xqO2S+TvSBrRz2xDwQTnzQj X-Google-Smtp-Source: AAOMgpfXTImHISXUmJ62RXJXA/6RFL9u7UrjYuYgDeaz9Vl0B8KQTRFqcmu/teid6PFTaAOHAI6gDLDjdYxbQyC6hRs= X-Received: by 2002:a02:1c48:: with SMTP id c69-v6mr2199764jac.65.1531845562987; Tue, 17 Jul 2018 09:39:22 -0700 (PDT) MIME-Version: 1.0 Sender: sharon.goldbe@gmail.com Received: by 2002:a6b:2150:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 09:38:42 -0700 (PDT) In-Reply-To: References: From: Sharon Goldberg Date: Tue, 17 Jul 2018 12:38:42 -0400 X-Google-Sender-Auth: YDkp7YdWthogDZtnr1c1SPFNFfQ Message-ID: To: sidrops@ietf.org Cc: Yossi Gilad , Job Snijders , "Sriram, Kotikalapudi" , Ben Maddison Content-Type: multipart/alternative; boundary="000000000000a1fb4e057134960a" Archived-At: Subject: Re: [Sidrops] draft-sidrops-rpkimaxlen-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 16:39:26 -0000 --000000000000a1fb4e057134960a Content-Type: text/plain; charset="UTF-8" Sorry. The SLIDES are here. http://www.cs.bu.edu/~ goldbe/papers/maxleng_ietf102.pdf Sharon On Mon, Jul 16, 2018 at 2:02 PM, Sharon Goldberg wrote: > Dear sidrops, > > Drafts from my presentation today on maxlength best practices are here: > > http://www.cs.bu.edu/~goldbe/papers/anrwWelcome.pdf > > We will be revising the draft over the next month, so please let us know > soon if you have comments: > > https://tools.ietf.org/html/draft-sidrops-rpkimaxlen-00 > > Thanks, > Sharon > > -- > Sharon Goldberg > Computer Science, Boston University > http://www.cs.bu.edu/~goldbe > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --000000000000a1fb4e057134960a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry.=C2=A0 The SLIDES are her= e.=C2=A0=C2=A0http://www.cs.bu.edu/~goldbe/papers/maxleng_ietf102.pdf<= span class=3D"gmail-HOEnZb" style=3D"font-size:12.8px;text-decoration-style= :initial;text-decoration-color:initial">

Sharon

On Mon, Jul 16, 2018 at 2:02 PM, Sharon Goldberg <g= oldbe@cs.bu.edu> wrote:
Dear sidrops,

Drafts from my pr= esentation today on maxlength best practices are here:

=
http://www.cs.bu.edu/~goldbe/papers/anrwWelcome.pdf

We will be revising the draft over the next month, s= o please let us know soon if you have comments:

https://tools.ietf.org/html/draft-sidrops-rpkimaxlen-00

Thanks,
Sharon=C2=A0

--
Sharon G= oldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe



--
Sharon Goldberg
= Computer Science, Boston University
http://www.cs.bu.edu/~goldbe
--000000000000a1fb4e057134960a-- From nobody Tue Jul 17 09:59:03 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B70130DBE for ; Tue, 17 Jul 2018 09:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.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 g3mTACPJ1n0C for ; Tue, 17 Jul 2018 09:58:57 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0072.outbound.protection.outlook.com [104.47.126.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08E35124BE5 for ; Tue, 17 Jul 2018 09:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.onmicrosoft.com; s=selector1-apnic-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RqXsH20IHbEF+qARh4uUICJGLC+ikr8XeW0CfLW9RBo=; b=JFuT/BSzPuzdjI7cDS0y0Lsn9tmmfr3nGCYtRNakcBt4i5ofZHKEkTTyI1hRe2vxG2n/2t8+w+R69Pa2RQ1e+duZzrPoowhXYgfO/Ro8NYC3k2yfRHpSM8KFZdM61HBEXl/YySscQ+rpuc156UiiXMuZt0I9sXXokBdeHC0wKs8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=tomh@apnic.net; Received: from localhost (31.133.158.237) by HK2PR0401MB1460.apcprd04.prod.outlook.com (2a01:111:e400:7a08::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.18; Tue, 17 Jul 2018 16:58:50 +0000 Date: Tue, 17 Jul 2018 12:58:27 -0400 From: Tom Harrison To: sidrops@ietf.org Message-ID: <20180717165827.GA14191@tomh-laptop> Mail-Followup-To: sidrops@ietf.org References: <152846464123.15396.14579027912013078144@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <152846464123.15396.14579027912013078144@ietfa.amsl.com> User-Agent: Mutt/1.10.0 (2018-05-17) X-Originating-IP: [31.133.158.237] X-ClientProxiedBy: DM5PR13CA0035.namprd13.prod.outlook.com (2603:10b6:3:7b::21) To HK2PR0401MB1460.apcprd04.prod.outlook.com (2a01:111:e400:7a08::26) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8e64f7c2-a470-4b98-3823-08d5ec069255 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:HK2PR0401MB1460; X-Microsoft-Exchange-Diagnostics: 1; HK2PR0401MB1460; 3:1mmeKugtf75UJuyIJNa6udsCN5Kraw0hKtSwVtlbxbq9UCsEm6RqFJCTyDDrz1fEOfyjilXOZW5TYIPW0fTx4Zdhqp1Z3Qg5tWDexxqBsUdP/rRLYenYuEgla/YOgjGGD5z5gV8yZQgeEu99FHklgAv1a/AU6SaUbSA5Q28HSWOkqfvF/w/l3+4dlbwN8gEWc6VocbTTJ79K3tHVp5jtXnkWY9p4kt6cjswiYa8wqPX9jkc/V+XJr1ftJ12Zs+Na; 25:bLstH9ll69aewO8eW3bXBFz6fxGPu1NoF68lH9m11MvcJkVoMGEnw2VLucfsR2iPW6hn3G2q4Mnv7qpKwpC0/gaHJCuXWV/aYrEGZpO/EmwHeslZWkvdt4KaqP9AB/5Xhx52afngPrJ6VrDBqCeDcXwJ3w/4xE3bTsIDKdNz6zSxqihmpBzCXs2rjwnMLyYM7/GL4k684oxVLzT0BO/tFMc5q39nLLiYpU+l4V8f1Xl1H0Z3yMrp3t9KeH63s5QanrwyIgyOJ0iTJ0pNWRqnya3y//NrxNH5//Jux3Ti1ZyrPBGa3tYatIrzz+utYPjPWOJHYEky3FiTgU5/YpAp3A==; 31:BtouBZJCfrYMVQr/VlznWw0fPhfBYBy+GNcHsMf5+y32WS9WdBvkMoLnY58o0Mh9wh33qmJxd1LplPw3NcLrV73w8HB0pBkSgfZJ8lV6KDgeQA09VC7d0rjdAFI4a2sOCi5NKcLG0tMGOE4HXjVllVcZGyitJbpHTeRoBOv3yJttax963e0/1UTBSSOLJAGlYE0lcWI/3nZhlbDsGTv4lqImtK2VK8n4qkCAVtpEnqg= X-MS-TrafficTypeDiagnostic: HK2PR0401MB1460: X-Microsoft-Exchange-Diagnostics: 1; HK2PR0401MB1460; 20:af90qjrQ2Q4t5bULarlvEl2Qf2T7ayLrkmF0sJVK+TTnaTbW+4hMwatK6hMDDluxutCCj5uLkUWKWOBUa/6dqr8LIVJpaPurKSCob+77s7lpOrCwBSXoAkzzTfDOO9wcHNmxnVhZDiEtwCZBXVU6d95gymttgUPjRbs7t49NmGeQE71OUgsOoeeFCmfk+tnnROJujvxd93co4MaJfIJ+RXxmrsmRJ4TECdvfEkLCeehgXyng0evOhCnUKZpj9JXu; 4:U+IkTs2OD4V4CtQaspuH2Jkg1+EZmNbawYkQdb+h4CSWsDPtq6+WeAXideRVXb7pQCgWVGDl2fUEGU96/s0H+5czEm+SmX22UY9Swu1eibLF0G04fNHtRQLo7dzEzk8CtCJX8hpyDI5rIITXIcYE2vaNxMNSGpJNgVOaZ6IKS2lEKYS4K/8vVSI6LiQSLAErjhHQROAG2Su/+cJQxWsssgtwYDMCGizCRooykvHTphvUlWwZyTsyHmUlq+sKCv688ilFy3JlOV5mFCWh7Ybfxg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(149027)(150027)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:HK2PR0401MB1460; BCL:0; PCL:0; RULEID:; SRVR:HK2PR0401MB1460; X-Forefront-PRVS: 073631BD3D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6069001)(7916004)(366004)(39840400004)(346002)(396003)(136003)(376002)(189003)(199004)(229853002)(6666003)(8676002)(6496006)(33656002)(2906002)(305945005)(8936002)(6916009)(2351001)(7736002)(52116002)(6116002)(3846002)(68736007)(2361001)(47776003)(446003)(81156014)(11346002)(81166006)(478600001)(6486002)(66066001)(23726003)(1076002)(76176011)(33896004)(25786009)(5660300001)(26005)(386003)(486006)(105586002)(9686003)(86362001)(33716001)(106356001)(6246003)(58126008)(50466002)(97736004)(14444005)(16526019)(76506005)(53936002)(186003)(316002)(956004)(476003)(16586007)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:HK2PR0401MB1460; H:localhost; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: apnic.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; HK2PR0401MB1460; 23:/pU+pUhqpFdy88pCqOCZ/Hx4IFsHI69R8O2h1RX?= =?us-ascii?Q?cTv3KvXbwIWr3BxzQ314XnKqGrpvjAySp+IWwSSbAgSLeDgbbD9UpmtIoYHp?= =?us-ascii?Q?RclA0juoxJ1PbVrR8yQbnvckVYuPcaeokPWDoysyaKqln/H2D7Xhyc3kq+iv?= =?us-ascii?Q?VqTsK5GKr76zWUwwE7HW0Vzs+CeVgyNvPbjMOBSI4iAyV0d94WwdS+8CuNIc?= =?us-ascii?Q?Muqj9E/IQIaKPEF+9SnV0qUbNMH0JwpNlUoLYG3SP56f9Oyojr78HhewKBOb?= =?us-ascii?Q?Uhcl8oYNtRLXm6pelC5FAPGhyvAMSRSe0JjijYIDC86b9BiMv+N7IDw7wT6I?= =?us-ascii?Q?4sbIL3ne5MVBUMaq43imK/ttzR9O3Zmq+/32uoIfFsyD5BSF/lkcXdMZR1X1?= =?us-ascii?Q?3ohGyC8En4Nc8QQGlN6+O0O3lHvfIyu6nDJqD/24gVR4226bO1wxpM0LXs+M?= =?us-ascii?Q?SDiNxmiwkec2DAH9SA5zHPKhj5jnMs1GdhTZOw3h03lBYh693Q/xNsFeByEw?= =?us-ascii?Q?OZkfzlbhkfKLh7E24ItOqUbvU0iMC+tkiyHWKkBihj5dM1TidB/sbRR0RIWg?= =?us-ascii?Q?PUMPcy+E8Q7vbw/9A9KKpoHjlwApaofpTiZin8K4fs6nNzNGI2utdcp3Rzkf?= =?us-ascii?Q?+7dVCZOEst3W0W1yZ/GYzcK5vDkgPzeZ84Rh3+fXDSbjSm483UtVVp+7ybW3?= =?us-ascii?Q?E2VU/aAnbAB95ULxaoMnAjzAWEeQmYiUg8H0BkVonuINjLWLSBNArvJzqOOm?= =?us-ascii?Q?WlUH01UE15CEjtFWEHaJHWRmiNWIg3xeqRVtcyF/3hR/yyTc1RQ20VO4jeLB?= =?us-ascii?Q?YNg5QNRSXphoSjnmi7HWu/Trd2bpLPUzE06jyeItMBYBkyMlnnCcjKZh/Zxl?= =?us-ascii?Q?AnC1+NzGeeNzfYu7v/BWomVDZPIyvOlxGvkPCJAsV7V5NoDWmESorH0Tm3ds?= =?us-ascii?Q?tho1I+H1FDZkV6wdYLstlKWR6ZU8PliOK+sScWZAcZ/hCN5neNl02qeIuRqd?= =?us-ascii?Q?wydxweFAy4V7BapJsu3iK5hN66N+2co3bw0WzJnxuEzqVfme/bzKTpw41s7b?= =?us-ascii?Q?ktiqhPtIdCmfDoHBZCcgOIHCZduvtpss5qdikQ30QU3qzCp7w0JfNAjOVbpA?= =?us-ascii?Q?hcdK0v1NBoFucvgTX2m9zDWY30AGsJ+RuVm7fQLrVM23TVjeem779k6tg9CK?= =?us-ascii?Q?eqEuHkBZkzbCBTB76CT8yLZK2SEnHPjHn62yF7QbX8L38gr+1hherNIW7HTY?= =?us-ascii?Q?R77yiB08bf6Wl3svvbcKbulJFesD9HFfc7+gJeqR/Fb+d+AnOmSAKA6pwqy3?= =?us-ascii?Q?ddo++2QvZVHhLkm6vV+b63ORqLb0mRFWUQAUM2NgzJ7vTQzaZFP/nQntxA8h?= =?us-ascii?Q?zMO5T4Q=3D=3D?= X-Microsoft-Antispam-Message-Info: Ryvefs+ln9JitrOol1cEfLsPsCe4kytueem2FdvwtLD1lBys1i/umVk0J5f6yWjunt12RuMkViR7l1/J8jglU0/JyIqe2H9S3yeaWeuT/cGwKlNRqgSioWAFxludKD06b3fNjCvnnF01aAmkBmW34z+VEFxfgEQ2TegtdPYC+o1NfFMDrVqCGEJ7PQtVs3kzhWLPiB601qrWj5lCZ9ExIXh3rBT9Sdifgl2C0vpDlvSbKJ02cihDoC5xnVctRcv5fwN8RsNBLyApQo1944214031jZ5K0x15sN+DLbSwp9U+hQXxEs9xT7sY6o8En7D0R5Xm1Ms4nx/q6fIzAMKx3tZOviY56A6qWYndhWWq0ec= X-Microsoft-Exchange-Diagnostics: 1; HK2PR0401MB1460; 6:OJIsUcHOKDbWmpbtnRya6XRVRq/gx6USzAUoSozSSuUC+pd2aXaYfdVmJomCr7Ht3m2pukC0FBqoGKVtN9mPcExUqxOEldBtbz+mJYeYNfndTeMZt+eQFu3B3ljo287AnDbkx5vD3SJINjf6o/vCcVn6WzrOzac7wiWn851pKDPjFv34QZdfOHHla6RspEvhuBv6vVqvrOSbX66RuBZ516uqFX9laeJaQE58pGAovp65qmMGNqzIkhS21zVU+dcsl9CtvwW4yGp1WtSUmmt/Dn3U+wlfpL5bhcAse+2LNo9itQDP+25MxS4apZLAH/QdJPSCEODLfllO5a8IJixrAfaud6GrmJ01oyvjaelk/sUm+mmkIYMKkRd609haG2wVufv76eYkxATIlvg60mQ/dhZDD2+of/RlT19jH725FTTbRa74pSfOpHmjSt+yLIip7SUE5S8I7B0pvlIbXmP3gg==; 5:ciGMagdUM2EWby4CpYppkGxP70i7Qj73F3OfZ4UCvaWnDy7AcAbO4Ib0gCsTK6hjzV9kz3zeR2Q6FqviJvBiWe7ndDbygfAhra9mT/bW/LGCRgA1f3x3g3lDJvG1ElgM4jvhJSP8X1ozy9DiANdQIfeVksxWi+02VOE9qfUvJK0=; 24:PRTle79JumTnoOIzZGjLHh+jMacECdbxh9P6xOKhnsEaPqB7hrsqHSfxbMa3bV/MHnk7wqsZASq2x8Fjc1uwRv/cEaVTfW5vQNf5ytybX0w= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HK2PR0401MB1460; 7:1vHl/Nwl5LoFArvJw6Ixq8vk81UtqLNHclw5Tdi2W6V/7ibOkADQWtkS94b98OydJ0Rg+jaiMwyThCiYJ6vv/cPorNyBPSpNobMltA4/zXFSVy6LKphgy1uoainmabnsGJ1HNCVc6qpENntaEv6Sxcs0YhQ4SHWY8VcnWPO4u9CY3d4wMe5lNs1JY5FyzsZ43+Xv8x76FTWtiwGra5HIfGhodvHm1vSfERDkUEhNqPNt8OxbNPK6rORLS5rXbn9W X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2018 16:58:50.6341 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8e64f7c2-a470-4b98-3823-08d5ec069255 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2PR0401MB1460 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 16:59:01 -0000 On Fri, Jun 08, 2018 at 06:30:41AM -0700, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SIDR Operations WG of the IETF. > > Title : RPKI signed object for TAL > Authors : Tim Bruijnzeels > Carlos Martinez > Filename : draft-ietf-sidrops-signed-tal-01.txt > Pages : 12 > Date : 2018-06-08 I've updated our proof-of-concept to match the new draft. Some questions and minor suggestions: In section 3, there is: The ASN.1 syntax for the Signed TAL eContent defined in Section 3.2. (This is the payload that specifies the AS being authorized to originate routes as well as the prefixes to which the AS may originate routes.) The text in parentheses looks to be a cut-and-paste from the ROA profile document (RFC 6482). In section 4, there is "[t]his EE certificate MUST have a 'notAfter' time that reflects the intended time that this Signed TAL will be published", which on its face implies that the 'notAfter' should be set to the time when the object is first published. Changing it to "reflects the intended time [or duration] for which this signed TAL will be published" should make things clearer. The SubjectPublicKeyInfo in the TAL structure has the type IA5String. Is there some reason not to use the 'raw' SubjectPublicKeyInfo type from RFC 5280? Since activationTime is not needed for an in-protocol reason at the moment, it would be good to add a note to the draft that it's there to prompt discussion/feedback about future dating. On future dating more generally, I think it's a good idea, since it allows for in-band signalling about the rollover and would (hopefully) encourage a wider set of users to test the new tree before it becomes the 'official' tree. -Tom From nobody Tue Jul 17 14:52:40 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F440130E43 for ; Tue, 17 Jul 2018 14:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_DKIMWL_WL_MED=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bg4nMNZFI_aX for ; Tue, 17 Jul 2018 14:52:35 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7344B130E2C for ; Tue, 17 Jul 2018 14:52:34 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id q20-v6so1343478ith.0 for ; Tue, 17 Jul 2018 14:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nlnetlabs-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AhhmHzGmM8/m7sJK9mAsUvgT6cNhd/C6OnsdQjKbZmA=; b=sS3J4EWsBOHE4em9/1eH2dKrcDNJGeHGPTs561MEFCW9JVaXM+39AuToA9szBHOG1x Oc4cMR9uoFE2XGmDNfF26Ar5na9bq3Te3393hxOq4QHoU7eRKLFrazCd1DzWVbbV9m0t RuYqdNPdXqwgxKGazDXoYtZfl3kYNZOI3sjVkepvFavSJxCBIOfhB2zkBbySykLZFSDp C0MMZhgQ2XFRi+Is4JJoXpbAYGt4BHItnao6bWQRH0+9QQQbqViyA3ILu+2Boaw6FMSt OtDzPUTevHVUBuR4R03re1BDDyE6TrcV+9icfRlIlv9WHtWh6aHcHxw+f4HCNmlog6Lw +Acg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AhhmHzGmM8/m7sJK9mAsUvgT6cNhd/C6OnsdQjKbZmA=; b=FR5pwcClcO/i+B/K6ZX40gGx11bIphC3v87vutD6WrlkkR9DBraexpBEsg06IMTV/7 8N5OsMWBduzFStwz/BDcHNNa1v8usqnxY6IQ2fWD6rpzG2f+boiNd5qdQFEQdVdyQpiI 7yUyLqADoyEOl+fw+qajKKBWzHs5pvxpgo27gopOT0bVlTniNb9QU97/o1odnEYQnmju 51ngl5ejSwqlDup3zxGqBaWKlaP9vEGNPUlqf2CByulC8qnteNBiuUIsAZH2nCnIVMiN wQz/hDTHUf5e7eFWjG9d4nwScxBbEMjdwJ9kz5mDlriQo+0dSgInLb9hFkd/k3idcFk4 B80w== X-Gm-Message-State: AOUpUlEDD52nJUKQ9dEOdEae+chCfz7gPQ9Eywoivun9CBzWEFWVlxYz qDN8Gorh9KegiOkrwoVFa4EJSSwPVkw= X-Google-Smtp-Source: AAOMgpeTK97gzPyPy9FsgRQ/IVVoq9SdWhn2cecBS/X+Er5+6FH2UPeeOi4N6O/d9KFOjzWHw+2nLA== X-Received: by 2002:a02:5658:: with SMTP id o85-v6mr3173332jab.135.1531864354317; Tue, 17 Jul 2018 14:52:34 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:39af:6c5c:df41:8987? ([2001:67c:370:128:39af:6c5c:df41:8987]) by smtp.gmail.com with ESMTPSA id 16-v6sm369981itk.15.2018.07.17.14.52.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 14:52:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Tim Bruijnzeels In-Reply-To: <20180717165827.GA14191@tomh-laptop> Date: Tue, 17 Jul 2018 17:52:32 -0400 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <152846464123.15396.14579027912013078144@ietfa.amsl.com> <20180717165827.GA14191@tomh-laptop> To: Tom Harrison X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 21:52:38 -0000 Hi Tom, Thanks for testing and the feedback. Comments below. > On 17 Jul 2018, at 12:58, Tom Harrison wrote: >=20 > On Fri, Jun 08, 2018 at 06:30:41AM -0700, internet-drafts@ietf.org = wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the SIDR Operations WG of the IETF. >>=20 >> Title : RPKI signed object for TAL >> Authors : Tim Bruijnzeels >> Carlos Martinez >> Filename : draft-ietf-sidrops-signed-tal-01.txt >> Pages : 12 >> Date : 2018-06-08 >=20 > I've updated our proof-of-concept to match the new draft. Some > questions and minor suggestions: >=20 > In section 3, there is: >=20 > The ASN.1 syntax for the Signed TAL eContent defined in > Section 3.2. (This is the payload that specifies the AS being > authorized to originate routes as well as the prefixes to which > the AS may originate routes.) >=20 > The text in parentheses looks to be a cut-and-paste from the ROA > profile document (RFC 6482). Fixed in my edit buffer. > In section 4, there is "[t]his EE certificate MUST have a 'notAfter' > time that reflects the intended time that this Signed TAL will be > published", which on its face implies that the 'notAfter' should be > set to the time when the object is first published. Changing it to > "reflects the intended time [or duration] for which this signed TAL > will be published" should make things clearer. Yes, you are right. The intention was duration. Fixed in the edit = buffer. >=20 > The SubjectPublicKeyInfo in the TAL structure has the type IA5String. > Is there some reason not to use the 'raw' SubjectPublicKeyInfo type > from RFC 5280? This is an oversight. It should just be the raw DER structure. > Since activationTime is not needed for an in-protocol reason at the > moment, it would be good to add a note to the draft that it's there to > prompt discussion/feedback about future dating. >=20 > On future dating more generally, I think it's a good idea, since it > allows for in-band signalling about the rollover and would (hopefully) > encourage a wider set of users to test the new tree before it becomes > the 'official' tree. The current draft assumes that the TA tests things before publishing the = new signed TAL object, and then I think it would be okay for RPs to = follow this new TAL as soon as it=E2=80=99s available. But.. there may be good reasons for future dating / having a backup key. In that case I would suggest that we have a structure where the = =E2=80=98current=E2=80=99 TA key and URIs are always listed explicitly, = pretty much like the document says now, but there is an optional similar = structure with the intended =E2=80=98activationTime=E2=80=99 = (informational only) for the new key. That way the roll can be prepared in advance. RPs could theoretically = verify independently that things are okay - but I would like to avoid = putting this burden on all RPs. Once things are okay to roll, the TA can = update it=E2=80=99s signed TAL then to make the new key =E2=80=98current=E2= =80=99 and RPs can follow. As I said at the mic HSMs can be used to protect against key theft. But = keys (or card sets) can still be lost. If access to the new key is lost, = then the TA can just choose not complete the roll - remove it, replace = it with a new target key. If access to the current key is lost, then = things get more difficult. Then the new key would have to be allowed to = take over, e.g. automatically once the activation time is past? Explicit revocation of the old key is also possible, but would require = that RPs constantly check these candidate keys. I am afraid this adds a = lot of overhead. Comments and ideas are most welcome! Tim >=20 > -Tom >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Sat Jul 21 13:51:47 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36368130E5F for ; Mon, 16 Jul 2018 11:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGT777nn4W1Z for ; Mon, 16 Jul 2018 11:04:26 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5FF6130DFA for ; Mon, 16 Jul 2018 11:04:26 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id q9-v6so38679671ioj.8 for ; Mon, 16 Jul 2018 11:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S8RXlnjB4YpC+eM5ma85L8zhwhTHgts1fUfsCkY5EhI=; b=DffLBx70cNqjnHr0gg+o3BxZbodlGg1pnLuvPCFmqvB4RjVxVNBJt87G6iUrwEt+E7 Ye1K/neroBS1Gz1CEU7T5NapGozLsNWjNQtU4hqYd5WcrcOGdc5CXVYQJZukoHF7/am7 Hrxfs2n/kVryz8JiX6iVtkN8Vtxo/7dwVN/NqBDFyC7AV679BVW3S38KH2tnBNooglct Nlq13yLmWwcZCNeqaNDq1irZ5fXlsDMVYm6xeDoKCCN9gWsl/qmj6CmIqIPDzjoptRJ5 vivXLY4jDAQgupEBFoji1vK7+Y2vOkawGiY+ajSP6VfGr6ZJDf7tu2TaI86PJ5dfyiVl WdeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S8RXlnjB4YpC+eM5ma85L8zhwhTHgts1fUfsCkY5EhI=; b=CnKbM1i4xU0mrIzx4VipoB6E0syWydgZMH0vjcM1sxhtdzluHOIXENMAiUn8NAcqNL dqUr3wr1yCjY6BpvzXvBW3abjChr9FVN2PvgSFFbysuncaAPSB2EI9PSEp8TyCzVi4Co 0ICzKHvmMyB7Iosd2uPxzBY1nBJW87AjExLzbK6ZsZ1EAPmyg6YsFNxBuAxwuBRK8grl vEYt0HGGat1jLWc0V71Z+HDC5gi/FTEqqjkFkI8t/mCmdVD0f5su+XJqjQLJVlqooxfK RFCPTaPvALRjjgX663h8hPrtIu2LbIb75c5Tr+/p87zLnQritwvfbXiCb93/KsxsU3Vi nnCA== X-Gm-Message-State: AOUpUlFuZCfhWhxpyBzM53TyzYSm+kGhrUwtZ3HBnph8i6TTKQm5PvWQ s8p+qbmt4xDkcshH9SWcHIW3kQ6T/REjMPu+pPgEWYtL X-Google-Smtp-Source: AAOMgpfnw5gdnmod3v2zRJybQt11b8YyZ6B7fsfKWROW5mUzj7SBscC66noGHJFFyQYpJ+CRDtU18+axeDlgr1vgRTQ= X-Received: by 2002:a6b:de05:: with SMTP id v5-v6mr42361024iog.121.1531764265882; Mon, 16 Jul 2018 11:04:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:2150:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 11:03:45 -0700 (PDT) In-Reply-To: References: From: Sharon Goldberg Date: Mon, 16 Jul 2018 14:03:45 -0400 Message-ID: To: sidrops@ietf.org Cc: Yossi Gilad , Job Snijders , "Sriram, Kotikalapudi" , Ben Maddison Content-Type: multipart/alternative; boundary="000000000000f29b17057121a8d6" Archived-At: X-Mailman-Approved-At: Sat, 21 Jul 2018 13:51:46 -0700 Subject: Re: [Sidrops] draft-sidrops-rpkimaxlen-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 18:04:29 -0000 --000000000000f29b17057121a8d6 Content-Type: text/plain; charset="UTF-8" Sorry. The SLIDES are here. http://www.cs.bu.edu/~goldbe/papers/maxleng_ietf102.pdf Sharon On Mon, Jul 16, 2018 at 2:02 PM, Sharon Goldberg wrote: > Dear sidrops, > > Drafts from my presentation today on maxlength best practices are here: > > http://www.cs.bu.edu/~goldbe/papers/anrwWelcome.pdf > > We will be revising the draft over the next month, so please let us know > soon if you have comments: > > https://tools.ietf.org/html/draft-sidrops-rpkimaxlen-00 > > Thanks, > Sharon > > -- > Sharon Goldberg > Computer Science, Boston University > http://www.cs.bu.edu/~goldbe > -- --- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --000000000000f29b17057121a8d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry.=C2=A0 The SLIDES are here.=C2=A0=C2=A0http://www.cs.bu.edu= /~goldbe/papers/maxleng_ietf102.pdf

Sharon
=


<= br>
On Mon, Jul 16, 2018 at 2:02 PM, Sharon Goldb= erg <goldbe@cs.bu.edu> wrote:

Thanks,
Sharon=C2=A0

--
Sha= ron Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe



--
---
Sharon Goldb= erg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe
--000000000000f29b17057121a8d6-- From nobody Tue Jul 24 12:44:02 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D491311D1 for ; Tue, 24 Jul 2018 12:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeSE3o2VjlFU for ; Tue, 24 Jul 2018 12:43:57 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 3DDF91311C4 for ; Tue, 24 Jul 2018 12:43:57 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id t6-v6so5231671wrn.7 for ; Tue, 24 Jul 2018 12:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ylL128fyMmjeNV7+XpB1s5V54lW0OOGRuiqutzZO9FM=; b=fSydLhSAj//mpRcXoxA4MajfgO/VGzfgvGJzv1xuxghWD9kYg5aMjMs7Ib6hWj/1GA qPi5G3X06RZDMpcLjDMREv1n2fZ1L9yGO19phxqIxQ+phO3Ib/Q7uidpyo9hreLo32YJ +hBN5hVkcRm/ctpRQ1fW8cRzMFSoh4RH30KToiyZgeK1bbftnYcxuyJHsDpzvqL7QZfw QqRLpGPPzQ1mYLvlyK+7Q4nUF+jTL0rqmxvxHphblKL+lnIqdyMyRWTcjXTES6Bt+Wpw vBlMUXSqP0IGPktmOXG1Ev75TKIjvqMp67n3unGXZ9YSGkYm0LdkvgB/iUlP6jmi0HzX 2u+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ylL128fyMmjeNV7+XpB1s5V54lW0OOGRuiqutzZO9FM=; b=B+3m0GV5uoqRbFzClKv+Z++lzt0br6DndFr+T2e/cT7cIvHztCS7c0FIjODqk41De2 s4T9jfGgp9x31f0SNSHY+v2Sn2qpxSvflNKmBHMlZvkPrIWnSAyKCWpaAmxsncKVBp5T bppnQ9UHlmCwD0EYfpZa56ciMINQogFX9uuusxDXkUvp/Fz7FXrmP9Aw/ue222MD2D58 Bt9/nJmnFne0BFCMQo2V/VVCYApaXrDgxydPHWjzlOXoFiIlWxfLTy5YS8Rt4Ea+cK7W cq7D/SNBXTP5T2VUlwGaaDlx7O5u59GbWvkkLmxClizSIpP/6wZXiFTv1ObJPCnWcBh+ 9+vA== X-Gm-Message-State: AOUpUlEias5d9KH0qcVssGN/UOfvVD1n5VrjEUbV7QBe+2wr1rFwALkU CXfm21XXJ+2T9XD9aG4MvD8w13xdlpc0pEZ1gmya7w== X-Google-Smtp-Source: AAOMgpdfoCyraazyptjxjDTHjiKf6tqEOjx6+tlZseojTFLPABXwVp/RkN+lUl55PsuYgoo9kxPnsqb1clt8hYYI6Dw= X-Received: by 2002:a5d:574d:: with SMTP id q13-v6mr12108153wrw.24.1532461435256; Tue, 24 Jul 2018 12:43:55 -0700 (PDT) MIME-Version: 1.0 From: Warren Kumari Date: Tue, 24 Jul 2018 15:43:15 -0400 Message-ID: To: draft-ietf-sidrops-ov-clarify@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Sidrops] AD review of draft-ietf-sidrops-ov-clarify X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 19:44:01 -0000 Hi all, Thanks to the authors for a useful and easy to read document -- I think clarification documents are useful, especially if they are informed by operational or implementation experience. I do have a few questions, and a nit which I think will help with readability: 1: Why is this Standards Track? It doesn't update a Std Track document, nor does it seem to have much in the way of protocol. If there is a reason I'm happy to progress it like this, otherwise Informational feels like a better fit. 2: Section 3. Mark ALL Prefixes "Significant Clarification: A router MUST mark all routes in BGP coming from any source (eBGP, iBGP, or redistribution from static), unless..." Presumably the router should also mark routes redistributed from protocols other than static as well? Regardless of the wisdom of redistributing $favorite_igp, I'd assume they should be consistent. 3: The Shepherd Writeup seems to be missing some words: "(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Document Shepherds read the document, reviewed comments and " 4: Nit: Section 1. Introduction "Deployment of RPKI-based BGP origin validation is hampered by, among other things, vendor mis-implementations in two critical areas, which routes are validated and whether policy is applied when not specified by configuration." I think that this would read much cleaner as: "vendor mis-implementations in two critical areas: which routes are validated" (s/,/:/) If editing the draft to address any of the above, this seems like a nit worth addressing. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Jul 24 14:16:53 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5581311C9; Tue, 24 Jul 2018 14:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 k2XofaAXmZ_s; Tue, 24 Jul 2018 14:16:50 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458A8130E28; Tue, 24 Jul 2018 14:16:49 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1fi4fn-00027t-EZ; Tue, 24 Jul 2018 21:16:47 +0000 Date: Tue, 24 Jul 2018 14:16:46 -0700 Message-ID: From: Randy Bush To: Warren Kumari Cc: draft-ietf-sidrops-ov-clarify@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] AD review of draft-ietf-sidrops-ov-clarify X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 21:16:52 -0000 > 1: Why is this Standards Track? It doesn't update a Std Track > document well, it does. 6811. i guess i should figure out how to get that in the header. > 2: Section 3. Mark ALL Prefixes > "Significant Clarification: A router MUST mark all routes in BGP > coming from any source (eBGP, iBGP, or redistribution from static), > unless..." > Presumably the router should also mark routes redistributed from > protocols other than static as well? Regardless of the wisdom of > redistributing $favorite_igp, I'd assume they should be consistent. hmmm. i guess i should include 'connected'. can you think of others? > 3: The Shepherd Writeup seems to be missing some words: ain't my dawg > 4: Nit: > Section 1. Introduction > "Deployment of RPKI-based BGP origin validation is hampered by, among > other things, vendor mis-implementations in two critical areas, which > routes are validated and whether policy is applied when not specified > by configuration." > > I think that this would read much cleaner as: > "vendor mis-implementations in two critical areas: which routes are > validated" (s/,/:/) > If editing the draft to address any of the above, this seems like a > nit worth addressing. i have other nits i have fixed in the next rev. randy From nobody Tue Jul 24 14:31:31 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C7B130F30 for ; Tue, 24 Jul 2018 14:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, UNPARSEABLE_RELAY=0.001, WEIRD_QUOTING=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLVzZXgvMCRU for ; Tue, 24 Jul 2018 14:31:28 -0700 (PDT) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) (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 521C11311E4 for ; Tue, 24 Jul 2018 14:31:27 -0700 (PDT) Received: by mail-ed1-f46.google.com with SMTP id s24-v6so5324299edr.8 for ; Tue, 24 Jul 2018 14:31:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8i28V6uBtQFdYlsmQWQZ3HiXjTpOj5miBwQ3jJHfYvk=; b=gVBCsHDMWGLGU53Rypq78jjOps9+yBs/ochRvNwMFuj1WIXD+XEUKO/vxjQBBvOapR SIwXgH7qV75N9eh2caqdL5UD4g2EtvmOGppWxldIQotdXMW546W02Sk55OTTz0+lBva8 ilNI6xM7TtyghMRy8xQvhL9RbKSfNEh5KbtLRbe/JmtUl864Hb/ZcEDoCmfyqUYJGdds alQvk3y1fAJA7Wzfyz3d6vLK7fSytQ+iNDkp65fJCc1btxpFIoxPUXvDOj80GUhXhKkr Uj+IAD2oXGWefBQT2H98EVs0g/biGPrRcH8wFWdkASi/HwkMf/L2TXWLIl2bZWrEYHfx 4cAw== X-Gm-Message-State: AOUpUlEKu2qOkvk73tCksO9dtzdhci7RecXalI1hnjfwpOUH1gE+J/tU UZiYrbkxPBFmV06KtibameqWoz1v7uQ= X-Google-Smtp-Source: AAOMgpdjJElMOe9E/P8xt/kb7tB4lVJuojlKgBZMnD3OkFZC9+ZtmL4Nh0l2/XOZZIAZaFnTvnkCag== X-Received: by 2002:a50:9622:: with SMTP id y31-v6mr20062566eda.141.1532467885555; Tue, 24 Jul 2018 14:31:25 -0700 (PDT) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id v8-v6sm6167902edr.48.2018.07.24.14.31.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 24 Jul 2018 14:31:24 -0700 (PDT) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 339dcd68; Tue, 24 Jul 2018 21:31:23 +0000 (UTC) Date: Tue, 24 Jul 2018 21:31:23 +0000 From: Job Snijders To: Randy Bush Cc: Warren Kumari , sidrops-chairs@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-ov-clarify@ietf.org Message-ID: <20180724213123.GP37801@vurt.meerval.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Sidrops] AD review of draft-ietf-sidrops-ov-clarify X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 21:31:30 -0000 On Tue, Jul 24, 2018 at 02:16:46PM -0700, Randy Bush wrote: > > 1: Why is this Standards Track? It doesn't update a Std Track > > document > > well, it does. 6811. i guess i should figure out how to get that in > the header. add this in the tag: updates="6811" > > 2: Section 3. Mark ALL Prefixes "Significant Clarification: A > > router MUST mark all routes in BGP coming from any source (eBGP, > > iBGP, or redistribution from static), unless..." > > Presumably the router should also mark routes redistributed from > > protocols other than static as well? Regardless of the wisdom of > > redistributing $favorite_igp, I'd assume they should be consistent. > > hmmm. i guess i should include 'connected'. can you think of others? also "generated", so perhaps: """ A router MUST mark all routes in BGP coming from any source (EBGP, IBGP, IGP, or redistribution from static and generated routes, etc), unless... """" Kind regards, Job From nobody Wed Jul 25 08:58:16 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A7D130E82 for ; Wed, 25 Jul 2018 08:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ef9EC7Psh2F for ; Wed, 25 Jul 2018 08:57:41 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 36528130E83 for ; Wed, 25 Jul 2018 08:57:41 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id q10-v6so7901062wrd.4 for ; Wed, 25 Jul 2018 08:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bFxem9RV6x4U98twG5Ti0pe2AEGu4nGlfL1CXQwVNnI=; b=nJUG+hypXSn6hihkiW/X5KvRKasWNrnlxlx0vc9tOfB7QWYF2eNiF9e1x5x6k9EFHJ lTUr9g5CcPFD4L9gH4DqvovGvBjcHizcSGzK6Fe8+EzK+g1havTh3PEQcHC44VCWpwmK zYHBC0zHXmLWZQpLKitqm5eWoweo3yBRzlCGtbE55eqTjvGpQ3aUga017xzzp/KcSFFB M7A60SQ4EsRC700eXnEbrptNqZysrVuhf7FqL1FFYo6TlKYgEGKGUtcOxiLWSmpXers2 aufGj8bGe/AjI/jy9/CaxPtEXbbcFOEx8d0JoSws3sSk+CxlNZLH3h2wEBzlfk7kR1h5 wnzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bFxem9RV6x4U98twG5Ti0pe2AEGu4nGlfL1CXQwVNnI=; b=eaaw1hH37HeC3Z08GKl+GM/VgZrI0IVSX3tQ+eFcHtUSdADiBJ/UF67r9rLhn0QLxA aJaGyHI9x/GiNHKpo8Z0K8A6QQJawgfvjf++Wan54nLjkD9WYjJWKKfyrXmFM3FH8DNi BboYWVJG2Yo5eVeCLu4HAj/Y0NKTJlQtdadwZeY7T0Ns7hJBDupLbbpDw9QZJNjF0ji9 gUEI6G3beWjDxxfELd6jX3wavK2faP5qbp2CeaN8p4o5rncSZ4MGgw0JyiAbZGAXd4dt o48uEaYPSFfo11iYyEkOfwcR7IaRQi46Z5ibWs9xR4Mu+8eD1bEFOpzVrDIHAMRBLqLj QYnA== X-Gm-Message-State: AOUpUlFZ7mB3T/uVcqQXbk20lST1l/qN7KtuUzIqsDD9kuC0SeLI2kPm A17BssyCGogrBsfsfJaODRbov6LBobLD/+HjBmVkrA== X-Google-Smtp-Source: AAOMgpevcuAHGtr2612TNW6iohbbWrnCL1WjAjfAfpi3qU8GkHxsajSjHug4jP1PrsSw5mfnEH6gHjOr71UaPeIGySg= X-Received: by 2002:adf:ad38:: with SMTP id p53-v6mr15522811wrc.10.1532534259305; Wed, 25 Jul 2018 08:57:39 -0700 (PDT) MIME-Version: 1.0 References: <20180724213123.GP37801@vurt.meerval.net> In-Reply-To: <20180724213123.GP37801@vurt.meerval.net> From: Warren Kumari Date: Wed, 25 Jul 2018 11:57:03 -0400 Message-ID: To: Job Snijders Cc: Randy Bush , sidrops-chairs@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-ov-clarify@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] AD review of draft-ietf-sidrops-ov-clarify X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 15:57:50 -0000 On Tue, Jul 24, 2018 at 5:31 PM Job Snijders wrote: > > On Tue, Jul 24, 2018 at 02:16:46PM -0700, Randy Bush wrote: > > > 1: Why is this Standards Track? It doesn't update a Std Track > > > document > > > > well, it does. 6811. i guess i should figure out how to get that in > > the header. > > add this in the tag: > > updates="6811" > ... and in the Abstract add "This updates RFC6811 by $something and $something_else" -- perhaps "This updates RFC6811 by clarifying that all prefixes should be marked, and that policy must not be applied without operator configuration" > > > 2: Section 3. Mark ALL Prefixes "Significant Clarification: A > > > router MUST mark all routes in BGP coming from any source (eBGP, > > > iBGP, or redistribution from static), unless..." > > > Presumably the router should also mark routes redistributed from > > > protocols other than static as well? Regardless of the wisdom of > > > redistributing $favorite_igp, I'd assume they should be consistent. > > > > hmmm. i guess i should include 'connected'. can you think of others? > > also "generated", so perhaps: > > """ > A router MUST mark all routes in BGP coming from any source (EBGP, > IBGP, IGP, or redistribution from static and generated routes, etc), > unless... > """" > Works for me.... Thank you very much! W > Kind regards, > > Job -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Jul 25 10:29:42 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE25130E75; Wed, 25 Jul 2018 10:29:40 -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, SPF_PASS=-0.001, WEIRD_QUOTING=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 237THRVYl0zE; Wed, 25 Jul 2018 10:29:39 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D0F1124D68; Wed, 25 Jul 2018 10:29:39 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1fiNbT-00089W-U0; Wed, 25 Jul 2018 17:29:36 +0000 Date: Wed, 25 Jul 2018 10:29:35 -0700 Message-ID: From: Randy Bush To: Warren Kumari Cc: Job Snijders , sidrops-chairs@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-ov-clarify@ietf.org In-Reply-To: References: <20180724213123.GP37801@vurt.meerval.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] AD review of draft-ietf-sidrops-ov-clarify X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 17:29:41 -0000 > perhaps "This updates RFC6811 by clarifying that all prefixes should > be marked, and that policy must not be applied without operator > configuration" not the text i had put in, but i can steal it. no ipr i presume? >> """ >> A router MUST mark all routes in BGP coming from any source (EBGP, >> IBGP, IGP, or redistribution from static and generated routes, etc), >> unless... >> """" > > Works for me.... this is what i had put in Significant Clarification: A router MUST mark all routes in BGP coming from any source (eBGP, iBGP, or redistribution from static, connected, etc.), unless specifically configured otherwise by the operator. randy From nobody Wed Jul 25 11:14:31 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203A7130E24 for ; Wed, 25 Jul 2018 11:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv1nMwfHnxqD for ; Wed, 25 Jul 2018 11:14:27 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA449130DD1 for ; Wed, 25 Jul 2018 11:14:26 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id o18-v6so6948100wmc.0 for ; Wed, 25 Jul 2018 11:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o4VpVggb+aC1ehnOmoTtIYp1bvFCrB4aetSAAFltpzo=; b=ykq++S88Rx7Wh0lEaLEwUlKVzdS+dfH/hQEoEXQ9/k6XaoDGRS7fnKaY/7sokVD7L+ xbKAdTDOINYzo7gHzVLD7YKJlCsiCixGZU8UyGI5GMVZKwoQk3REkPnroJHI4PJrSu5U C+bpEr3UDavqKb6kj3WksHetMkYoADr5J7JiMXlzpgcf52Wq5YjOUnMxCz2FF7+AlWQY FiFvNYodMDUzBTV5tT2LYWVUULOg2+/3d6mcZzYYaRv6SuYCikFJsFIVLtcTAOzh9DXY rcs9zw6qtyu8rcSUu0Sts4kbuA77IK32C7Hfqlf3iY3G2+YZoWtDvtLbFB+H2YzqhbdH 81cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o4VpVggb+aC1ehnOmoTtIYp1bvFCrB4aetSAAFltpzo=; b=rn+xyHInV1E72cWcgWvJ/qzaqur6qj+WM6iStGMuCl96NFXHyqLSGCvglcnyEkmHQd ONeNsMAZskL217gztYShZGUxGkt/mzb6Kel6sJ1tVhyFYQlGOjJ8EuMJ0HijUXGD1JkA sxm3v0lD0KCkGzUnL7Shp1slbCY2BUuFRry9doUK2mOrZFFEiQHYpOVPvg+XgVIVJVYK EeJqq4gFPrjg/7iKYeag3+8h49znGtbdi1nxE4XPjsQQJANe4whOpQ5Pgq3ydgc3r1Ok VS40rbIMaBJVi9v++QQGJ9+Btb8zRHLwTlT1fE/71l5MIirFE2bHR2lucyn2ZQlMkrt3 IgqA== X-Gm-Message-State: AOUpUlF3wF8e7EUKMx/w/A/sGG6D3KiW2i3uoxihuuyNyrQmjE+QP3YE rlnMZdcQmNW+CbFXXNNX0ndClbjSxJfgnUPMn8NJZQ== X-Google-Smtp-Source: AAOMgpegR0zchU5xedkvpIuEq7hi5jAbnAas5zWG5GpQMXiJTVXQBAkVZDw+z3rcuUXbgWMgi6lU5pjFj9CdsivzsF0= X-Received: by 2002:a1c:5b09:: with SMTP id p9-v6mr5908836wmb.0.1532542464647; Wed, 25 Jul 2018 11:14:24 -0700 (PDT) MIME-Version: 1.0 References: <20180724213123.GP37801@vurt.meerval.net> In-Reply-To: From: Warren Kumari Date: Wed, 25 Jul 2018 14:13:48 -0400 Message-ID: To: Randy Bush Cc: Job Snijders , sidrops-chairs@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-ov-clarify@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] AD review of draft-ietf-sidrops-ov-clarify X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 18:14:29 -0000 On Wed, Jul 25, 2018 at 1:29 PM Randy Bush wrote: > > > perhaps "This updates RFC6811 by clarifying that all prefixes should > > be marked, and that policy must not be applied without operator > > configuration" > > not the text i had put in, but i can steal it. no ipr i presume? Of course (and no IPR :-)) > > >> """ > >> A router MUST mark all routes in BGP coming from any source (EBGP, > >> IBGP, IGP, or redistribution from static and generated routes, etc), > >> unless... > >> """" > > > > Works for me.... > > this is what i had put in > > Significant Clarification: A router MUST mark all routes in BGP > coming from any source (eBGP, iBGP, or redistribution from static, > connected, etc.), unless specifically configured otherwise by the > operator. > WFM! W > randy -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Jul 25 11:28:22 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCF2130ED8; Wed, 25 Jul 2018 11:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 othV6NToDBtL; Wed, 25 Jul 2018 11:28:18 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7781C130EBB; Wed, 25 Jul 2018 11:28:18 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1fiOWE-0000aq-RE; Wed, 25 Jul 2018 18:28:14 +0000 Date: Wed, 25 Jul 2018 11:28:14 -0700 Message-ID: From: Randy Bush To: Warren Kumari Cc: Job Snijders , sidrops-chairs@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-ov-clarify@ietf.org In-Reply-To: References: <20180724213123.GP37801@vurt.meerval.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] AD review of draft-ietf-sidrops-ov-clarify X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 18:28:20 -0000 tell me when you want the new version posted. randy From nobody Wed Jul 25 11:41:19 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15616130EE4 for ; Wed, 25 Jul 2018 11:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96KezERnNmXn for ; Wed, 25 Jul 2018 11:41:15 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 64652130EDD for ; Wed, 25 Jul 2018 11:41:15 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id y9-v6so6173113wma.5 for ; Wed, 25 Jul 2018 11:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G93kA2hp7E/TNzJfPAyO7Cog17wZrph1JJSd4LY7q+k=; b=uhgoZ++XEb0abSyhaH565rYcVeCgg5YtypMvAGwIyq5SwYKGMOu04J6h619X/Iwg8d XZIBPv5CKoguMyM8TS6c6VKjGq26ughUq/6crz0uMOUipXCq0KJcV7o60LOABxKOKPA7 AnD0IMdZXFzyrPM9nA3NWMK85Pwo3bZjqCdggj9vgbDwHF6EGsQEqVKkIELbw0sn9Vym 5bplnBiIUkYZrG6nudsnt0lbnee2iIfoN+lhRAOPV8syS8xbyDwGPCEBTZ4xb6JISLJM kqX1ZcTBqh6KssvVELgJKVVZ+rCUuwiKBQQ1HY52jf4TZI06RFEwQxeApHcZ14GBV6md wuMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G93kA2hp7E/TNzJfPAyO7Cog17wZrph1JJSd4LY7q+k=; b=mqioPKZ4poiaPfS6xyQPPbvBx0Asi3iqM0WrtCAhKBM0bS1Ba/HetFPsJ8LSb4e1bE ueg3LsUOriGo0JR2Bvx/4JjpO8uW2OCNf1c2GuIo52WHfPAFZLt4JY6zxihky8/+gLdV PKsh4qvd2k6Oek+bpmGchF1blofSSdmQn/C4y9DGpycZBUEM38P8SvxPoorNjHxcujSL L2/HLd6tVJAWf/kR/qAKNbQEVluon/9gwBcOVa8mobdzEolvvKhW0RuQXUggWFoiLZ2r b/fASk2kvEzHxh332mPjdfkmX/kjKMmSXu9tx4zFPCz1rvZnq9LtBDA3pC794Bi7xU/i g9ww== X-Gm-Message-State: AOUpUlEsbsKFU0kBjE/vupLmWCa7hOBvTOeaqO1AXddXgQZOmRy6Qrb3 Suxi0h/ndMXdvaLs+/hipYEEHYHiH3txZAJPZ2dPCw== X-Google-Smtp-Source: AAOMgpeZUHomCy+Opmx4Mub+oDDmcIU5dIU8z5v7jFKFtFpNh0dTKPx3J1MU6tXyhWwHup/774hTFnWU+DjhX5A8eRA= X-Received: by 2002:a1c:8b0d:: with SMTP id n13-v6mr5026162wmd.46.1532544073534; Wed, 25 Jul 2018 11:41:13 -0700 (PDT) MIME-Version: 1.0 References: <20180724213123.GP37801@vurt.meerval.net> In-Reply-To: From: Warren Kumari Date: Wed, 25 Jul 2018 14:40:37 -0400 Message-ID: To: Randy Bush Cc: Job Snijders , sidrops-chairs@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-ov-clarify@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] AD review of draft-ietf-sidrops-ov-clarify X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 18:41:18 -0000 On Wed, Jul 25, 2018 at 2:28 PM Randy Bush wrote: > > tell me when you want the new version posted. I'm fine whenever, so up to Job et al. W > > randy -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Jul 25 14:40:48 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8271277C8; Wed, 25 Jul 2018 14:40:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <153255484272.15410.5336923576287868026@ietfa.amsl.com> Date: Wed, 25 Jul 2018 14:40:42 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-ov-clarify-03.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 21:40:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : Origin Validation Clarifications Author : Randy Bush Filename : draft-ietf-sidrops-ov-clarify-03.txt Pages : 4 Date : 2018-07-25 Abstract: Deployment of RPKI-based BGP origin validation is hampered by, among other things, vendor mis-implementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration. This document is meant to clarify possible misunderstandings causing those mis-implementations; and thus updates RFC6811 by clarifying that all prefixes should be marked, and that policy must not be applied without operator configuration" The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-clarify/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-ov-clarify-03 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-ov-clarify-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-ov-clarify-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 25 15:17:47 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 137DC130F2D; Wed, 25 Jul 2018 15:17:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-sidrops-ov-clarify@ietf.org, keyur@arrcus.com, sidrops@ietf.org, Keyur Patel , sidrops-chairs@ietf.org, warren@kumari.net Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <153255705607.15385.11338294621699870268.idtracker@ietfa.amsl.com> Date: Wed, 25 Jul 2018 15:17:36 -0700 Archived-At: Subject: [Sidrops] Last Call: (Origin Validation Clarifications) to Internet Standard X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 22:17:41 -0000 The IESG has received a request from the SIDR Operations WG (sidrops) to consider the following document: - 'Origin Validation Clarifications' as Internet Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-08-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Deployment of RPKI-based BGP origin validation is hampered by, among other things, vendor mis-implementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration. This document is meant to clarify possible misunderstandings causing those mis-implementations; and thus updates RFC6811 by clarifying that all prefixes should be marked, and that policy must not be applied without operator configuration" The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-clarify/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-clarify/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc6482: A Profile for Route Origin Authorizations (ROAs) (Proposed Standard - IETF stream) rfc8097: BGP Prefix Origin Validation State Extended Community (Proposed Standard - IETF stream) rfc6811: BGP Prefix Origin Validation (Proposed Standard - IETF stream) From nobody Wed Jul 25 23:03:12 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEA7130EDE for ; Wed, 25 Jul 2018 23:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2quWDtGj7bQC for ; Wed, 25 Jul 2018 23:03:06 -0700 (PDT) Received: from mail-vk0-x243.google.com (mail-vk0-x243.google.com [IPv6:2607:f8b0:400c:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB14130DC2 for ; Wed, 25 Jul 2018 23:03:06 -0700 (PDT) Received: by mail-vk0-x243.google.com with SMTP id s17-v6so241396vke.10 for ; Wed, 25 Jul 2018 23:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YH3liCzj2zlrnMYxbabOovp/c2EpIta8kTUAL76bkDk=; b=mda50K9qddex+am3zk8Z75cw30hq7BSEjHenxT+/MTM6vOb9z5zHEL0fLofBFCdSKx dnujwpMSOagIkl5vyTRWefT/E9VOHQ3IcLgVwnnhpGe8THgSg3iuSxoNo2g6zJkAkLmc XaISB09z9a+7j72VvuBzxY+6aZ8P9ERyBQ3Rbq7Wet15AkGAZnfK5lc33TL5RNTvRClc kSfJt91e4hJl80dMs+jq6nGDrf39YmWR+UzA2OpCfJjw2ClG4eHZJS93XzeJ7twkeQjR PHOnlyi/qvpy359BLs4n9Rwy1WGNFLj8xyGAjrGP3GG8TtpHqs59QhwswylRoHh69gnX lmyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YH3liCzj2zlrnMYxbabOovp/c2EpIta8kTUAL76bkDk=; b=apNY2QqKINFH8u61WDPHOZTBeGIqKryaaasAv50bn63fbE1BedYyjWyPeNqycPc2yJ A8NjmduEGEge3Tx1hteLMzhzopUsDvI7mEHInOaDyd2wnoCnw8K3Se5dW0S1sUdZcn38 RZhxsEZhdizmbK95BHEplnFBP4mBDSOG8Ehnx6qhOBaw8QGLJCVcd9MepvEUs7zNtBWG mcg0v8pkMGjIQerLk8mI6zYr7KwKnB/K7q72HRcuiy1fWHV5FWRWsNyVuLDR3lnMVaGI 1/NCzySSe19XlskUBT+aOT+r9NCzjTbOMDaMJYkZ13YhHdab5w58ZWwjwqk66/VPpXDd kYkA== X-Gm-Message-State: AOUpUlGt4vqJ3JGHl+9bqEhZCVbHVqtbgs2dMsykhmcWLuqs02S+HbBd LsYG7sNZdajdb0ztIQDqiUyv9naWS2LRPNRrci3bMA== X-Google-Smtp-Source: AAOMgpdV6ATwzdJEzimFIlAv7oylAJnaVZIE0ZoJtp+6JaSLm01BJUOcHEDXQD4sWg67pV+33jM1oKClDrkOxgwMQ+U= X-Received: by 2002:a1f:b449:: with SMTP id d70-v6mr319736vkf.160.1532584985373; Wed, 25 Jul 2018 23:03:05 -0700 (PDT) MIME-Version: 1.0 References: <152846464123.15396.14579027912013078144@ietfa.amsl.com> <20180717165827.GA14191@tomh-laptop> In-Reply-To: From: Christopher Morrow Date: Thu, 26 Jul 2018 02:02:54 -0400 Message-ID: To: tim@nlnetlabs.nl Cc: tomh@apnic.net, sidrops@ietf.org Content-Type: multipart/alternative; boundary="000000000000a433310571e0bf5e" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 06:03:10 -0000 --000000000000a433310571e0bf5e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It occurs to me that ... we should have closed out the wglc for this document prior to IETF week. If this set of comments/edits is all done then we can send a new version of the draft and forward things up the mgmt chain. thoughts? -chris On Tue, Jul 17, 2018 at 5:52 PM Tim Bruijnzeels wrote: > Hi Tom, > > Thanks for testing and the feedback. Comments below. > > > On 17 Jul 2018, at 12:58, Tom Harrison wrote: > > > > On Fri, Jun 08, 2018 at 06:30:41AM -0700, internet-drafts@ietf.org > wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >> This draft is a work item of the SIDR Operations WG of the IETF. > >> > >> Title : RPKI signed object for TAL > >> Authors : Tim Bruijnzeels > >> Carlos Martinez > >> Filename : draft-ietf-sidrops-signed-tal-01.txt > >> Pages : 12 > >> Date : 2018-06-08 > > > > I've updated our proof-of-concept to match the new draft. Some > > questions and minor suggestions: > > > > In section 3, there is: > > > > The ASN.1 syntax for the Signed TAL eContent defined in > > Section 3.2. (This is the payload that specifies the AS being > > authorized to originate routes as well as the prefixes to which > > the AS may originate routes.) > > > > The text in parentheses looks to be a cut-and-paste from the ROA > > profile document (RFC 6482). > > Fixed in my edit buffer. > > > In section 4, there is "[t]his EE certificate MUST have a 'notAfter' > > time that reflects the intended time that this Signed TAL will be > > published", which on its face implies that the 'notAfter' should be > > set to the time when the object is first published. Changing it to > > "reflects the intended time [or duration] for which this signed TAL > > will be published" should make things clearer. > > Yes, you are right. The intention was duration. Fixed in the edit buffer. > > > > > The SubjectPublicKeyInfo in the TAL structure has the type IA5String. > > Is there some reason not to use the 'raw' SubjectPublicKeyInfo type > > from RFC 5280? > > This is an oversight. It should just be the raw DER structure. > > > Since activationTime is not needed for an in-protocol reason at the > > moment, it would be good to add a note to the draft that it's there to > > prompt discussion/feedback about future dating. > > > > On future dating more generally, I think it's a good idea, since it > > allows for in-band signalling about the rollover and would (hopefully) > > encourage a wider set of users to test the new tree before it becomes > > the 'official' tree. > > The current draft assumes that the TA tests things before publishing the > new signed TAL object, and then I think it would be okay for RPs to follo= w > this new TAL as soon as it=E2=80=99s available. > > But.. there may be good reasons for future dating / having a backup key. > > In that case I would suggest that we have a structure where the =E2=80=98= current=E2=80=99 > TA key and URIs are always listed explicitly, pretty much like the docume= nt > says now, but there is an optional similar structure with the intended > =E2=80=98activationTime=E2=80=99 (informational only) for the new key. > > That way the roll can be prepared in advance. RPs could theoretically > verify independently that things are okay - but I would like to avoid > putting this burden on all RPs. Once things are okay to roll, the TA can > update it=E2=80=99s signed TAL then to make the new key =E2=80=98current= =E2=80=99 and RPs can > follow. > > As I said at the mic HSMs can be used to protect against key theft. But > keys (or card sets) can still be lost. If access to the new key is lost, > then the TA can just choose not complete the roll - remove it, replace it > with a new target key. If access to the current key is lost, then things > get more difficult. Then the new key would have to be allowed to take ove= r, > e.g. automatically once the activation time is past? > > Explicit revocation of the old key is also possible, but would require > that RPs constantly check these candidate keys. I am afraid this adds a l= ot > of overhead. > > Comments and ideas are most welcome! > > Tim > > > > > > > > > > -Tom > > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --000000000000a433310571e0bf5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It occurs to me that ... we should have closed out the wgl= c for this document prior to IETF week.
If this set of comments/edits i= s all done then we can send a new version of the draft and forward things u= p the mgmt chain.

thoughts?

-chris

On Tue= , Jul 17, 2018 at 5:52 PM Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
Hi Tom,

Thanks for testing and the feedback. Comments below.

> On 17 Jul 2018, at 12:58, Tom Harrison <tomh@apnic.net> wrote:
>
> On Fri, Jun 08, 2018 at 06:30:41AM -0700, internet-drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts= directories.
>> This draft is a work item of the SIDR Operations WG of the IETF. >>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: RPKI signed object for TAL
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Tim Bruijnzeels
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Carlos Martinez
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : d= raft-ietf-sidrops-signed-tal-01.txt
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: 12
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : 2018-06-08
>
> I've updated our proof-of-concept to match the new draft.=C2=A0 So= me
> questions and minor suggestions:
>
> In section 3, there is:
>
>=C2=A0 =C2=A0The ASN.1 syntax for the Signed TAL eContent defined in >=C2=A0 =C2=A0Section 3.2.=C2=A0 (This is the payload that specifies the= AS being
>=C2=A0 =C2=A0authorized to originate routes as well as the prefixes to = which
>=C2=A0 =C2=A0the AS may originate routes.)
>
> The text in parentheses looks to be a cut-and-paste from the ROA
> profile document (RFC 6482).

Fixed in my edit buffer.

> In section 4, there is "[t]his EE certificate MUST have a 'no= tAfter'
> time that reflects the intended time that this Signed TAL will be
> published", which on its face implies that the 'notAfter'= should be
> set to the time when the object is first published.=C2=A0 Changing it = to
> "reflects the intended time [or duration] for which this signed T= AL
> will be published" should make things clearer.

Yes, you are right. The intention was duration. Fixed in the edit buffer.
>
> The SubjectPublicKeyInfo in the TAL structure has the type IA5String.<= br> > Is there some reason not to use the 'raw' SubjectPublicKeyInfo= type
> from RFC 5280?

This is an oversight. It should just be the raw DER structure.

> Since activationTime is not needed for an in-protocol reason at the > moment, it would be good to add a note to the draft that it's ther= e to
> prompt discussion/feedback about future dating.
>
> On future dating more generally, I think it's a good idea, since i= t
> allows for in-band signalling about the rollover and would (hopefully)=
> encourage a wider set of users to test the new tree before it becomes<= br> > the 'official' tree.

The current draft assumes that the TA tests things before publishing the ne= w signed TAL object, and then I think it would be okay for RPs to follow th= is new TAL as soon as it=E2=80=99s available.

But.. there may be good reasons for future dating / having a backup key.
In that case I would suggest that we have a structure where the =E2=80=98cu= rrent=E2=80=99 TA key and URIs are always listed explicitly, pretty much li= ke the document says now, but there is an optional similar structure with t= he intended =E2=80=98activationTime=E2=80=99 (informational only) for the n= ew key.

That way the roll can be prepared in advance. RPs could theoretically verif= y independently that things are okay - but I would like to avoid putting th= is burden on all RPs. Once things are okay to roll, the TA can update it=E2= =80=99s signed TAL then to make the new key =E2=80=98current=E2=80=99 and R= Ps can follow.

As I said at the mic HSMs can be used to protect against key theft. But key= s (or card sets) can still be lost. If access to the new key is lost, then = the TA can just choose not complete the roll - remove it, replace it with a= new target key. If access to the current key is lost, then things get more= difficult. Then the new key would have to be allowed to take over, e.g. au= tomatically once the activation time is past?

Explicit revocation of the old key is also possible, but would require that= RPs constantly check these candidate keys. I am afraid this adds a lot of = overhead.

Comments and ideas are most welcome!

Tim






>
> -Tom
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org=
> https://www.ietf.org/mailman/listinfo/sidrops<= br>
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--000000000000a433310571e0bf5e-- From nobody Thu Jul 26 00:34:26 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47DB130DF2 for ; Thu, 26 Jul 2018 00:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jViUgLRLXt-j for ; Thu, 26 Jul 2018 00:34:21 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 D15B2130DE3 for ; Thu, 26 Jul 2018 00:34:20 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id b10-v6so729364eds.4 for ; Thu, 26 Jul 2018 00:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nlnetlabs-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=L+L7PTgaEkMh6M1qx+Wfr98hmnLGiqb8fG1HmV9QbJU=; b=o/rX9m3cU2o9Tlgkx16Oa8yjvUQvrZ53p6IIl9L8BLcRGZ9GZG1jyqaX7VQhCfhDMM gJTwU034I/0/eJ7FMXwssuUL3Sxtr1Jn4GG3mtCONbn18A13BBX36ewa6lsg96MBbzTc EWo2gMAQ4KFEpylmTOgw6A/3ulU0uaA3zEGNSCAVecjWmoMV7pDh4W1HsRn8haymNmjY ktlGpDuHnLaUYddccKr3DFEipzOUJQ+f1yhXaE+Q8t6ek/K5mMBMaizDAqgZmVnYsnTp m6OiciB3PL+8xZPxTAn7tDwdlBVSAzRzw5e995oFtlDEb5hwwEfzSpP/JT1ZL/CDDoa9 9bYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=L+L7PTgaEkMh6M1qx+Wfr98hmnLGiqb8fG1HmV9QbJU=; b=AS90HlwL+113eliPF7nsR/8Xovk4F2qWoHHTJnMdHcQlZhfrZh/3r1MuutV40jEsWs A4r5MfrzB7vPqfe5HqTGcwQ7YgA9p/75QbYkyfGpZkFIVcgLn7orp5HhjfRMwJq3Xdk4 CRa+SyzfNQ+wVkBy5ucBRG1KNcmJmtL+YeSy9n83R3GygTK8cRM6Q3cZGKKAOFuW020A vHa4x00v6c5zkoTPVJuZGrXfgqkKpJVj6eASE2JkUpmwLCxle5FHj+Bw9aQ8TfX/xaLH yb6E+UIUZxdFDMTLgTkop6SI0xzSZGfmwysVJi1M11WNbtXsSMRZ9VDwW4g386Tkd0Ex 6tkQ== X-Gm-Message-State: AOUpUlHI3KbihJH9sYOPlmNGo7ktwNHdUFH0eeb6xST6VBu4VR88Cg1h O1ZXEOWc4xBx9LNMaVat5dRmug== X-Google-Smtp-Source: AAOMgpcFU30745WYUSExoHn53pNaDez2jQFYhs10gDv8zoy61HZi9OetXnFoE1AKirFrWSsiMqAzBw== X-Received: by 2002:a50:cf81:: with SMTP id h1-v6mr1501749edk.35.1532590459398; Thu, 26 Jul 2018 00:34:19 -0700 (PDT) Received: from ?IPv6:2a04:b900::1:2168:fbd9:cb78:4939? ([2a04:b900:0:1:2168:fbd9:cb78:4939]) by smtp.gmail.com with ESMTPSA id p40-v6sm697120eda.53.2018.07.26.00.34.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jul 2018 00:34:18 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_78279FDE-5A80-42F4-A359-262F580A63F4" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Tim Bruijnzeels In-Reply-To: Date: Thu, 26 Jul 2018 09:34:16 +0200 Cc: tomh@apnic.net, sidrops@ietf.org Message-Id: <2D133A87-A328-4758-9452-929370F8F54E@nlnetlabs.nl> References: <152846464123.15396.14579027912013078144@ietfa.amsl.com> <20180717165827.GA14191@tomh-laptop> To: Christopher Morrow X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 07:34:24 -0000 --Apple-Mail=_78279FDE-5A80-42F4-A359-262F580A63F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Chris, The last call was on 'draft-ietf-sidrops-https-tal-03=E2=80=99, see: https://www.ietf.org/mail-archive/web/sidrops/current/msg00440.html = There was a nit and a suggestion for clarification by Job Snijders that = I would be happy to include in an update. The signed-tal document needs more work. I received useful feedback on = list from Tom Harrison and Di Ma, and a good in-depth discussion with = Rob Austein. I plan to upload a new version for further discussion in = the coming weeks. Tim > On 26 Jul 2018, at 08:02, Christopher Morrow = wrote: >=20 > It occurs to me that ... we should have closed out the wglc for this = document prior to IETF week. > If this set of comments/edits is all done then we can send a new = version of the draft and forward things up the mgmt chain. >=20 > thoughts? >=20 > -chris >=20 > On Tue, Jul 17, 2018 at 5:52 PM Tim Bruijnzeels > wrote: > Hi Tom, >=20 > Thanks for testing and the feedback. Comments below. >=20 > > On 17 Jul 2018, at 12:58, Tom Harrison > wrote: > >=20 > > On Fri, Jun 08, 2018 at 06:30:41AM -0700, internet-drafts@ietf.org = wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. > >> This draft is a work item of the SIDR Operations WG of the IETF. > >>=20 > >> Title : RPKI signed object for TAL > >> Authors : Tim Bruijnzeels > >> Carlos Martinez > >> Filename : draft-ietf-sidrops-signed-tal-01.txt > >> Pages : 12 > >> Date : 2018-06-08 > >=20 > > I've updated our proof-of-concept to match the new draft. Some > > questions and minor suggestions: > >=20 > > In section 3, there is: > >=20 > > The ASN.1 syntax for the Signed TAL eContent defined in > > Section 3.2. (This is the payload that specifies the AS being > > authorized to originate routes as well as the prefixes to which > > the AS may originate routes.) > >=20 > > The text in parentheses looks to be a cut-and-paste from the ROA > > profile document (RFC 6482). >=20 > Fixed in my edit buffer. >=20 > > In section 4, there is "[t]his EE certificate MUST have a 'notAfter' > > time that reflects the intended time that this Signed TAL will be > > published", which on its face implies that the 'notAfter' should be > > set to the time when the object is first published. Changing it to > > "reflects the intended time [or duration] for which this signed TAL > > will be published" should make things clearer. >=20 > Yes, you are right. The intention was duration. Fixed in the edit = buffer. >=20 > >=20 > > The SubjectPublicKeyInfo in the TAL structure has the type = IA5String. > > Is there some reason not to use the 'raw' SubjectPublicKeyInfo type > > from RFC 5280? >=20 > This is an oversight. It should just be the raw DER structure. >=20 > > Since activationTime is not needed for an in-protocol reason at the > > moment, it would be good to add a note to the draft that it's there = to > > prompt discussion/feedback about future dating. > >=20 > > On future dating more generally, I think it's a good idea, since it > > allows for in-band signalling about the rollover and would = (hopefully) > > encourage a wider set of users to test the new tree before it = becomes > > the 'official' tree. >=20 > The current draft assumes that the TA tests things before publishing = the new signed TAL object, and then I think it would be okay for RPs to = follow this new TAL as soon as it=E2=80=99s available. >=20 > But.. there may be good reasons for future dating / having a backup = key. >=20 > In that case I would suggest that we have a structure where the = =E2=80=98current=E2=80=99 TA key and URIs are always listed explicitly, = pretty much like the document says now, but there is an optional similar = structure with the intended =E2=80=98activationTime=E2=80=99 = (informational only) for the new key. >=20 > That way the roll can be prepared in advance. RPs could theoretically = verify independently that things are okay - but I would like to avoid = putting this burden on all RPs. Once things are okay to roll, the TA can = update it=E2=80=99s signed TAL then to make the new key =E2=80=98current=E2= =80=99 and RPs can follow. >=20 > As I said at the mic HSMs can be used to protect against key theft. = But keys (or card sets) can still be lost. If access to the new key is = lost, then the TA can just choose not complete the roll - remove it, = replace it with a new target key. If access to the current key is lost, = then things get more difficult. Then the new key would have to be = allowed to take over, e.g. automatically once the activation time is = past? >=20 > Explicit revocation of the old key is also possible, but would require = that RPs constantly check these candidate keys. I am afraid this adds a = lot of overhead. >=20 > Comments and ideas are most welcome! >=20 > Tim >=20 >=20 >=20 >=20 >=20 >=20 > >=20 > > -Tom > >=20 > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops = >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops = --Apple-Mail=_78279FDE-5A80-42F4-A359-262F580A63F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Chris,

The last call = was on 'draft-ietf-sidrops-https-tal-03=E2=80=99, see:
https://www.ietf.org/mail-archive/web/sidrops/current/msg00440.= html

There = was a nit and a suggestion for clarification by Job Snijders that I = would be happy to include in an update.

The signed-tal document needs more = work. I received useful feedback on list from Tom Harrison and Di Ma, = and a good in-depth discussion with Rob Austein. I plan to upload a new = version for further discussion in the coming weeks.

Tim




On 26 Jul 2018, at 08:02, Christopher Morrow = <christopher.morrow@gmail.com> wrote:

It occurs to me that ... we should have closed out the wglc = for this document prior to IETF week.
If this set of = comments/edits is all done then we can send a new version of the draft = and forward things up the mgmt chain.

thoughts?

-chris

On Tue, Jul 17, 2018 = at 5:52 PM Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
Hi Tom,

Thanks for testing and the feedback. Comments below.

> On 17 Jul 2018, at 12:58, Tom Harrison <tomh@apnic.net> wrote:
>
> On Fri, Jun 08, 2018 at 06:30:41AM -0700, internet-drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line = Internet-Drafts directories.
>> This draft is a work item of the SIDR Operations WG of the = IETF.
>>
>>        Title        =    : RPKI signed object for TAL
>>        Authors        =  : Tim Bruijnzeels
>>                  =         Carlos Martinez
>>        Filename        = : draft-ietf-sidrops-signed-tal-01.txt
>>        Pages        =    : 12
>>        Date        =     : 2018-06-08
>
> I've updated our proof-of-concept to match the new draft.  = Some
> questions and minor suggestions:
>
> In section 3, there is:
>
>   The ASN.1 syntax for the Signed TAL eContent defined = in
>   Section 3.2.  (This is the payload that specifies = the AS being
>   authorized to originate routes as well as the prefixes = to which
>   the AS may originate routes.)
>
> The text in parentheses looks to be a cut-and-paste from the ROA
> profile document (RFC 6482).

Fixed in my edit buffer.

> In section 4, there is "[t]his EE certificate MUST have a = 'notAfter'
> time that reflects the intended time that this Signed TAL will = be
> published", which on its face implies that the 'notAfter' should = be
> set to the time when the object is first published.  Changing = it to
> "reflects the intended time [or duration] for which this signed = TAL
> will be published" should make things clearer.

Yes, you are right. The intention was duration. Fixed in the edit = buffer.

>
> The SubjectPublicKeyInfo in the TAL structure has the type = IA5String.
> Is there some reason not to use the 'raw' SubjectPublicKeyInfo = type
> from RFC 5280?

This is an oversight. It should just be the raw DER structure.

> Since activationTime is not needed for an in-protocol reason at = the
> moment, it would be good to add a note to the draft that it's there = to
> prompt discussion/feedback about future dating.
>
> On future dating more generally, I think it's a good idea, since = it
> allows for in-band signalling about the rollover and would = (hopefully)
> encourage a wider set of users to test the new tree before it = becomes
> the 'official' tree.

The current draft assumes that the TA tests things before publishing the = new signed TAL object, and then I think it would be okay for RPs to = follow this new TAL as soon as it=E2=80=99s available.

But.. there may be good reasons for future dating / having a backup = key.

In that case I would suggest that we have a structure where the = =E2=80=98current=E2=80=99 TA key and URIs are always listed explicitly, = pretty much like the document says now, but there is an optional similar = structure with the intended =E2=80=98activationTime=E2=80=99 = (informational only) for the new key.

That way the roll can be prepared in advance. RPs could theoretically = verify independently that things are okay - but I would like to avoid = putting this burden on all RPs. Once things are okay to roll, the TA can = update it=E2=80=99s signed TAL then to make the new key =E2=80=98current=E2= =80=99 and RPs can follow.

As I said at the mic HSMs can be used to protect against key theft. But = keys (or card sets) can still be lost. If access to the new key is lost, = then the TA can just choose not complete the roll - remove it, replace = it with a new target key. If access to the current key is lost, then = things get more difficult. Then the new key would have to be allowed to = take over, e.g. automatically once the activation time is past?

Explicit revocation of the old key is also possible, but would require = that RPs constantly check these candidate keys. I am afraid this adds a = lot of overhead.

Comments and ideas are most welcome!

Tim






>
> -Tom
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

= --Apple-Mail=_78279FDE-5A80-42F4-A359-262F580A63F4-- From nobody Thu Jul 26 07:02:57 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC22B131001 for ; Thu, 26 Jul 2018 07:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoVqFcBTweP9 for ; Thu, 26 Jul 2018 07:02:47 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 D897E130E70 for ; Thu, 26 Jul 2018 07:02:46 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id i4-v6so1144057uak.0 for ; Thu, 26 Jul 2018 07:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I1d3gpupeYx4pidVGcS0trVOLVj6EGBTl61B8rAWg5g=; b=kq42/yoOalCKQP1Xek0DJc+I0/eW/cmYCbjexOA0jLVKa+nnNoFbgznREED1uMOcTQ EWaxvOYN62RTwQzopA9+9WhJDTitD4Yqvu5gFg/PixZ7HMSNTVApOU1QbqRcVfXjUrrd JaFvb7uWcyifMm8BmzGwIsfyP1GjrPGZjWm4l0LCl+GHlcSPSZt44rMHJVUPTkyGh6+J t6+4Wgo6L1sir2J5rEDH8/fyDfVh9wvOfB4RmauHEy8OTT8TFjlz40JfzfVF+9dxPqC5 92sMZorrHgt1h6IuDS8QIzSUK/IrD8p6dTDKlhJNn+P2NrVTbLV5FXZqlgR2BSuV02/y UsHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I1d3gpupeYx4pidVGcS0trVOLVj6EGBTl61B8rAWg5g=; b=A2yNK2J8XguUlNsbRU+ShbnriB4sfYo4jeDuMG/hSkq+ChxZfc3vnMykJFhzl4lMJK E7chgUCckoP0qJWsVBgTC6Ti185zxDrk0qvjHxKCa/Xf/N5/NbxeiWfPcLBkoUWZPJte fNFs/MnjIrsTSscPrGx8lzjyX2xfqnpHht9tJHGB2LDT6R69+/KTYbSJ9UFAQimSbrEJ hEFEkKMC3EpI/7eus2xyW3eTfFOMUvOcdqSlTnrzg4unkSaFNX3RXFjXW958jwTKd5vY 48NslNUnmcoUqewYSXA/JORugEZthZY9eqvFPFqFqsfkZI4T0V69xvrTuus76sqort1E gilw== X-Gm-Message-State: AOUpUlE+EM96PrGsKNMU980ch3XJMl1IzJCjD8Y71qL6YvcAuQVGeeRQ zbo+oJ28tkCVyChvgtq5gClKHkyHqr3SKNuvkuLyPw== X-Google-Smtp-Source: AAOMgpeaJR7XKiB96J6fAox00m53XUwNEmc+4kIEUpP2kF1cFdMz1IwMjUgZxGXhUr0cxQbe9Yb0OX8x6F+XcE3za2A= X-Received: by 2002:ab0:74d1:: with SMTP id f17-v6mr1410468uaq.105.1532613765695; Thu, 26 Jul 2018 07:02:45 -0700 (PDT) MIME-Version: 1.0 References: <152846464123.15396.14579027912013078144@ietfa.amsl.com> <20180717165827.GA14191@tomh-laptop> <2D133A87-A328-4758-9452-929370F8F54E@nlnetlabs.nl> In-Reply-To: <2D133A87-A328-4758-9452-929370F8F54E@nlnetlabs.nl> From: Christopher Morrow Date: Thu, 26 Jul 2018 10:02:34 -0400 Message-ID: To: tim@nlnetlabs.nl Cc: tomh@apnic.net, sidrops@ietf.org Content-Type: multipart/alternative; boundary="0000000000001510bf0571e773ac" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 14:02:56 -0000 --0000000000001510bf0571e773ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 26, 2018 at 3:34 AM Tim Bruijnzeels wrote: > Hi Chris, > > The last call was on 'draft-ietf-sidrops-https-tal-03=E2=80=99, see: > https://www.ietf.org/mail-archive/web/sidrops/current/msg00440.html > > There was a nit and a suggestion for clarification by Job Snijders that I > would be happy to include in an update. > > The signed-tal document needs more work. I received useful feedback on > list from Tom Harrison and Di Ma, and a good in-depth discussion with Rob > Austein. I plan to upload a new version for further discussion in the > coming weeks. > > ok, great, you intend to ask to move it back through wglc when you get settled then? (which is fine for me) > Tim > > > > > On 26 Jul 2018, at 08:02, Christopher Morrow > wrote: > > It occurs to me that ... we should have closed out the wglc for this > document prior to IETF week. > If this set of comments/edits is all done then we can send a new version > of the draft and forward things up the mgmt chain. > > thoughts? > > -chris > > On Tue, Jul 17, 2018 at 5:52 PM Tim Bruijnzeels wrote: > >> Hi Tom, >> >> Thanks for testing and the feedback. Comments below. >> >> > On 17 Jul 2018, at 12:58, Tom Harrison wrote: >> > >> > On Fri, Jun 08, 2018 at 06:30:41AM -0700, internet-drafts@ietf.org >> wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> This draft is a work item of the SIDR Operations WG of the IETF. >> >> >> >> Title : RPKI signed object for TAL >> >> Authors : Tim Bruijnzeels >> >> Carlos Martinez >> >> Filename : draft-ietf-sidrops-signed-tal-01.txt >> >> Pages : 12 >> >> Date : 2018-06-08 >> > >> > I've updated our proof-of-concept to match the new draft. Some >> > questions and minor suggestions: >> > >> > In section 3, there is: >> > >> > The ASN.1 syntax for the Signed TAL eContent defined in >> > Section 3.2. (This is the payload that specifies the AS being >> > authorized to originate routes as well as the prefixes to which >> > the AS may originate routes.) >> > >> > The text in parentheses looks to be a cut-and-paste from the ROA >> > profile document (RFC 6482). >> >> Fixed in my edit buffer. >> >> > In section 4, there is "[t]his EE certificate MUST have a 'notAfter' >> > time that reflects the intended time that this Signed TAL will be >> > published", which on its face implies that the 'notAfter' should be >> > set to the time when the object is first published. Changing it to >> > "reflects the intended time [or duration] for which this signed TAL >> > will be published" should make things clearer. >> >> Yes, you are right. The intention was duration. Fixed in the edit buffer= . >> >> > >> > The SubjectPublicKeyInfo in the TAL structure has the type IA5String. >> > Is there some reason not to use the 'raw' SubjectPublicKeyInfo type >> > from RFC 5280? >> >> This is an oversight. It should just be the raw DER structure. >> >> > Since activationTime is not needed for an in-protocol reason at the >> > moment, it would be good to add a note to the draft that it's there to >> > prompt discussion/feedback about future dating. >> > >> > On future dating more generally, I think it's a good idea, since it >> > allows for in-band signalling about the rollover and would (hopefully) >> > encourage a wider set of users to test the new tree before it becomes >> > the 'official' tree. >> >> The current draft assumes that the TA tests things before publishing the >> new signed TAL object, and then I think it would be okay for RPs to foll= ow >> this new TAL as soon as it=E2=80=99s available. >> >> But.. there may be good reasons for future dating / having a backup key. >> >> In that case I would suggest that we have a structure where the =E2=80= =98current=E2=80=99 >> TA key and URIs are always listed explicitly, pretty much like the docum= ent >> says now, but there is an optional similar structure with the intended >> =E2=80=98activationTime=E2=80=99 (informational only) for the new key. >> >> That way the roll can be prepared in advance. RPs could theoretically >> verify independently that things are okay - but I would like to avoid >> putting this burden on all RPs. Once things are okay to roll, the TA can >> update it=E2=80=99s signed TAL then to make the new key =E2=80=98current= =E2=80=99 and RPs can >> follow. >> >> As I said at the mic HSMs can be used to protect against key theft. But >> keys (or card sets) can still be lost. If access to the new key is lost, >> then the TA can just choose not complete the roll - remove it, replace i= t >> with a new target key. If access to the current key is lost, then things >> get more difficult. Then the new key would have to be allowed to take ov= er, >> e.g. automatically once the activation time is past? >> >> Explicit revocation of the old key is also possible, but would require >> that RPs constantly check these candidate keys. I am afraid this adds a = lot >> of overhead. >> >> Comments and ideas are most welcome! >> >> Tim >> >> >> >> >> >> >> > >> > -Tom >> > >> > _______________________________________________ >> > Sidrops mailing list >> > Sidrops@ietf.org >> > https://www.ietf.org/mailman/listinfo/sidrops >> >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >> > > --0000000000001510bf0571e773ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Jul 26, 2018 at 3:34 AM Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
Hi Chr= is,

The last call was on 'draft-ietf-sidrops-https-t= al-03=E2=80=99, see:

There was a nit and a suggestion for clarification by Job Snijders that I = would be happy to include in an update.

The signed= -tal document needs more work. I received useful feedback on list from Tom = Harrison and Di Ma, and a good in-depth discussion with Rob Austein. I plan= to upload a new version for further discussion in the coming weeks.
<= div>

ok, great, you intend = to ask to move it back through wglc when you get settled then? (which is fi= ne for me)
=C2=A0
Tim<= /div>




On 26 Jul 2018, at 08:02, Christopher Morrow <christopher.morrow@gmail.c= om> wrote:

It occurs to me that ... we should have clos= ed out the wglc for this document prior to IETF week.
If this set of co= mments/edits is all done then we can send a new version of the draft and fo= rward things up the mgmt chain.

thoughts?

-chris

On Tue, Jul 17, 2018 at 5:52 PM Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
=
Hi Tom,

Thanks for testing and the feedback. Comments below.

> On 17 Jul 2018, at 12:58, Tom Harrison <tomh@apnic.net> wrote:
>
> On Fri, Jun 08, 2018 at 06:30:41AM -0700, internet-drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts= directories.
>> This draft is a work item of the SIDR Operations WG of the IETF. >>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: RPKI signed object for TAL
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Tim Bruijnzeels
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Carlos Martinez
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : d= raft-ietf-sidrops-signed-tal-01.txt
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: 12
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : 2018-06-08
>
> I've updated our proof-of-concept to match the new draft.=C2=A0 So= me
> questions and minor suggestions:
>
> In section 3, there is:
>
>=C2=A0 =C2=A0The ASN.1 syntax for the Signed TAL eContent defined in >=C2=A0 =C2=A0Section 3.2.=C2=A0 (This is the payload that specifies the= AS being
>=C2=A0 =C2=A0authorized to originate routes as well as the prefixes to = which
>=C2=A0 =C2=A0the AS may originate routes.)
>
> The text in parentheses looks to be a cut-and-paste from the ROA
> profile document (RFC 6482).

Fixed in my edit buffer.

> In section 4, there is "[t]his EE certificate MUST have a 'no= tAfter'
> time that reflects the intended time that this Signed TAL will be
> published", which on its face implies that the 'notAfter'= should be
> set to the time when the object is first published.=C2=A0 Changing it = to
> "reflects the intended time [or duration] for which this signed T= AL
> will be published" should make things clearer.

Yes, you are right. The intention was duration. Fixed in the edit buffer.
>
> The SubjectPublicKeyInfo in the TAL structure has the type IA5String.<= br> > Is there some reason not to use the 'raw' SubjectPublicKeyInfo= type
> from RFC 5280?

This is an oversight. It should just be the raw DER structure.

> Since activationTime is not needed for an in-protocol reason at the > moment, it would be good to add a note to the draft that it's ther= e to
> prompt discussion/feedback about future dating.
>
> On future dating more generally, I think it's a good idea, since i= t
> allows for in-band signalling about the rollover and would (hopefully)=
> encourage a wider set of users to test the new tree before it becomes<= br> > the 'official' tree.

The current draft assumes that the TA tests things before publishing the ne= w signed TAL object, and then I think it would be okay for RPs to follow th= is new TAL as soon as it=E2=80=99s available.

But.. there may be good reasons for future dating / having a backup key.
In that case I would suggest that we have a structure where the =E2=80=98cu= rrent=E2=80=99 TA key and URIs are always listed explicitly, pretty much li= ke the document says now, but there is an optional similar structure with t= he intended =E2=80=98activationTime=E2=80=99 (informational only) for the n= ew key.

That way the roll can be prepared in advance. RPs could theoretically verif= y independently that things are okay - but I would like to avoid putting th= is burden on all RPs. Once things are okay to roll, the TA can update it=E2= =80=99s signed TAL then to make the new key =E2=80=98current=E2=80=99 and R= Ps can follow.

As I said at the mic HSMs can be used to protect against key theft. But key= s (or card sets) can still be lost. If access to the new key is lost, then = the TA can just choose not complete the roll - remove it, replace it with a= new target key. If access to the current key is lost, then things get more= difficult. Then the new key would have to be allowed to take over, e.g. au= tomatically once the activation time is past?

Explicit revocation of the old key is also possible, but would require that= RPs constantly check these candidate keys. I am afraid this adds a lot of = overhead.

Comments and ideas are most welcome!

Tim






>
> -Tom
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org=
> https://www.ietf.org/mailman/listinfo/sidrops<= br>
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops

--0000000000001510bf0571e773ac-- From nobody Thu Jul 26 07:19:24 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A41D3130E58; Thu, 26 Jul 2018 07:19:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <153261476362.25884.13351623488918768311@ietfa.amsl.com> Date: Thu, 26 Jul 2018 07:19:23 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-https-tal-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 14:19:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : Resource Public Key Infrastructure (RPKI) Trust Anchor Locator Authors : Geoff Huston Samuel Weiler George Michaelson Stephen Kent Tim Bruijnzeels Filename : draft-ietf-sidrops-https-tal-04.txt Pages : 10 Date : 2018-07-26 Abstract: This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). This document obsoletes RFC 7730 by adding support for HTTPS URIs in a TAL. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-https-tal-04 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-https-tal-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-https-tal-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 26 07:24:11 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17783130E5C for ; Thu, 26 Jul 2018 07:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-hLAPjnx2tV for ; Thu, 26 Jul 2018 07:24:07 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 C4FD5130E58 for ; Thu, 26 Jul 2018 07:24:06 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id b20-v6so1586840edt.10 for ; Thu, 26 Jul 2018 07:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nlnetlabs-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=wIXz6+/vUDKxARCly+rXE4WjiB4vEGVX1uUNwPj28cM=; b=YBMusxVwnffigmjHPcfxhCI4V672f+2V/LNB4Rj/ZTyrVYBt93sXwAe4cCniVipBbz VXnFqyjBRP1yW1vG2r/0UrR7dO8mBUYhRiyj+IWlvPa2XLh7XXrrwXRxCTGGboKzpSHg 584IybP86UA6vRlCXY1JFOu2hpteXHnEKrHRSwPZ3j+RG4SUDcmATnUTAdqCi2tsh1ya bWKy84wMV5RDWeRZD2g0nhG0fMoXOgw7DFOLXU1+rXW0CjNS8SkZznf9aQuBkuH8Vv7M eeaAop3KgaLXEVNP/UvLFaJ26GFeLpPvnvUpD/wdrDt6bOB+L1DvWpTj9iBf5chzqxcZ VJZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=wIXz6+/vUDKxARCly+rXE4WjiB4vEGVX1uUNwPj28cM=; b=H/SdMaO2sEq+FNZyHVYSb/flKrkyiadi1DX5vxQSRulQablAO5bsecdHmmRoD7uFCh HIe9mtD7w6XKbUEQbi9/nTUcEWBUwt9uPyIdEepSNSaOds/Lu71S+PlJ1EcfaZhrgNx7 64xiL5SD7B888CPIIVcZhYTtEdWbRTCftZCMn0nulg0G+yA4sOAmiPyoZJgXVwtIwfcM JK5g9xJkGNkRAYQiydUprdQKes/v142e7yUXesLQkA9KZR1eDwzwHY08eMHH4WzT163I p1B+6cfa9QjtWuDZCI/84zPm3ZZT7zS8PNh+3PI4DVaXBwDNVDsRfcEILXBoJYbf0DIF liuw== X-Gm-Message-State: AOUpUlENxDb+++Z5I9ZDbOGHRdRmPgahs9oW2xnmji5KKUzfIcS+wFBT ctX7X0ebJtfDi12PDVCf6MCeOQ== X-Google-Smtp-Source: AAOMgpebKS8p5J3iKLRmDGTtT2EOLxbNbMdqAACZY2f8xuEx8N2cZKBR28JmxBotgqSTCNjzf6EjMA== X-Received: by 2002:a50:c3c7:: with SMTP id i7-v6mr3026933edf.232.1532615045360; Thu, 26 Jul 2018 07:24:05 -0700 (PDT) Received: from ?IPv6:2a04:b900::1:2168:fbd9:cb78:4939? ([2a04:b900:0:1:2168:fbd9:cb78:4939]) by smtp.gmail.com with ESMTPSA id q5-v6sm793491edn.83.2018.07.26.07.24.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jul 2018 07:24:04 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_48D54699-BC8A-4F71-9082-1538EE834C7E" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Tim Bruijnzeels In-Reply-To: Date: Thu, 26 Jul 2018 16:24:03 +0200 Cc: sidrops@ietf.org, tomh@apnic.net Message-Id: <73546F49-19D9-4525-AE67-87B055CCBD1D@nlnetlabs.nl> References: <152846464123.15396.14579027912013078144@ietfa.amsl.com> <20180717165827.GA14191@tomh-laptop> <2D133A87-A328-4758-9452-929370F8F54E@nlnetlabs.nl> To: Christopher Morrow X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 14:24:10 -0000 --Apple-Mail=_48D54699-BC8A-4F71-9082-1538EE834C7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > On 26 Jul 2018, at 16:02, Christopher Morrow = wrote: > ok, great, you intend to ask to move it back through wglc when you get = settled then? (which is fine for me) I just uploaded = https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-https-tal-04 = = with the nits included. I want to ask you if you can conclude what the = outcome is of the WG-LC for this, but I hope it can progress to = publication. Signed-tal should just stay a WG document. I plan to have an -02 before = Bangkok, and based on how that is received we can then ask for WG-LC on = this one, or keep discussing and fixing things for a bit longer. Tim= --Apple-Mail=_48D54699-BC8A-4F71-9082-1538EE834C7E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

On 26 Jul 2018, at 16:02, Christopher Morrow = <christopher.morrow@gmail.com> wrote:
ok, great, you intend to ask to = move it back through wglc when you get settled then? (which is fine for = me)

I just uploaded https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-https-= tal-04 with the nits included. I want to ask you if you can = conclude what the outcome is of the WG-LC for this, but I hope it can = progress to publication.

Signed-tal should just stay a WG document. I plan to have an = -02 before Bangkok, and based on how that is received we can then ask = for WG-LC on this one, or keep discussing and fixing things for a bit = longer.

Tim
= --Apple-Mail=_48D54699-BC8A-4F71-9082-1538EE834C7E-- From nobody Fri Jul 27 09:12:17 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D27B130F8E; Fri, 27 Jul 2018 09:12:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-sidrops-ov-clarify@ietf.org, keyur@arrcus.com, sidrops@ietf.org, Keyur Patel , sidrops-chairs@ietf.org, warren@kumari.net Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <153270793031.333.2900788023503673455.idtracker@ietfa.amsl.com> Date: Fri, 27 Jul 2018 09:12:10 -0700 Archived-At: Subject: [Sidrops] Last Call: (Origin Validation Clarifications) to Proposed Standard X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 16:12:11 -0000 The IESG has received a request from the SIDR Operations WG (sidrops) to consider the following document: - 'Origin Validation Clarifications' as Proposed Standard This is a second IETF LC. The first one was accidentally started as a "Internet Standard" instead of "Proposed Standard". The original LC notice is here: https://mailarchive.ietf.org/arch/msg/ietf-announce/BgXnazE6uDDDnL4QEASwE4j9fHk The original LC thread is here: https://www.ietf.org/mail-archive/web/ietf/current/msg108610.html Thanks to S. Moonesamy for noticing this, and pointing out that a new LC is cleaner / more appropriate. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-08-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Deployment of RPKI-based BGP origin validation is hampered by, among other things, vendor mis-implementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration. This document is meant to clarify possible misunderstandings causing those mis-implementations; and thus updates RFC6811 by clarifying that all prefixes should be marked, and that policy must not be applied without operator configuration" The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-clarify/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-clarify/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Jul 27 09:49:45 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC2D130DD0; Fri, 27 Jul 2018 09:49:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk CC: morrowc@ops-netman.net, sidrops@ietf.org, sidrops-chairs@ietf.org, Chris Morrow , warren@kumari.net, draft-ietf-sidrops-rpki-tree-validation@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <153271017883.413.133137576195627940.idtracker@ietfa.amsl.com> Date: Fri, 27 Jul 2018 09:49:38 -0700 Archived-At: Subject: [Sidrops] Last Call: (RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator) to Informational RFC X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 16:49:39 -0000 The IESG has received a request from the SIDR Operations WG (sidrops) to consider the following document: - 'RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator' as Informational RFC An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see section 4.2.3). The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-08-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the approach to validate the content of the RPKI certificate tree, as it is implemented in the RIPE NCC RPKI Validator. This approach is independent of a particular object retrieval mechanism. This allows it to be used with repositories available over the rsync protocol, the RPKI Repository Delta Protocol, and repositories that use a mix of both. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-tree-validation/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-tree-validation/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Jul 27 09:50:51 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C41813105D; Fri, 27 Jul 2018 09:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 HRf4JcHdUQWw; Fri, 27 Jul 2018 09:50:39 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6B1131002; Fri, 27 Jul 2018 09:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2450; q=dns/txt; s=iport; t=1532710239; x=1533919839; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PnzpiHYrAz3xcbn47CeME+gZB+hkoaMFmvKjkIoooWs=; b=FuzTc7X5mRK+Qt91VOMzxGsYIR/37JH/iFNLJpNy/wYrk4N1Cx9+5NS3 UJxQ7bybP5mAmCfWWvIfBbeNuWyGbFucA+A9+Rq2qKjgvtSHJ2jIcU7PL r8779C+ovWP76zPj7lu2GJpg6DF8CGuH0hTx5Hz4n5BZX9ncxpeXzgtRt M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C7AADYTFtb/4QNJK1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNOY38oCot6jDuCDJVRgXoLGA2EAUYCgnshNBgBAgEBAgE?= =?us-ascii?q?BAm0cDIU2AQEBBAEBODQLDAQCAQgRBAEBHwULJwsUCQgCBAENBQiDGYF/DwO?= =?us-ascii?q?vVoo+BYkCF4FBP4ERgxKDGwEBAQIBgTwBAVCFJAKSDYd+CQKGFIVegzqBUB+?= =?us-ascii?q?De4gkik6HPwIRFIEkHTiBUnAVO4I1ATOCTYhIhT5vAY0KDRcHgQGBGwEB?= X-IronPort-AV: E=Sophos;i="5.51,410,1526342400"; d="scan'208";a="419497090" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2018 16:50:37 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id w6RGob9g001562 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Jul 2018 16:50:37 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 27 Jul 2018 11:50:36 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Fri, 27 Jul 2018 11:50:37 -0500 From: "Jakob Heitz (jheitz)" To: "ietf@ietf.org" , IETF-Announce CC: "sidrops-chairs@ietf.org" , Keyur Patel , "sidrops@ietf.org" , "draft-ietf-sidrops-ov-clarify@ietf.org" , "warren@kumari.net" Thread-Topic: [Sidrops] Last Call: (Origin Validation Clarifications) to Proposed Standard Thread-Index: AQHUJcSkNi0whkCqBUauWCe3UoWZCqSjSENQ Date: Fri, 27 Jul 2018 16:50:37 +0000 Message-ID: References: <153270793031.333.2900788023503673455.idtracker@ietfa.amsl.com> In-Reply-To: <153270793031.333.2900788023503673455.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.198.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [Sidrops] Last Call: (Origin Validation Clarifications) to Proposed Standard X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 16:50:49 -0000 I support this document. Regards, Jakob. -----Original Message----- From: Sidrops On Behalf Of The IESG Sent: Friday, July 27, 2018 9:12 AM To: IETF-Announce Cc: sidrops-chairs@ietf.org; Keyur Patel ; sidrops@ietf.o= rg; draft-ietf-sidrops-ov-clarify@ietf.org; warren@kumari.net Subject: [Sidrops] Last Call: (Origi= n Validation Clarifications) to Proposed Standard The IESG has received a request from the SIDR Operations WG (sidrops) to consider the following document: - 'Origin Validation Clarifications' as Proposed Standard This is a second IETF LC. The first one was accidentally started as a "Internet Standard" instead of "Proposed Standard". The original LC notice is here: https://mailarchive.ietf.org/arch/msg/ietf-= announce/BgXnazE6uDDDnL4QEASwE4j9fHk The original LC thread is here: https://www.ietf.org/mail-archive/web/ietf/= current/msg108610.html Thanks to S. Moonesamy for noticing this, and pointing out that a new LC=20 is cleaner / more appropriate.=20 The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-08-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning = of the Subject line to allow automated sorting. Abstract Deployment of RPKI-based BGP origin validation is hampered by, among other things, vendor mis-implementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration. This document is meant to clarify possible misunderstandings causing those mis-implementations; and thus updates RFC6811 by clarifying that all prefixes should be marked, and that policy must not be applied without operator configuration" The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-clarify/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-clarify/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ Sidrops mailing list Sidrops@ietf.org https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Jul 30 18:35:50 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1D4130E2F; Mon, 30 Jul 2018 18:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 f70PajOW6bNj; Mon, 30 Jul 2018 18:35:48 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF462130E23; Mon, 30 Jul 2018 18:35:44 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1fkJZf-00067Y-BI; Tue, 31 Jul 2018 01:35:43 +0000 Date: Mon, 30 Jul 2018 18:35:42 -0700 Message-ID: From: Randy Bush To: Brian Carpenter Cc: , draft-ietf-sidrops-ov-clarify.all@ietf.org, sidrops@ietf.org In-Reply-To: <153300071561.7755.6509769097582818893@ietfa.amsl.com> References: <153300071561.7755.6509769097582818893@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-clarify-03 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 01:35:49 -0000 thanks for review! > Title would be more searchworthy if it read "BGP-4 Origin Validation Clarifications" ok. how about "BGP-4 RPKI-Based Origin Validation Clarifications?" > Abstract: s/\"/./ whoopsie. will keep new xml in in emacs buffer until all reviews are in randy From nobody Tue Jul 31 08:49:27 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A610D1311EA; Mon, 30 Jul 2018 18:31:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Carpenter To: Cc: draft-ietf-sidrops-ov-clarify.all@ietf.org, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153300071561.7755.6509769097582818893@ietfa.amsl.com> Date: Mon, 30 Jul 2018 18:31:55 -0700 Archived-At: X-Mailman-Approved-At: Tue, 31 Jul 2018 08:49:26 -0700 Subject: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-clarify-03 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 01:32:05 -0000 Reviewer: Brian Carpenter Review result: Ready with Nits Gen-ART Last Call review of draft-ietf-sidrops-ov-clarify-03 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-sidrops-ov-clarify-03.txt Reviewer: Brian Carpenter Review Date: 2018-07-31 IETF LC End Date: 2018-08-10 IESG Telechat date: Summary: Ready -------- Comments: Clear & easy to understand --------- Nits: ----- Title would be more searchworthy if it read "BGP-4 Origin Validation Clarifications" Abstract: s/\"/./ From nobody Tue Jul 31 08:49:40 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E091F129385; Mon, 30 Jul 2018 19:09:24 -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, FREEMAIL_FROM=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 0KmhQuIVFu-f; Mon, 30 Jul 2018 19:09:23 -0700 (PDT) Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DC3B130E11; Mon, 30 Jul 2018 19:09:23 -0700 (PDT) Received: by mail-pl0-x232.google.com with SMTP id d5-v6so868674pll.4; Mon, 30 Jul 2018 19:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=P77IqOrBXBjbAdI0eepyD60xWeyVYf4KpY+JYBOlK6o=; b=ZS4RQfzpS1RXH8xVQpr/llpJZHro4cDUaqlo255DgPku1Ln5I3wLckP+xuhEZHzSp+ IWXItqxk7VbQlQug5GGPwNcK/912TRR+sUUC2gZ97O4CElUEJkgytmFr+eVFL3pk6uVy r2LGO9VqkPGIWkOWguR/qTr6QzQXjdJpIV8jokwPT1p7guDH7aCrDwoxRsSVI2h5ojJp 63QT9FRC2RcfCFy3JTwckYDw3vfwPIZ33R+iXLZD+54c9ekannXOCEWA2OFmxZ06KLu0 tkp7ILLoCFFXCZNxkyuOgGC+VOmWKZDuIZObD8YHiLA0r+0MQwAfN5eN6ScI/BRhLRqk 9+eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=P77IqOrBXBjbAdI0eepyD60xWeyVYf4KpY+JYBOlK6o=; b=lS8zzAX389gwooLun0eYktqGXKtIzPxY/eggC9GeNDsBaVhgVqMAu7WmtfYV2N15J5 fUj0LkQlqVOo8yyM3U4ghaXmRAXwUpxz+B5PQh69zbSIyDcEHYzYWQypzZsWIi7iZPML lkIQIMlz3eB4pT6nWs74b11sTSswIFeI42KDqhswrTvA45gUPxsOmnfH0PDldPIOe34q 8bnuFMWL0yFrUGvldwisERA1C7+DEoS4dIOrNb4hna0+wMKagUBHWWH+oGYpdu8p0hgD jwCHHwLmFMjP5LieM3CJacCmIqDpqZMAwXqgPI1qwut0vBPIQSoNu0mze31N0LJjxujU C5Pw== X-Gm-Message-State: AOUpUlHIclcDuw5BwcmM1LU5IFlA8F/nBQhNZSAJBlN2VQ7wcYX3XIQQ 2/gtn3FS+LPABMWYaWj1bGPnTYYa X-Google-Smtp-Source: AAOMgpdyFyO8PXpmffjaY6XCiZXk/VXgtFNADdAmrmqOyl3NzpLwvDmBu0UbR3f9gTH9ug64hPBUVA== X-Received: by 2002:a17:902:5617:: with SMTP id h23-v6mr18485685pli.324.1533002962857; Mon, 30 Jul 2018 19:09:22 -0700 (PDT) Received: from [172.24.11.27] ([202.36.244.178]) by smtp.gmail.com with ESMTPSA id y5-v6sm38861048pfj.169.2018.07.30.19.09.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jul 2018 19:09:21 -0700 (PDT) To: Randy Bush Cc: gen-art@ietf.org, draft-ietf-sidrops-ov-clarify.all@ietf.org, sidrops@ietf.org References: <153300071561.7755.6509769097582818893@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <8a0fc2dc-b5ae-ccf5-68c4-2284b5229c8b@gmail.com> Date: Tue, 31 Jul 2018 14:09:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 31 Jul 2018 08:49:26 -0700 Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-clarify-03 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 02:09:25 -0000 On 31/07/2018 13:35, Randy Bush wrote: > thanks for review! > >> Title would be more searchworthy if it read "BGP-4 Origin Validation Clarifications" > > ok. how about "BGP-4 RPKI-Based Origin Validation Clarifications?" Sure Brian > >> Abstract: s/\"/./ > > whoopsie. > > will keep new xml in in emacs buffer until all reviews are in > > randy >