[Sidrops] The Horizontal INR Conflict-Detection Algorithm: Revealing INR Reallocation and Reauthorization in RPKI

Di Ma <madi@rpstir.net> Thu, 08 July 2021 06:37 UTC

Return-Path: <madi@rpstir.net>
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 2BEBE3A15CB for <sidrops@ietfa.amsl.com>; Wed, 7 Jul 2021 23:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 JdWUpL0rE9e6 for <sidrops@ietfa.amsl.com>; Wed, 7 Jul 2021 23:37:41 -0700 (PDT)
Received: from out20-147.mail.aliyun.com (out20-147.mail.aliyun.com [115.124.20.147]) (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 240853A15C6 for <sidrops@ietf.org>; Wed, 7 Jul 2021 23:37:39 -0700 (PDT)
X-Alimail-AntiSpam: AC=SUSPECT; BC=0.6462826|-1; BR=01201311R211b1; CH=blue; DM=|SUSPECT|false|; DS=CONTINUE|ham_social|0.188203-0.00478918-0.807008; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047202; MF=madi@rpstir.net; NM=1; PH=DS; RN=1; RT=1; SR=0; TI=SMTPD_---.Ke1jzlI_1625726254;
Received: from smtpclient.apple(mailfrom:madi@rpstir.net fp:SMTPD_---.Ke1jzlI_1625726254) by smtp.aliyun-inc.com(10.147.40.200); Thu, 08 Jul 2021 14:37:35 +0800
From: Di Ma <madi@rpstir.net>
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: <B4D367D5-0C95-4DBD-A956-ED84D3EFA4D4@rpstir.net>
Date: Thu, 08 Jul 2021 14:37:34 +0800
To: SIDR Operations WG <sidrops@ietf.org>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/UzCzWccvYkYYc3LTN9hgvWkrvvc>
Subject: [Sidrops] The Horizontal INR Conflict-Detection Algorithm: Revealing INR Reallocation and Reauthorization in RPKI
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jul 2021 06:37:46 -0000

Hi, folks,

My team has just got a paper published, which is about RPKI analysis.

The abstract of this paper is: 

Resource Public Key Infrastructure (RPKI) is a promising security enhancement to the Border Gateway Protocol, but it only requires the relying party (RP) to validate Internet Number Resource (INR) allocation or authorization relationships expressed in parent-child certificate pairs vertically. Therefore, conflicts in INR allocation and authorization may exist because of the limitations of the validation procedure of the RP software, in other words, certification authority malfunctions in issuing RPKI objects within a publication point cannot be detected by the RP. We develop a model of such conflicts and propose a horizontal INR conflict-detection algorithm with acceptable build time and query time. The proposed algorithm was tested on real-world RPKI data to identify actual and potential INR conflicts and its accurateness has been tried to be evaluated. This paper also discusses the deployment issues and the accuracy dependence about our algorithm design.

The full paper can be accessed via:

https://ieeexplore.ieee.org/document/9463976

Di