Re: [Sidrops] rpki rp frequency

Job Snijders <job@ntt.net> Sat, 11 April 2020 22:35 UTC

Return-Path: <job@ntt.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 8076B3A1A32 for <sidrops@ietfa.amsl.com>; Sat, 11 Apr 2020 15:35:04 -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 SE9QDz8-1HFg for <sidrops@ietfa.amsl.com>; Sat, 11 Apr 2020 15:35:02 -0700 (PDT)
Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [204.2.238.64]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3AFA3A1A35 for <sidrops@ietf.org>; Sat, 11 Apr 2020 15:35:02 -0700 (PDT)
Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id E1D2D220181 for <sidrops@ietf.org>; Sat, 11 Apr 2020 22:35:00 +0000 (UTC)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 40E9927C0054 for <sidrops@ietf.org>; Sat, 11 Apr 2020 18:34:59 -0400 (EDT)
Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Sat, 11 Apr 2020 18:34:59 -0400
X-ME-Sender: <xms:EkaSXiv8Fi74s3f28ewx5CUMz0W82xH8kz4iEBHpp3AmPQbfXETYbw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrvdehgddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedflfhosgcuufhnihhjuggvrhhsfdcuoehjohgssehnthht rdhnvghtqeenucffohhmrghinheptgholhhotghluhgvrdhnvghtpdhpvggvrhhinhhgug gsrdgtohhmpdhgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehjohgsodhmvghsmhhtphgruhhthhhpvghrshhonhgrlh hithihqddutdegjeeludehkeegqddvfeeffeekfedvtddqjhhosgeppehnthhtrdhnvght sehsohgsohhrnhhoshhtrdhnvght
X-ME-Proxy: <xmx:EkaSXlqzKoI8U_CDIsLDJRiUhHvaBpNKspFTMmk7norEiZM1k5ZEMg> <xmx:EkaSXkEet17JMJfvBmcxwiC9i-bEtqK7PYMG21jTFnFmRG5tF1pQQQ> <xmx:EkaSXhENc_5Z3MyA1Y_VM01auTZQyTbJO0BoM926hMTHfHXGWeNByQ> <xmx:E0aSXnHUDV2s2bmsxWdqv6_JM4Ose61UuXUbvLTfaM_rGhSSLBeT5w>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 97D73C200A5; Sat, 11 Apr 2020 18:34:58 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-1104-g203475c-fmstable-20200408v2
Mime-Version: 1.0
Message-Id: <d7355fcf-9f96-4f96-8a23-ed7d1b097f43@www.fastmail.com>
In-Reply-To: <m2d08d3i2a.wl-randy@psg.com>
References: <m2d08d3i2a.wl-randy@psg.com>
Date: Sun, 12 Apr 2020 00:34:27 +0200
From: "Job Snijders" <job@ntt.net>
To: sidrops@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/mjiyjAN44zqL5HJuTK-gf9FWZYA>
Subject: Re: [Sidrops] rpki rp frequency
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: Sat, 11 Apr 2020 22:35:05 -0000

On Sat, Apr 11, 2020, at 22:04, Randy Bush wrote:
> how do we diagnose such things?

My approach would be just like most other BGP reachability issue? First step is to figure out the peer who'd you expect to carry the route to the global system. I think in the case of this experiment the relevant upstream might be AS 8283.

Luckily they have a public looking glass, we can see that their EBGP-in side rejects 2 routes from AS 47065 https://birdseye.coloclue.net/birdseye/app/routeservers/0/protocols/peer_AS47065_49DA60/routes It shows the route being rejected because of RPKI.

One could then go to https://www.peeringdb.com/asn/8283 for NOC contact info and other information. There we also see "filters facing peers are updated every 12 hours" - I suspect that coincidences in a specific way with the pace of the experiment.

Full disclosure: I was the architect of AS 8283's network automation system (https://github.com/coloclue/kees). One of my design choices was to not use RTR. Instead, the 'kees' system generated & distributes a configuration snippet to all routers and SIGHUPs the BGP process. The snippet contains all the RPKI VRPs. This process runs every few hours.

In the large RPKI deployments some people opted for a sort of tiered setup: a few validators at the top, and then a distribution mechanism to RTR servers, which then in turn distribute data via RTR to the BGP routers. I expect operators to pick different timers for publishing & fetching at each tier. I hope I can share more at a later point about such setups.

Some low-hanging fruit outside of IETF might be to introduce a new field to PeeringDB's datamodel where operators can self-declare what the "RPKI Delay" in their network roughly is. The "RPKI Delay" would be the maximum number of minutes that could lapse between a ROA becoming available for fetching at the publication point, to the moment the VRP is present on all routers, during normal operations.

Or perhaps a new RPKI Object profile is defined to message some operational parameters about the validation process policies an ASN operator applies? Some of the data elements in PeeringDB were put there only because there wasn't any other place to put it. 

Kind regards,

Job