From nobody Mon Aug 2 04:36:53 2021 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 3AAF03A19C3 for ; Mon, 2 Aug 2021 04:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdM4uPYRafYa for ; Mon, 2 Aug 2021 04:36:48 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B51333A19B0 for ; Mon, 2 Aug 2021 04:36:47 -0700 (PDT) Received: from fraeml702-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GdbYw6FVtz6F88F for ; Mon, 2 Aug 2021 19:36:36 +0800 (CST) Received: from kwepeml500004.china.huawei.com (7.221.188.141) by fraeml702-chm.china.huawei.com (10.206.15.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Mon, 2 Aug 2021 13:36:44 +0200 Received: from kwepeml500001.china.huawei.com (7.221.188.162) by kwepeml500004.china.huawei.com (7.221.188.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 2 Aug 2021 19:36:42 +0800 Received: from kwepeml500001.china.huawei.com ([7.221.188.162]) by kwepeml500001.china.huawei.com ([7.221.188.162]) with mapi id 15.01.2176.012; Mon, 2 Aug 2021 19:36:42 +0800 From: "Wanghaibo (Rainsword)" To: "sidrops@ietf.org" Thread-Topic: Hi all, about the prensetation of draft-shen-sidrops-region-verification, some reply are here Thread-Index: AdeHknKEfh8tHtn2Roea65kWZ2cnEg== Date: Mon, 2 Aug 2021 11:36:42 +0000 Message-ID: <9409e157dd454d2e8a07add1fb7a0a10@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.153.118] Content-Type: multipart/alternative; boundary="_000_9409e157dd454d2e8a07add1fb7a0a10huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Sidrops] Hi all, about the prensetation of draft-shen-sidrops-region-verification, some reply are here X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 11:36:51 -0000 --_000_9409e157dd454d2e8a07add1fb7a0a10huaweicom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQo0KSBIYWlibyBXYW5nIC0gWzEwIG1pbnV0ZXNdIFJlZ2lvbiBWZXJpZmljYXRp b24NCmRyYWZ0LXNoZW4tc2lkcm9wcy1yZWdpb24tdmVyaWZpY2F0aW9uDQoNClJhbmR5IEJ1c2g6 DQpUaGlzIG1vZGVsIGFzc3VtZXMgaW4gcmVnaW9uIKGwbm8gcm91dGVycyBhcmUgY29tcHJvbWlz ZWShsSAtIGlmIHRoaXMgaXMgdHJ1ZSB3aXRoIG5laWdoYm9ycyB0aGVuIG5vIGJvZHkgb24gdGhl IGludGVybmV0IGlzIGNvbXByb21pc2VkLg0KDQpbUmVwbHldo7ogT3VyIG1vZGVsIGRvZXMgbm90 IGFzc3VtZSB0aGF0IHJlZ2lvbiByb3V0ZXJzIGFyZSBub3QgY29tcHJvbWlzZWQuIFRoaXMgZmVh dHVyZSBwcm90ZWN0cyByb3V0ZXMgaW4gdGhlIHJlZ2lvbiB0byBpbXByb3ZlIHRoZSByZWdpb24n cyBzZWN1cml0eS4gSWYgYW4gZXh0ZXJuYWwgcm91dGUgZW50ZXJzIHRoZSByZWdpb24sIHdoZXRo ZXIgdGhlIHJvdXRlIGlzIHN0aWxsIHNlY3VyZSBpcyBiZXlvbmQgdGhlIHByb3RlY3Rpb24gc2Nv cGUgb2YgdGhpcyBtb2RlbC4NCg0KQmVuIE1hZGRpc29uOg0KVGhlcmUgYXJlIGEgbG90IG9mIHBy b2JsZW1zIHdpdGggdGhpcyBhcHByb2FjaC4gVGhlIHR3byBtb3N0IHByb2JsZW1tYXRpYyBhcmU6 IFRoZSBmaXJzdCBvbmUgaXMgdGhlIG9uZSBSYW5keSBqdXN0IGNhbGxlZCBvdXQsIG5vIG9wZXJh dG9yIGluIHRoZSBERlogaXMgdHJ1c3RlZCBlbm91Z2ggbm90IHRvIGJlIGNhcGFibGUgb2YgbWFr aW5nIGEgY29uZmlndXJhdGlvbiBlcnJvciwgdGhpcyBpcyB1bndvcmthYmxlIHNpbmNlIGZldyBv cGVyYXRvcnMgd2lsbCBlc3RhYmxpc2ggYSByZWdpb25hbCBjb25mZWRlcmF0aW9uIGFuZCB3b3Jr IG9uIHRoZSBhc3N1bXB0aW9uIG9mIHRydXN0IGluc2lkZSB0aGUgcmVnaW9uLg0KDQpbUmVwbHld OiBDb25maWd1cmF0aW9uIG1pc3Rha2VzIGFyZSBpbmV2aXRhYmxlLCBhbmQgdGhlIG1vZGVsIGhl cmUgaXMgdXNlZCB0byBtZWFzdXJlIHRoZSBpbXBhY3Qgb2Ygb3RoZXJzJyBhY3Rpb25zIG9uIHRo ZWlyIG93biByb3V0aW5nLg0KDQpUaGUgc2Vjb25kIHByb2JsZW0gaXMgdGhhdCBpdCBtYWtlcyB0 aGUgaW50ZXJuZXQgdG9wb2xvZ3kgYXMgYSB3aG9sZSBleHRyZW1lbHkgZnJhZ2lsZTogdGhlIHJ1 bGVzIGFzIGVudW1lcmF0ZWQgd291bGQgY2F1c2UgdmFsaWQgcm91dGVzLCB0cmFuc2l0aW5nIHRv IGJlIHJlamVjdGVkIGFzIHdlbGwuIElmIHBlZXJpbmcgYnJva2UsIHRoZSChsG91dHNpZGWhsSBy b3V0ZXMgd291bGQgYmUgcmVqZWN0ZWQuIEFTUEEgb2JqZWN0cyBpbiBzeXN0ZW0gdG8gY29uZmly bSB0aGUgQVMgaXMgYSBsZWdpdC4gdHJhbnNpdCBwcm92aWRlciwgdGhlbiB0aGVyZSBzZWVtcyB0 byBiZSBhIHZlcnkgY29ybmVyLWNhc2UgYXR0YWNrIHZlY3Rvci4gSSBkb26hr3QgdGhpbmsgdGhp cyBhcHByb2FjaCBpcyB3b3J0aCBwdXJzdWluZy4NCg0KW1JlcGx5XTogIE9mIGNvdXJzZSwgdGhl IHNjZW5hcmlvcyBsaXN0ZWQgaGVyZSBhcmUgc2ltcGxpZmllZCBzY2VuYXJpb3MuIFRoZXJlIGFy ZSBtdWx0aXBsZSBsaW5rcyBiZXR3ZWVuIElTUDEgYW5kIElTUDIsIHdoaWNoIGNhbiBwcm92aWRl IHN1ZmZpY2llbnQgcHJvdGVjdGlvbiBvciBjYW4gYmUgcHJvdGVjdGVkIGJ5IG90aGVyIGNvbmZl ZGVyYXRpb24gbWVtYmVycywgcGVyaGFwcyBJU1A0LCBJU1A1LiBUcmFmZmljIGlzIG5vdCBleHBl Y3RlZCB0byBiZSBkZXRvdXJlZCB0aHJvdWdoIElTUDEuDQpUaGlzIG1ldGhvZCBkb2VzIG5vdCBy ZXN1bHQgaW4gcmVqZWN0aW9uIG9mIHZhbGlkIHJvdXRlcy4gSXQgcHJvdGVjdHMgb25seSB0aGUg cm91dGVzIGJlbG9uZyB0byBsb2NhbCByZWdpb24gYW5kIGRvZXMgbm90IGFzc3VtZSBleHRlcm5h bCByb3V0ZXMuIFRoZSBtb2RlbCBoZXJlIHByb3RlY3RzIHRoZSBsZWFybmluZyBwYXRocyBvZiB0 aGVzZSBsb2NhbCByZWdpb24gcm91dGVzLiBJbiBwcmFjdGljZSwgc29tZSBjYXJyaWVycyBhbHNv IGRlcGxveSBtYW55IGFzLXBhdGgtZmlsdGVycyB0byBwZXJmb3JtIHNpbWlsYXIgcGF0aCBmaWx0 ZXJpbmcuDQoNClJ1ZGlnZXIgVm9sazogcHJvYmxlbSBzY2VuYXJpbyB3YXMgobByb3V0ZSBwcm9w YWdhdGlvbiBiZXR3ZWVuIHZhcmlvdXMgQVNOIG5vdCBzZWN1cmWhsSB0aGVuIGNyZWF0ZSBmYWly bHkgY29tcGxleCBzY2hlbWUgb2YgZGF0YSwgY2hlY2tzIHRvIHNlY3VyZSB0aGluZ3MuIG5vdCBx dWVzdGlvbmluZywgd2hhdCBjaGVja3MgYXJlIGRvbmUgYW5kIHdoYXQgY2hlY2tzIHdvdWxkIGJl IHJlYXNvbmFibGUgdG8gZG8sIGF0IHRoZSB2YXJpb3VzIHBsYWNlcywgaXMgbWlzc2luZy4gSSBo YXZlIHRyb3VibGUgdG8gYmVsaWV2ZSB5b3UgcmVhbGx5IGFzc3VtZSB3aXRoaW4gb25lIElTUCAy IGRvemVuIEFTIGFyZSBmdWxseSBpbnRlcmNvbm5lY3RlZCB3aXRob3V0IGFueSBjaGVja3MgYW5k IHRoYXRzIHJlYXNvbmFibGUgcG9saWN5LiBSYW5keSB3YXMgc3VjY2luY3QsIGJ1dCBwbGVhc2Ug ZXhwbGFpbiBleGFjdGx5IHdoYXQgY2hlY2tzIGFuZCBndWFyYW50ZWVzIHlvdSBhcmUgYXNzdW1p bmcgb3IgZHJvcHBpbmcgd2l0aGluIHlvdXIgc3RhcnRpbmcgc2NlbmFyaW8NCg0KW1JlcGx5XaO6 VGhlIG1vZGVsIGhlcmUgZG9lcyBub3QgcmVkdWNlIHRoZSBleGlzdGluZyBwcm90ZWN0aW9uIG1l YXN1cmVzLCBidXQgYWRkcyBuZXcgbWV0aG9kIHRvIHN0cmVuZ3RoZW4gdGhlIHByb3RlY3Rpb24g b2YgaXRzZWxmLg0KVGhlIGRhdGEgbW9kZWwgaGVyZSBpcyBub3QgY29tcGxleC4gT25seSBuZWVk IHRvIHNwZWNpZnkgdGhlIElTUCdzIG93biBBU2VzLiBUaGVzZSBBU2VzIGFyZSBwdWJsaWMgaW5m b3JtYXRpb24sIGJ1dCB0aGV5IGFyZSBub3QgYWdncmVnYXRlZCBmb3IgdXNlIGJlZm9yZS4NCg0K DQpKb2IgU25pamRlcnM6IGl0IGFwcGVhcnMgdG8gbWUgeW91ciB1c2VycyBhcmUgbm90IGxpa2Ug dGhvc2UgaW4gRXVyb3BlLCB5b3UgYXJlIG5lZWRpbmcgdG8gZm9ybSChsGFnZ3JlZ2F0ZXOhsSBv ZiBzb21lIGtpbmQuIEkgdGhpbmsgeW91IG1pZ2h0IG5lZWQgdG8gZ28gSURSIHRvIGRpc2N1c3Mu IEVuY291cmFnZSB5b3UgdG8gc3BlY2lmeSBpbiBBU04uMSBob3cgeW91IGVudmlzaW9uIHRoZSBv YmplY3RzLCB0byBmYWNpbGl0YXRlIHRoZSBkaXNjdXNzaW9uLg0KDQpbUmVwbHldo7pUaGFua3Ms IHdlIHdpbGwgY29uc2lkZXIgeW91ciBzdWdnZXN0aW9ucy4NCg0KUmVnYXJkcywNCkhhaWJvDQo= --_000_9409e157dd454d2e8a07add1fb7a0a10huaweicom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

 

4) Haibo Wang - [10 minutes] Re= gion Verification

draft-shen-sidrops-region-verif= ication

 

Randy Bush: <= /p>

This model assumes in region = =A1=B0no routers are compromised=A1=B1 - if this is true with neighbors the= n no body on the internet is compromised.

 

[Reply]=A3=BA Our model does n= ot assume that region routers are not compromised. This feature protects ro= utes in the region to improve the region's security. If an external route enters the region, whether the route is still secure is = beyond the protection scope of this model.

 

Ben Maddison:

There are a lot of problems wit= h this approach. The two most problemmatic are: The first one is the one Ra= ndy just called out, no operator in the DFZ is trusted enough not to be cap= able of making a configuration error, this is unworkable since few operators will establish a regional confedera= tion and work on the assumption of trust inside the region.

 

[Reply]: Configuration mistakes= are inevitable, and the model here is used to measure the impact of others= ' actions on their own routing.

 

The second problem is that it m= akes the internet topology as a whole extremely fragile: the rules as enume= rated would cause valid routes, transiting to be rejected as well. If peeri= ng broke, the =A1=B0outside=A1=B1 routes would be rejected. ASPA objects in system to confirm the AS is a legit. transit = provider, then there seems to be a very corner-case attack vector. I don=A1= =AFt think this approach is worth pursuing.

 

[Reply]:  Of course, the s= cenarios listed here are simplified scenarios. There are multiple links bet= ween ISP1 and ISP2, which can provide sufficient protection or can be prote= cted by other confederation members, perhaps ISP4, ISP5. Traffic is not expected to be detoured through ISP1.

This method does not result in = rejection of valid routes. It protects only the routes belong to local regi= on and does not assume external routes. The model here protects the learnin= g paths of these local region routes. In practice, some carriers also deploy many as-path-filters to perform sim= ilar path filtering.

 

Rudiger Volk: problem scenario = was =A1=B0route propagation between various ASN not secure=A1=B1 then creat= e fairly complex scheme of data, checks to secure things. not questioning, = what checks are done and what checks would be reasonable to do, at the various places, is missing. I have trouble to bel= ieve you really assume within one ISP 2 dozen AS are fully interconnected w= ithout any checks and thats reasonable policy. Randy was succinct, but plea= se explain exactly what checks and guarantees you are assuming or dropping within your starting scenario=

 

[Reply]=A3=BAThe model here do= es not reduce the existing protection measures, but adds new method to stre= ngthen the protection of itself.

The data model here is not comp= lex. Only need to specify the ISP's own ASes. These ASes are public informa= tion, but they are not aggregated for use before.

 

 

Job Snijders: it appears to me = your users are not like those in Europe, you are needing to form =A1=B0aggr= egates=A1=B1 of some kind. I think you might need to go IDR to discuss. Enc= ourage you to specify in ASN.1 how you envision the objects, to facilitate the discussion.

 

[Reply]=A3=BAThanks, we will c= onsider your suggestions.

 

Regards,

Haibo

--_000_9409e157dd454d2e8a07add1fb7a0a10huaweicom_-- From nobody Wed Aug 4 01:24:58 2021 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 835723A0D95 for ; Wed, 4 Aug 2021 01:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 R_AXOeSo5iln for ; Wed, 4 Aug 2021 01:24:51 -0700 (PDT) Received: from outbound.soverin.net (outbound.soverin.net [116.202.126.228]) (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 9B6283A0D94 for ; Wed, 4 Aug 2021 01:24:51 -0700 (PDT) Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 85B6194B for ; Wed, 4 Aug 2021 08:24:47 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1628065487; bh=G75CWHjGq5rKuf6G8Avp+NpSGFU+AAMr+Qmc5RRhm+g=; h=From:Date:Subject:To:From; b=DFVrtIcvUhHbQw8+E79Nxhp2ksM2s1kaXFv3sESrDnm+dal4aDWrAhoDdFz635D4H s4J3wMPY6/mHkWYHXvDgWTQhiKKYK8Xfs6atst2Nj9EE5V0QgO/T6MkiskVvMPA8iI DJWeW0YMhRcg57QdePU5QvvDjrFTVocvHbMCB+EtmxGdsLrAwGI+xIwZpzZlPTuwe1 0UasJc1v0wXJ7CBk36OZ4pS2jhCn2lGCEzM6+oYM0O13hD0TVEElmaH4I25Bl01bZC REyFchP4Bx9p5Tpd9wZbL4O+IzoUfNPh1MQPT0ZiGti2deFrfasBoPeduV9uaGnB3t fhYXTBq5UhiTg== From: Tim Bruijnzeels Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Wed, 4 Aug 2021 10:24:45 +0200 Message-Id: <810C485C-EAA4-481A-867D-111D0630D723@nlnetlabs.nl> To: SIDR Operations WG Archived-At: Subject: [Sidrops] Do ALL CA implementers include ALL *current* certificates in the "Resource Class List Response"? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 08:24:56 -0000 Dear group, CA implementers in particular, I am looking for clarity on RFC 6492 section 3.3.2: The provisioning = protocol "Resource Class List Response". This response payload includes information on resource and validity time = entitlements for a child CA, as well as a list of current certificates. = My issue is that I cannot find a normative "MUST" that says that the = parent CA MUST include any and all current certificate for each of the = child CA's keys. I believe that this is the intention, but I cannot = assume now that every parent CA in fact does this. So my question to other CA implementers is whether they will always = include the full set of (current) certificates for all child keys known = by the parent? And furthermore whether it's just me having doubts here, = or that a small clarification on this point would be good to add or keep = in mind for RFC 6492. This is important, because IF the parent CA always includes the full set = of current certificates for all keys, then the child CA can detect = whether there is any inconsistency in what it believes the certified key = is (or keys in case of a roll) versus the parent's view on this. And = then it could take actions to recover (e.g. request revocation of = surplus keys, certification of its current key, or even perform an = emergency roll to a new key state). Kind regards, Tim Bruijnzeels (implementer of the Krill CA) From nobody Wed Aug 4 01:47:19 2021 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 76DE83A0EB8 for ; Wed, 4 Aug 2021 01:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 oS05joOmGgxh for ; Wed, 4 Aug 2021 01:47:15 -0700 (PDT) Received: from out20-13.mail.aliyun.com (out20-13.mail.aliyun.com [115.124.20.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8EF3A0EB5 for ; Wed, 4 Aug 2021 01:47:13 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.3478912|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_news_journal|0.547682-0.0485896-0.403728; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047198; MF=madi@rpstir.net; NM=1; PH=DS; RN=1; RT=1; SR=0; TI=SMTPD_---.KvCXz49_1628066824; Received: from smtpclient.apple(mailfrom:madi@rpstir.net fp:SMTPD_---.KvCXz49_1628066824) by smtp.aliyun-inc.com(10.147.41.138); Wed, 04 Aug 2021 16:47:05 +0800 From: Di Ma Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Message-Id: <7C44766F-CB65-41D1-BF9E-A8A1E54B2093@rpstir.net> Date: Wed, 4 Aug 2021 16:47:04 +0800 To: SIDR Operations WG X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: [Sidrops] RTR over QUIC X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 08:47:18 -0000 Hi, folks, I am recently exploring to improve RTR. As we test our RP implementation, RTR would start over in case of just = one piece of wrong PDU, which is more remarkably observed when a router = is downloading the full copy from RTR server. I think this could be a = problem since there is an increasing both number and type of RPKI data. Since QUIC can tolerate packet loss to some extent, I am trying to let = RPSTIR call QUIC for transport.=20 Besides, QUIC has got intrinsic support of TLS which is another feature = that RTR could benefit from. =20 Any big idea or practice on this point? Shall this WG consider = standardizing RTR over QUIC? Di =20= From nobody Wed Aug 4 02:16:05 2021 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 3186C3A1068 for ; Wed, 4 Aug 2021 02:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYZanK055cmh for ; Wed, 4 Aug 2021 02:16:01 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E3DA3A1067 for ; Wed, 4 Aug 2021 02:16:01 -0700 (PDT) Received: (qmail 66933 invoked by uid 1000); 4 Aug 2021 09:15:58 -0000 Date: Wed, 4 Aug 2021 11:15:58 +0200 From: Claudio Jeker To: Di Ma Cc: SIDR Operations WG Message-ID: <20210804091558.GE34554@diehard.n-r-g.com> References: <7C44766F-CB65-41D1-BF9E-A8A1E54B2093@rpstir.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C44766F-CB65-41D1-BF9E-A8A1E54B2093@rpstir.net> Archived-At: Subject: Re: [Sidrops] RTR over QUIC X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 09:16:03 -0000 On Wed, Aug 04, 2021 at 04:47:04PM +0800, Di Ma wrote: > Hi, folks, > > I am recently exploring to improve RTR. > > As we test our RP implementation, RTR would start over in case of just one piece of wrong PDU, which is more remarkably observed when a router is downloading the full copy from RTR server. I think this could be a problem since there is an increasing both number and type of RPKI data. > > Since QUIC can tolerate packet loss to some extent, I am trying to let > RPSTIR call QUIC for transport. > > Besides, QUIC has got intrinsic support of TLS which is another feature > that RTR could benefit from. > > Any big idea or practice on this point? Shall this WG consider > standardizing RTR over QUIC? > What does QUIC solve that TCP does not that is relevant for RTR? I really see no point in pushing for QUIC for something that works perfectly over TCP and has no need to work around TCP window scaling. TCP stacks are widely available whereas QUIC is not. -- :wq Claudio From nobody Wed Aug 4 02:22:45 2021 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 7122F3A10B9 for ; Wed, 4 Aug 2021 02:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1v9_m2zOpBfy for ; Wed, 4 Aug 2021 02:22:39 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C90C3A0C50 for ; Wed, 4 Aug 2021 02:22:39 -0700 (PDT) Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GfmV41gLlz6GFhK for ; Wed, 4 Aug 2021 17:22:20 +0800 (CST) Received: from kwepeml500001.china.huawei.com (7.221.188.162) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 4 Aug 2021 11:22:34 +0200 Received: from kwepeml500002.china.huawei.com (7.221.188.128) by kwepeml500001.china.huawei.com (7.221.188.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 4 Aug 2021 17:22:32 +0800 Received: from kwepeml500002.china.huawei.com ([7.221.188.128]) by kwepeml500002.china.huawei.com ([7.221.188.128]) with mapi id 15.01.2176.012; Wed, 4 Aug 2021 17:22:32 +0800 From: Chenshuanglong To: Di Ma , SIDR Operations WG Thread-Topic: [Sidrops] RTR over QUIC Thread-Index: AQJIOw3LW+CJ9NIt3hXkPPTPxnRQPqqBqmHw Date: Wed, 4 Aug 2021 09:22:32 +0000 Message-ID: <0db4510ab252453384fb3d91adaf6aa9@huawei.com> References: <7C44766F-CB65-41D1-BF9E-A8A1E54B2093@rpstir.net> In-Reply-To: <7C44766F-CB65-41D1-BF9E-A8A1E54B2093@rpstir.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.142] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Sidrops] RTR over QUIC X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 09:22:44 -0000 SGkgRGmjrA0KDQpXZSBhcmUgYWxzbyBleHBsb3JpbmcgdGhlIGZlYXNpYmlsaXR5IG9mIEJHUCBv dmVyIFFVSUMsIGFuZCBJIHRoaW5rIGJvdGggQkdQIG92ZXIgUVVJQyBhbmQgUlRSIG92ZXIgUVVJ QyBhcmUgdGVjaG5pY2FsbHkgZmVhc2libGUuIA0KDQpJbiBhZGRpdGlvbiwgUVVJQydzIHdlYWsg bmV0d29yayB0b2xlcmFuY2UsIHNob3J0IGxhdGVuY3kgcGVyZm9ybWFuY2UsIGFuZCBpbmhlcmVu dCBzdXBwb3J0IGZvciBUTFMgbWF5IGJlbmVmaXQgcHJvdG9jb2xzLg0KDQpCZXN0UmVnYXJkcw0K U2h1YW5nbG9uZw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTaWRyb3Bz IFttYWlsdG86c2lkcm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGkgTWENClNl bnQ6IFdlZG5lc2RheSwgQXVndXN0IDQsIDIwMjEgNDo0NyBQTQ0KVG86IFNJRFIgT3BlcmF0aW9u cyBXRyA8c2lkcm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtTaWRyb3BzXSBSVFIgb3ZlciBRVUlD DQoNCkhpLCBmb2xrcywNCg0KSSBhbSByZWNlbnRseSBleHBsb3JpbmcgdG8gaW1wcm92ZSBSVFIu DQoNCkFzIHdlIHRlc3Qgb3VyIFJQIGltcGxlbWVudGF0aW9uLCBSVFIgd291bGQgc3RhcnQgb3Zl ciBpbiBjYXNlIG9mIGp1c3Qgb25lIHBpZWNlIG9mIHdyb25nIFBEVSwgd2hpY2ggaXMgbW9yZSBy ZW1hcmthYmx5IG9ic2VydmVkIHdoZW4gYSByb3V0ZXIgaXMgZG93bmxvYWRpbmcgdGhlIGZ1bGwg Y29weSBmcm9tIFJUUiBzZXJ2ZXIuIEkgdGhpbmsgdGhpcyBjb3VsZCBiZSBhIHByb2JsZW0gc2lu Y2UgdGhlcmUgaXMgYW4gaW5jcmVhc2luZyBib3RoIG51bWJlciBhbmQgdHlwZSBvZiBSUEtJIGRh dGEuDQoNClNpbmNlIFFVSUMgY2FuIHRvbGVyYXRlIHBhY2tldCBsb3NzIHRvIHNvbWUgZXh0ZW50 LCBJIGFtIHRyeWluZyB0byBsZXQgUlBTVElSIGNhbGwgUVVJQyBmb3IgdHJhbnNwb3J0LiANCg0K QmVzaWRlcywgUVVJQyBoYXMgZ290IGludHJpbnNpYyBzdXBwb3J0IG9mIFRMUyB3aGljaCBpcyBh bm90aGVyIGZlYXR1cmUgdGhhdCBSVFIgY291bGQgYmVuZWZpdCBmcm9tLg0KIA0KQW55IGJpZyBp ZGVhIG9yIHByYWN0aWNlIG9uIHRoaXMgcG9pbnQ/IFNoYWxsIHRoaXMgV0cgY29uc2lkZXIgc3Rh bmRhcmRpemluZyBSVFIgb3ZlciBRVUlDPw0KDQoNCkRpDQoNCiANCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTaWRyb3BzIG1haWxpbmcgbGlzdA0KU2lk cm9wc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRy b3BzDQo= From nobody Wed Aug 4 03:01:32 2021 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 BDBF93A11B1 for ; Wed, 4 Aug 2021 03:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.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 qxMpUzutSTYD for ; Wed, 4 Aug 2021 03:01:27 -0700 (PDT) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 B843B3A11AD for ; Wed, 4 Aug 2021 03:01:26 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id gs8so2818217ejc.13 for ; Wed, 04 Aug 2021 03:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=GJTY+LlzhUEBmhR99cBoi3W71mA3ZAlWI0rJcXfIjd0=; b=nH8nAhJFnpRXkAWzMT77UKHyQujMa5aiHX9cpuUJ7qB6lP+1M2fsR+6bpyJaegw6O/ 045STbn40cM4AcGDD0NXzu85i24cgjyCWN5/WnlaA5GxnLsTU5pnpGQ5H2ruj/H6ROzw BsJiPu4bFKR4PZQNwRzeMjWYo5ucyXTPkamgY= 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; bh=GJTY+LlzhUEBmhR99cBoi3W71mA3ZAlWI0rJcXfIjd0=; b=l2Y9VSl1MCu9OHmfHphZ/prUCSz4RvzCQd+kSMYoXq4ir38tpHgFRjEIgAJYSh4pU4 l2zZttLxphTkcPD/2Rf3j/rBI16RRyiS4WA9ZJFDFXZ+aIU5Fkfp0dcg2ODbPwuPn6pC bj6+RypWo0aJICHZgc5BGXHHwJucdA6x/H7RRrqdonF8lkN/ccd2TZx5qxDNJLKGW2nd xSD2CYJq1EA+1WuE2O7A6u1xIMnzzMKabZ8yGUI80T7i/QI1kQei0n/JhlFjH/qSPR+r NGCtKPujFfedyjezFaRuGSzVcViN+Ct3RtcLCz+qNGjI79rjml82DzwLmDQS8snqfE33 Mebw== X-Gm-Message-State: AOAM531EvQ9X1Z+EygKH/AaixIYtcUIhZFyF0V6g6vTv3x+eUGG9UXYE EN3eSV8IT908tS4VvOpfQ0DhIQ== X-Google-Smtp-Source: ABdhPJzv2a6W4grTuj5dsL9sF8Hau2i9ztCaplfgLE5Srma/c3EjQZBSh4UMHA+/tMK94biVPW5OLg== X-Received: by 2002:a17:906:9c84:: with SMTP id fj4mr24808320ejc.274.1628071284058; Wed, 04 Aug 2021 03:01:24 -0700 (PDT) Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id j24sm738619edp.44.2021.08.04.03.01.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Aug 2021 03:01:23 -0700 (PDT) Date: Wed, 4 Aug 2021 12:01:22 +0200 From: Job Snijders To: Di Ma Cc: SIDR Operations WG Message-ID: References: <7C44766F-CB65-41D1-BF9E-A8A1E54B2093@rpstir.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C44766F-CB65-41D1-BF9E-A8A1E54B2093@rpstir.net> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] RTR over QUIC X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 10:01:32 -0000 On Wed, Aug 04, 2021 at 04:47:04PM +0800, Di Ma wrote: > I am recently exploring to improve RTR. > > As we test our RP implementation, RTR would start over in case of just > one piece of wrong PDU, which is more remarkably observed when a > router is downloading the full copy from RTR server. I think this > could be a problem since there is an increasing both number and type > of RPKI data. RTR clients are fully expected to terminate the RTR session when a corrupted PDU is received from the server. > Since QUIC can tolerate packet loss to some extent, I am trying to let > RPSTIR call QUIC for transport. But TCP (and SSH) can also tolerate packet loss? > Besides, QUIC has got intrinsic support of TLS which is another > feature that RTR could benefit from. > > Any big idea or practice on this point? Shall this WG consider > standardizing RTR over QUIC? There already is: * RTR over SSH * RTR over TLS * RTR over TCP-MD5 * RTR over TCP-AO I am not sure how adding QUIC to the list will materially improve things. It would introduce additional fragmentation in the ecosystem. With this many RTR transport options available, it appears the industry is not converging on a single mechanism, which harms interopability. The table overview at https://datatracker.ietf.org/doc/html/rfc7128#section-5 is an indication there already are too many standards. Promoting "RTR over SSH" to be the default transport, supported by all platforms would be my preference. Kind regards, Job From nobody Wed Aug 4 04:48:45 2021 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 95C633A1581 for ; Wed, 4 Aug 2021 04:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 z9IibUpESjR1 for ; Wed, 4 Aug 2021 04:48:39 -0700 (PDT) Received: from out20-15.mail.aliyun.com (out20-15.mail.aliyun.com [115.124.20.15]) (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 521753A1587 for ; Wed, 4 Aug 2021 04:48:35 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.2991534|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.21064-0.00308783-0.786273; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047211; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.KvH40Oo_1628077709; Received: from smtpclient.apple(mailfrom:madi@rpstir.net fp:SMTPD_---.KvH40Oo_1628077709) by smtp.aliyun-inc.com(10.147.44.129); Wed, 04 Aug 2021 19:48:29 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Di Ma In-Reply-To: <0db4510ab252453384fb3d91adaf6aa9@huawei.com> Date: Wed, 4 Aug 2021 19:48:28 +0800 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C44766F-CB65-41D1-BF9E-A8A1E54B2093@rpstir.net> <0db4510ab252453384fb3d91adaf6aa9@huawei.com> To: Chenshuanglong X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Sidrops] RTR over QUIC X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 11:48:45 -0000 Shuanglong, > 2021=E5=B9=B48=E6=9C=884=E6=97=A5 17:22=EF=BC=8CChenshuanglong = =E5=86=99=E9=81=93=EF=BC=9A >=20 > Hi Di=EF=BC=8C >=20 > We are also exploring the feasibility of BGP over QUIC, and I think = both BGP over QUIC and RTR over QUIC are technically feasible. Glad to know Huawei as a vendor=E2=80=99s interest in QUIC support for = routers. Should Huawei's router has got support of QUIC, then we would have = chance to have a test of RTR over QUIC. Di=20 From nobody Wed Aug 4 05:07:03 2021 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 C543E3A1521 for ; Wed, 4 Aug 2021 05:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ZPhQp4cnbkFd for ; Wed, 4 Aug 2021 05:06:58 -0700 (PDT) Received: from out20-73.mail.aliyun.com (out20-73.mail.aliyun.com [115.124.20.73]) (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 CB5D13A167B for ; Wed, 4 Aug 2021 05:06:56 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.1329882|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.0847081-0.00294046-0.912351; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047202; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.KvHHnWe_1628078810; Received: from smtpclient.apple(mailfrom:madi@rpstir.net fp:SMTPD_---.KvHHnWe_1628078810) by smtp.aliyun-inc.com(10.147.40.233); Wed, 04 Aug 2021 20:06:51 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Di Ma In-Reply-To: Date: Wed, 4 Aug 2021 20:06:50 +0800 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C44766F-CB65-41D1-BF9E-A8A1E54B2093@rpstir.net> To: Job Snijders X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Sidrops] RTR over QUIC X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 12:07:02 -0000 Job, > 2021=E5=B9=B48=E6=9C=884=E6=97=A5 18:01=EF=BC=8CJob Snijders = =E5=86=99=E9=81=93=EF=BC=9A >=20 > On Wed, Aug 04, 2021 at 04:47:04PM +0800, Di Ma wrote: >> I am recently exploring to improve RTR. >>=20 >> As we test our RP implementation, RTR would start over in case of = just >> one piece of wrong PDU, which is more remarkably observed when a >> router is downloading the full copy from RTR server. I think this >> could be a problem since there is an increasing both number and type >> of RPKI data. >=20 > RTR clients are fully expected to terminate the RTR session when a > corrupted PDU is received from the server. Yes.=20 Granted, the RTR client has to start over for all the PDUs, instead of = pursuing an incremental from where it finds this corrupted one. Di From nobody Wed Aug 4 05:09:39 2021 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 7CA753A169B for ; Wed, 4 Aug 2021 05:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isyj2ZifHUSg for ; Wed, 4 Aug 2021 05:09:33 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15253A16A0 for ; Wed, 4 Aug 2021 05:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=t4Cm2FiSRNR8D0L7AS5k7TQXsy4i8QF+/XV6yI3FJfA=; b=GP06LuIjdovepX77Yxi/LIPF CDwYq1p6V2vFBl644fAPjnWOUsylloEPetiW3xxP8HoOk/iB8SoNgPBVp9HLYx04J9WCw1IWTAZYA u3u4V66gGbZKZANUj61AH0WJx4nxzmAq8B8ZhhogWOYaZmV81xufqGaxlvmalUyyOx/XUzgpLc7DG bR8ISspw3GtLi672bCo/LT1R0baRmUUYpZrSqaD19Qz+74wHgRYA0XSxmTTb2hPflTcJ96lXaJPGI JTbwD4A7qPqPFsOs8gxU7wStQwQKWUObmQf2uCMP65Imlg5KqV07veMZqWL2eczlOb28tNqfMnmIN 9t+YpGMmwQ==; Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:56800) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mBFiB-0005aa-5e; Wed, 04 Aug 2021 14:09:27 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mBFiB-0005Oe-2Q; Wed, 04 Aug 2021 14:09:27 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Ties de Kock In-Reply-To: Date: Wed, 4 Aug 2021 14:09:26 +0200 Cc: Job Snijders , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <5EEF71A2-11E4-4FAE-8E7F-CBA29330593D@ripe.net> References: <7C44766F-CB65-41D1-BF9E-A8A1E54B2093@rpstir.net> To: Di Ma X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e16d1a3588556a3b00a694bcc87744b795 Archived-At: Subject: Re: [Sidrops] RTR over QUIC X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 12:09:38 -0000 Di, > On 4 Aug 2021, at 14:06, Di Ma wrote: >=20 > Job, >=20 >> 2021=E5=B9=B48=E6=9C=884=E6=97=A5 18:01=EF=BC=8CJob Snijders = =E5=86=99=E9=81=93=EF=BC=9A >>=20 >> On Wed, Aug 04, 2021 at 04:47:04PM +0800, Di Ma wrote: >>> I am recently exploring to improve RTR. >>>=20 >>> As we test our RP implementation, RTR would start over in case of = just >>> one piece of wrong PDU, which is more remarkably observed when a >>> router is downloading the full copy from RTR server. I think this >>> could be a problem since there is an increasing both number and type >>> of RPKI data. >>=20 >> RTR clients are fully expected to terminate the RTR session when a >> corrupted PDU is received from the server. >=20 > Yes.=20 >=20 > Granted, the RTR client has to start over for all the PDUs, instead of = pursuing an incremental from where it finds this corrupted one. How would you inject an invalid PDU in a TCP, RTR-over-TLS or = RTR-over-SSH stream? I think that an on-path attacker can always force the connection to = reset - even with QUIC. Kind regards, Ties= From nobody Wed Aug 4 18:43:27 2021 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 D7E5F3A0EEB for ; Wed, 4 Aug 2021 18:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DR3VxD4KUfjW for ; Wed, 4 Aug 2021 18:43:23 -0700 (PDT) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB9A3A0EEA for ; Wed, 4 Aug 2021 18:43:23 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-73-100-88-186.hsd1.ma.comcast.net [73.100.88.186]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 3A12B27305; Thu, 5 Aug 2021 01:43:22 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 2EE982EA00C8; Wed, 4 Aug 2021 21:43:21 -0400 (EDT) Date: Wed, 04 Aug 2021 21:43:21 -0400 From: Rob Austein To: Tim Bruijnzeels Cc: SIDR Operations WG In-Reply-To: <810C485C-EAA4-481A-867D-111D0630D723@nlnetlabs.nl> References: <810C485C-EAA4-481A-867D-111D0630D723@nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Message-Id: <20210805014321.2EE982EA00C8@minas-ithil.hactrn.net> Archived-At: Subject: Re: [Sidrops] Do ALL CA implementers include ALL *current* certificates in the "Resource Class List Response"? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 01:43:25 -0000 On Wed, 04 Aug 2021 04:24:45 -0400, Tim Bruijnzeels wrote: ... > I am looking for clarity on RFC 6492 section 3.3.2: The provisioning > protocol "Resource Class List Response". > > This response payload includes information on resource and validity > time entitlements for a child CA, as well as a list of current > certificates. My issue is that I cannot find a normative "MUST" that > says that the parent CA MUST include any and all current certificate > for each of the child CA's keys. I believe that this is the > intention, but I cannot assume now that every parent CA in fact does > this. Um, the section you cite explicitly says otherwise: Where the issuer has issued multiple certificates in a resource class signed with different keys (as may occur during a staged issuer-key rollover), only the most recent certificate issued with the currently "active" issuer's key is to be listed in the response. As to what my (elderly) implementation does, we return any certs which: a) Are marked "active", and b) Have some resource overlap with what the back-end database says this child should have. For grotty details, see https://github.com/dragonresearch/rpki.net/blob/master/rpki/rpkidb/models.py#L1669 From nobody Sun Aug 8 13:00:46 2021 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 5F7AE3A14D6; Sun, 8 Aug 2021 13:00:40 -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: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <162845284032.8200.10136537682451303583@ietfa.amsl.com> Date: Sun, 08 Aug 2021 13:00:40 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rov-timing-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2021 20:00:41 -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 : Timing Parameters in the RPKI based Route Origin Validation Supply Chain Authors : Randy Bush Jay Borkenhagen Tim Bruijnzeels Job Snijders Filename : draft-ietf-sidrops-rpki-rov-timing-04.txt Pages : 8 Date : 2021-08-08 Abstract: This document explores, and makes recommendations for, timing of Resource Public Key Infrastructure publication of ROV data, their propagation, and their use in Relying Parties and routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-rov-timing/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rov-timing-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpki-rov-timing-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Aug 8 13:03:40 2021 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 CE3563A14EE for ; Sun, 8 Aug 2021 13:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrmCsTMC_b3I for ; Sun, 8 Aug 2021 13:03:33 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 BD05E3A14EB for ; Sun, 8 Aug 2021 13:03:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mCp19-00021C-4N for sidrops@ietf.org; Sun, 08 Aug 2021 20:03:31 +0000 Date: Sun, 08 Aug 2021 13:03:30 -0700 Message-ID: From: Randy Bush To: SIDR Operations WG In-Reply-To: <162845284032.8200.10136537682451303583@ietfa.amsl.com> References: <162845284032.8200.10136537682451303583@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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] I-D Action: draft-ietf-sidrops-rpki-rov-timing-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 08 Aug 2021 20:03:39 -0000 small tweaks and wording consistency. we would like to request wglc, but it would be good if folk could give it a read before we do so. thanks. randy From nobody Sun Aug 8 13:38:21 2021 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 741143A1636; Sun, 8 Aug 2021 13:38:19 -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: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <162845509942.28236.7404410032742481217@ietfa.amsl.com> Date: Sun, 08 Aug 2021 13:38:19 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-has-no-identity-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2021 20:38:20 -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 : The I in RPKI does not stand for Identity Authors : Randy Bush Russ Housley Filename : draft-ietf-sidrops-rpki-has-no-identity-01.txt Pages : 7 Date : 2021-08-08 Abstract: There is a false notion that Internet Number Resources (INRs) in the RPKI can be associated with the real world identity of the 'owner' of an INR. This document attempts to put that notion to rest. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-has-no-identity/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-has-no-identity-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpki-has-no-identity-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Aug 8 13:44:08 2021 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 49E6F3A1671 for ; Sun, 8 Aug 2021 13:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBYWVaZnAIUf for ; Sun, 8 Aug 2021 13:44:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 0B2833A1670 for ; Sun, 8 Aug 2021 13:44:02 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mCpeK-00029x-HI for sidrops@ietf.org; Sun, 08 Aug 2021 20:44:00 +0000 Date: Sun, 08 Aug 2021 13:43:59 -0700 Message-ID: From: Randy Bush To: SIDR Operations WG In-Reply-To: <162845509942.28236.7404410032742481217@ietfa.amsl.com> References: <162845509942.28236.7404410032742481217@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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] I-D Action: draft-ietf-sidrops-rpki-has-no-identity-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 08 Aug 2021 20:44:07 -0000 my (always suspect) memory on this one is that, when it was first published, there was a lot of discussion exacerbated by some lack of clarity. this was cleaned up when we made clear that we were not attacking RTA or RSC, only warning of potential misuse. so it was adopted as a wg document. are we bored enough with it to wglc it? randy From nobody Mon Aug 9 00:58:39 2021 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 318B33A07AA for ; Mon, 9 Aug 2021 00:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuwaJMXFDncs for ; Mon, 9 Aug 2021 00:58:31 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085473A07A5 for ; Mon, 9 Aug 2021 00:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=weRvQoX7f+QuEs0wZlIGBM/cGP1IX+HGjXR2wO+CeMQ=; b=EZ+6KZ6UBqKyfe1rrmgzcq1R 4uhN0pJCzZhxqst4HpR32IdUHCqTy1jiQWvgI1lXXawse2Ac1MGsfTk3F3be7X/NOmethVg2qvob9 yTaB859NE94Dk4MzlDrfQr/X5A1y2DwtfTs8HpkAk37OXocY6puUkU0WLOn++UQlXru1k+QGrM9mM rmZn/soBsDXyOxWUM2HVfungb9nh+HVCwofBgD078Aj5QJWINMxib8kH70v4vQyPy0a5BVb/raFRC c1++c+7qji+MvAEphhlkfgHP3LNigaNjewyWytxx6LQE6zqdqxUZXzY6h06xTJXKh0kRmkPCtU6go +bBH4+6N3g==; Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:42326) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mD0B1-000AbX-OB; Mon, 09 Aug 2021 09:58:27 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mD0B1-0008Gf-LX; Mon, 09 Aug 2021 09:58:27 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Ties de Kock In-Reply-To: Date: Mon, 9 Aug 2021 09:58:27 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <76BFDB10-2FE5-4FBD-8E16-8104CBE3D86C@ripe.net> References: <162845509942.28236.7404410032742481217@ietfa.amsl.com> To: Randy Bush X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1e5d51f837634f2029fddda5063684f02 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-has-no-identity-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 09 Aug 2021 07:58:37 -0000 Hi Randy, > On 8 Aug 2021, at 22:43, Randy Bush wrote: >=20 > my (always suspect) memory on this one is that, when it was first > published, there was a lot of discussion exacerbated by some lack of > clarity. this was cleaned up when we made clear that we were not > attacking RTA or RSC, only warning of potential misuse. so it was > adopted as a wg document. First of all: I like the draft and it demonstrates some problem with = using the RPKI for external attestations really well. > In large organizations, INR management is often compartmentalized > with no authority over anything beyond dealing with INR registration. > The INR manager for Bill's Bait and Sushi is unlikely to be > authorized to conduct bank transactions for BB&S, or even to > authorize access to BB&S's servers in some colocation facility. About this paragraph: This may even need to be more specific. I think that the department performing INR _management_ often may not = even have legal authority to change INR _registration_s. I imagine a department = that can change the data related to the INR registration (=E2=80=9Cupdate the = ROAs=E2=80=9D) but not manage the INR registration (=E2=80=9Cgarage sale of the IPv4=E2=80=9D). For the latter you (hopefully) need legal signing power. Kind regards, Ties= From nobody Mon Aug 9 12:41:36 2021 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 CBF053A148F for ; Mon, 9 Aug 2021 12:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJtNBTl2TNmO for ; Mon, 9 Aug 2021 12:41:22 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 BD4D53A1481 for ; Mon, 9 Aug 2021 12:41:21 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mDB9D-00071c-4P; Mon, 09 Aug 2021 19:41:19 +0000 Date: Mon, 09 Aug 2021 12:41:18 -0700 Message-ID: From: Randy Bush To: Ties de Kock Cc: SIDR Operations WG In-Reply-To: <76BFDB10-2FE5-4FBD-8E16-8104CBE3D86C@ripe.net> References: <162845509942.28236.7404410032742481217@ietfa.amsl.com> <76BFDB10-2FE5-4FBD-8E16-8104CBE3D86C@ripe.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-has-no-identity-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 09 Aug 2021 19:41:35 -0000 >> In large organizations, INR management is often compartmentalized >> with no authority over anything beyond dealing with INR registration. >> The INR manager for Bill's Bait and Sushi is unlikely to be >> authorized to conduct bank transactions for BB&S, or even to >> authorize access to BB&S's servers in some colocation facility. > > About this paragraph: This may even need to be more specific. > > I think that the department performing INR _management_ often may not > even have legal authority to change INR _registration_s. I imagine a > department that can change the data related to the INR registration > (“update the ROAs”) but not manage the INR registration (“garage sale > of the IPv4”). > > For the latter you (hopefully) need legal signing power. yes, but ... i do not see where rsc/mta/... and folk wanting to sign bank statements with registry data are asking to change the registry database. clue bat, please. randy From nobody Tue Aug 10 06:35:05 2021 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 05D9B3A0A7E for ; Tue, 10 Aug 2021 06:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSlriFZkBHvv for ; Tue, 10 Aug 2021 06:34:58 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E743A0A88 for ; Tue, 10 Aug 2021 06:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=LNfOrOUSErve4bUbK5HcIHEL8mgpJ+m68DMJeAge9dA=; b=ll2EjdENvk0aqD/6EwdF/HPE PopuH5icaOdtWuTGfcbasrYtdPTr5SWwrU0t6NQEwsFPqvaozUiYoDjrMHWQgjgP2TgXHfQn871AM HrZ/ytn6ae79FAnN0NvMc144eCJ90GelUXjnwhhZHZDq7lz4bBBTwjEfPXSPn1IwUOwqyT1QrD/03 GrPYn7oYNBarRCS3M+oFYEuzfabC78KbDOzfQZDosXHN0jFsgWUIBdR7saLoc2h/De6NLeO4Ul0eU oEAvSf/ubymZQD6ay6YvJOUAjxrsebxl05RSLeGR0ZIibgipnAEGIPUcLP3FwRmK18eI9HWbjPtzr ReLp1njt2g==; Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:40410) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mDRu5-0006Ck-He; Tue, 10 Aug 2021 15:34:49 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mDRu5-0000d7-EM; Tue, 10 Aug 2021 15:34:49 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Ties de Kock In-Reply-To: Date: Tue, 10 Aug 2021 15:34:49 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <8170EFA9-8832-4B7A-816D-9829790C23FA@ripe.net> References: <162845509942.28236.7404410032742481217@ietfa.amsl.com> <76BFDB10-2FE5-4FBD-8E16-8104CBE3D86C@ripe.net> To: Randy Bush X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e14d60464cadbb85b8b7ac57ed3ff1844c Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-has-no-identity-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 13:35:04 -0000 > On 9 Aug 2021, at 21:41, Randy Bush wrote: >=20 >>> In large organizations, INR management is often compartmentalized >>> with no authority over anything beyond dealing with INR = registration. >>> The INR manager for Bill's Bait and Sushi is unlikely to be >>> authorized to conduct bank transactions for BB&S, or even to >>> authorize access to BB&S's servers in some colocation facility. >>=20 >> About this paragraph: This may even need to be more specific. >>=20 >> I think that the department performing INR _management_ often may not >> even have legal authority to change INR _registration_s. I imagine a >> department that can change the data related to the INR registration >> (=E2=80=9Cupdate the ROAs=E2=80=9D) but not manage the INR = registration (=E2=80=9Cgarage sale >> of the IPv4=E2=80=9D). >>=20 >> For the latter you (hopefully) need legal signing power. >=20 > yes, but ... >=20 > i do not see where rsc/mta/... and folk wanting to sign bank = statements > with registry data are asking to change the registry database. clue > bat, please. >=20 > randy I was thinking about the situation where an actor uses an RPKI object to = lead people to believe they have legal authority to sign contracts concerning = the resources. RPKI does not have identity but it does not imply being an legal = representative either? I was wondering if we needed to clarify that as well. -Ties= From nobody Tue Aug 10 20:36:19 2021 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 C1C6C3A0EC0 for ; Tue, 10 Aug 2021 20:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJceal-gXP-C for ; Tue, 10 Aug 2021 20:36:15 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 5689B3A0EC2 for ; Tue, 10 Aug 2021 20:36:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mDf2H-0005zZ-E8; Wed, 11 Aug 2021 03:36:10 +0000 Date: Tue, 10 Aug 2021 20:36:08 -0700 Message-ID: From: Randy Bush To: Ties de Kock Cc: SIDR Operations WG In-Reply-To: <8170EFA9-8832-4B7A-816D-9829790C23FA@ripe.net> References: <162845509942.28236.7404410032742481217@ietfa.amsl.com> <76BFDB10-2FE5-4FBD-8E16-8104CBE3D86C@ripe.net> <8170EFA9-8832-4B7A-816D-9829790C23FA@ripe.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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] I-D Action: draft-ietf-sidrops-rpki-has-no-identity-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 03:36:17 -0000 > I was thinking about the situation where an actor uses an RPKI object > to lead people to believe they have legal authority to sign contracts > concerning the resources. > > RPKI does not have identity but it does not imply being an legal > representative either? I was wondering if we needed to clarify that as > well. so you want something such as That someone can provide 'proof of possession' of the private key signing over a particular INR should not be taken to imply that they are a valid legal representative of the organization in possession of that INR. They could be just an INR administrative person. randy From nobody Wed Aug 11 00:19:29 2021 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 422553A0112 for ; Wed, 11 Aug 2021 00:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2-ojd239tuj for ; Wed, 11 Aug 2021 00:19:20 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164BA3A011F for ; Wed, 11 Aug 2021 00:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=Lst3BluX/maOfJhbSPVmWoLidbq0Kyo5PPUwd18ZRyw=; b=httEE7eZc9kbyZTLDSoHqaM8 1n1jn8TO+ANTkauViwm2/IRWVRXfI2TNTYU2pcYdi5yUYrLf1FsuV+ZbVdsTi45GXsIB7P2JeTfBO Pg1cxTisJcpWlzp+rr/zIP8mT28Dsa6W+ovEwMl3DBU8G/IfYU/He6QsWvge4zX/spnA2hkepe/Y2 Od64zhjgY09q4rLYM1iVKC3068O6hCSMspWSHwvf5gMIGqOzqQKM6JaYlsOrJi7VhtzsJiMj5o6tx J7RPf4ATt/1Q9/mqHpjBmFfFg6zKhMTgSszvpzLK8ALGBBb/uF67AGNDmG1FJT3xuuj9uyy1wAuWm NZCX0cJoIg==; Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:38998) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mDiW8-0002Zt-A2; Wed, 11 Aug 2021 09:19:12 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mDiW8-0002z8-7J; Wed, 11 Aug 2021 09:19:12 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Ties de Kock In-Reply-To: Date: Wed, 11 Aug 2021 09:19:11 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: 7bit Message-Id: <9727EFC1-D132-4E25-B2F0-7852C67766E2@ripe.net> References: <162845509942.28236.7404410032742481217@ietfa.amsl.com> <76BFDB10-2FE5-4FBD-8E16-8104CBE3D86C@ripe.net> <8170EFA9-8832-4B7A-816D-9829790C23FA@ripe.net> To: Randy Bush X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1b6df362ba33711cb631c8c62476da976 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-has-no-identity-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 07:19:27 -0000 On 11 Aug 2021, at 05:36, Randy Bush wrote: > >> I was thinking about the situation where an actor uses an RPKI object >> to lead people to believe they have legal authority to sign contracts >> concerning the resources. >> >> RPKI does not have identity but it does not imply being an legal >> representative either? I was wondering if we needed to clarify that as >> well. > > so you want something such as > > That someone can provide 'proof of possession' of the private key > signing over a particular INR should not be taken to imply that they > are a valid legal representative of the organization in possession > of that INR. They could be just an INR administrative person. I think that looks good! -Ties > > randy > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Aug 11 09:11:22 2021 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 BED9D3A1B6B; Wed, 11 Aug 2021 09:11:20 -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: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <162869828068.32024.16676672787854053360@ietfa.amsl.com> Date: Wed, 11 Aug 2021 09:11:20 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rsc-05.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 16:11:21 -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) object profile for Signed Checklist (RSC) Authors : Job Snijders Tom Harrison Ben Maddison Filename : draft-ietf-sidrops-rpki-rsc-05.txt Pages : 14 Date : 2021-08-11 Abstract: This document defines a Cryptographic Message Syntax (CMS) profile for a general purpose listing of checksums (a 'checklist'), for use with the Resource Public Key Infrastructure (RPKI). The objective is to allow an attestation, in the form of a listing of one or more checksums of arbitrary digital objects (files), to be signed "with resources", and for validation to provide a means to confirm a specific Internet Resource Holder produced the Signed Checklist. The profile is intended to provide for the signing of an arbitrary checksum listing with a specific set of Internet Number Resources. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-rsc/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-rsc-05.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpki-rsc-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Aug 15 09:50:00 2021 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 5E9AB3A1C44; Sun, 15 Aug 2021 09:49:54 -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: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <162904619434.14259.6901716058517754664@ietfa.amsl.com> Date: Sun, 15 Aug 2021 09:49:54 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-8210bis-03.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 16:49:55 -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 : The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2 Authors : Randy Bush Rob Austein Filename : draft-ietf-sidrops-8210bis-03.txt Pages : 38 Date : 2021-08-15 Abstract: In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. RFC 6810 describes version 0, and RFC 8210 describes version 1. This document updates RFC 8210. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-8210bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-8210bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-8210bis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 16 00:20:10 2021 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 D2C2D3A1BD8; Mon, 16 Aug 2021 00:20:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: nathalie@ripe.net, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162909840698.4820.6389057404480438070@ietfa.amsl.com> Date: Mon, 16 Aug 2021 00:20:07 -0700 Archived-At: Subject: [Sidrops] sidrops - New Meeting Session Request for IETF 112 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 07:20:08 -0000 A new meeting session request has just been submitted by Nathalie Trenaman, a Secretary of the sidrops working group. --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Nathalie Trenaman Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 70 Conflicts to Avoid: People who must be present: Keyur Patel Chris Morrow Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Aug 16 04:31:18 2021 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 118633A0835; Mon, 16 Aug 2021 04:31:13 -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: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <162911347300.23549.10489175833993571707@ietfa.amsl.com> Date: Mon, 16 Aug 2021 04:31:13 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rov-timing-05.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 11:31:13 -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 : Timing Parameters in the RPKI based Route Origin Validation Supply Chain Authors : Randy Bush Jay Borkenhagen Tim Bruijnzeels Job Snijders Filename : draft-ietf-sidrops-rpki-rov-timing-05.txt Pages : 9 Date : 2021-08-16 Abstract: This document explores, and makes recommendations for, timing of Resource Public Key Infrastructure publication of ROV data, their propagation, and their use in Relying Parties and routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-rov-timing/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rov-timing-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpki-rov-timing-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 16 04:39:38 2021 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 CE93D3A08CF; Mon, 16 Aug 2021 04:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ltm1iy5D8b2z; Mon, 16 Aug 2021 04:39:35 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 1450B3A08CC; Mon, 16 Aug 2021 04:39:35 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mFaxo-0005UX-Ov; Mon, 16 Aug 2021 11:39:32 +0000 Date: Mon, 16 Aug 2021 04:39:31 -0700 Message-ID: From: Randy Bush To: sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net, nathalie@ripe.net In-Reply-To: <162909840698.4820.6389057404480438070@ietfa.amsl.com> References: <162909840698.4820.6389057404480438070@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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] sidrops - New Meeting Session Request for IETF 112 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 11:39:37 -0000 > Conflicts to Avoid: idr grow opsawg From nobody Mon Aug 16 04:43:14 2021 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 285DA3A092F for ; Mon, 16 Aug 2021 04:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8bHc8lglVVx for ; Mon, 16 Aug 2021 04:42:55 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 DF4483A097A for ; Mon, 16 Aug 2021 04:42:54 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mFb11-0005VS-Rw for sidrops@ietf.org; Mon, 16 Aug 2021 11:42:52 +0000 Date: Mon, 16 Aug 2021 04:42:51 -0700 Message-ID: From: Randy Bush To: SIDR Operations WG In-Reply-To: <162911347300.23549.10489175833993571707@ietfa.amsl.com> References: <162911347300.23549.10489175833993571707@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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] I-D Action: draft-ietf-sidrops-rpki-rov-timing-05.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 11:43:08 -0000 after a few weeks of discussion among authors and kind suggestions by folk such as ties de kock, ... > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpki-rov-timing-05 worth a read From nobody Mon Aug 16 05:22:44 2021 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 8A4DC3A0C2F; Mon, 16 Aug 2021 05:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBQMU6qvQHdL; Mon, 16 Aug 2021 05:22:37 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450693A0C2E; Mon, 16 Aug 2021 05:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=QD7xF1fXQfPvgeq7DjqZcFjzNrBssyVqf3bdzeLvy8k=; b=OgVFpdMifd2fHybOZ2x9SbKZ ebxpjaDyQYt6rS1lOyAzHATCx/xzx2doGBVI9KB8RCC/ER8t4XN401UEWvrHimTq4x1pgArrOzWJ6 uPXMaGXpMVfhesiStDulH0QuRlvkhYGReu6PkbwLB3FWM2FmKuI5fi+9tWcCltyQ7GjFa/NgUkZAZ DVMAX5UO3TtR63jLu0SYM/+MsoySznge4vnHDsNJOLqScnWIvhGlJ5AnsR52cL0CmVL2fA5tu5/Wo rsBD2CKrw7TKvY7KZ3koApDLIa/LSO9Qsk5PNChjiCDqTW/gUd0H/Jhgx61m1TCxVNjty+bOCRQIC DGzLYl1hBA==; Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:39658) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mFbdP-00091C-CU; Mon, 16 Aug 2021 14:22:31 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mFbdP-00038P-9R; Mon, 16 Aug 2021 14:22:31 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Nathalie Trenaman In-Reply-To: Date: Mon, 16 Aug 2021 14:22:30 +0200 Cc: sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <162909840698.4820.6389057404480438070@ietfa.amsl.com> To: Randy Bush X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a121a0a28b6b808fe3553bf8e1b35817f Archived-At: Subject: Re: [Sidrops] sidrops - New Meeting Session Request for IETF 112 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 12:22:43 -0000 > Op 16 aug. 2021, om 13:39 heeft Randy Bush het = volgende geschreven: >=20 >> Conflicts to Avoid:=20 >=20 > idr > grow > opsawg Yep, doesn=E2=80=99t show in the output, but is in the input. I have a = screenshot as evidence ;) Nathalie= From nobody Tue Aug 24 15:12:30 2021 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 F3B5B3A1613; Tue, 24 Aug 2021 15:12:16 -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: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <162984313683.28325.15276501839622948944@ietfa.amsl.com> Date: Tue, 24 Aug 2021 15:12:16 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpkimaxlen-07.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 22:12: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 : The Use of Maxlength in the RPKI Authors : Yossi Gilad Sharon Goldberg Kotikalapudi Sriram Job Snijders Ben Maddison Filename : draft-ietf-sidrops-rpkimaxlen-07.txt Pages : 13 Date : 2021-08-24 Abstract: This document recommends ways to reduce forged-origin hijack attack surface by prudently limiting the set of IP prefixes that are included in a Route Origin Authorization (ROA). One recommendation is to avoid using the maxLength attribute in ROAs except in some specific cases. The recommendations complement and extend those in RFC 7115. The document also discusses creation of ROAs for facilitating the use of Distributed Denial of Service (DDoS) mitigation services. Considerations related to ROAs and origin validation in the context of destination-based Remote Triggered Black Hole (RTBH) filtering are also highlighted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpkimaxlen/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpkimaxlen-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpkimaxlen-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 25 14:12:55 2021 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 627A73A1058; Wed, 25 Aug 2021 14:12:45 -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: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <162992596529.24798.5873690532394887967@ietfa.amsl.com> Date: Wed, 25 Aug 2021 14:12:45 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-08.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 21:12:46 -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 : Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization Authors : Alexander Azimov Eugene Bogomazov Randy Bush Keyur Patel Job Snijders Filename : draft-ietf-sidrops-aspa-verification-08.txt Pages : 15 Date : 2021-08-25 Abstract: This document defines the semantics of an Autonomous System Provider Authorization object in the Resource Public Key Infrastructure to verify the AS_PATH attribute of routes advertised in the Border Gateway Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-aspa-verification-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/