IETF Logo Mail Archive

[Sidrops] Bug Fix Validator 3

Nathalie Trenaman <nathalie@ripe.net> Mon, 16 December 2019 15:49 UTC

Return-Path: <nathalie@ripe.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 D98A2120020 for <sidrops@ietfa.amsl.com>; Mon, 16 Dec 2019 07:49:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_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 fjOq_-hjlDOP for <sidrops@ietfa.amsl.com>; Mon, 16 Dec 2019 07:49:34 -0800 (PST)
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 3D35D120047 for <sidrops@ietf.org>; Mon, 16 Dec 2019 07:49:34 -0800 (PST)
Received: from [193.0.23.13] (helo=bufobufo.ripe.net) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <nathalie@ripe.net>) id 1igscm-0000CI-QW for sidrops@ietf.org; Mon, 16 Dec 2019 16:49:32 +0100
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::2bb]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from <nathalie@ripe.net>) id 1igscm-0004wb-Nd for sidrops@ietf.org; Mon, 16 Dec 2019 16:49:32 +0100
From: Nathalie Trenaman <nathalie@ripe.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_2F5C5030-2E44-4957-ABE3-BC5EDC971900"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <A123A6B4-D07E-44A8-B997-CDE3964E52B7@ripe.net>
Date: Mon, 16 Dec 2019 16:49:32 +0100
To: SIDR Operations WG <sidrops@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-ACL-Warn: Delaying message
X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a05d9938775299da6042cf3addf16e96e
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/FtsJvRah9QEW8PeHqxB3JfF76TE>
Subject: [Sidrops] Bug Fix Validator 3
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: Mon, 16 Dec 2019 15:49:36 -0000

Hi all,

We have just released a bug fix version of our Validator 3.

You can find them here:

Centos7 - https://ftp.ripe.net/tools/rpki/validator3/prod/centos7/repo/rpki-validator-3.1-2019.12.16.15.18.18.noarch.rpm <https://ftp.ripe.net/tools/rpki/validator3/prod/centos7/repo/rpki-validator-3.1-2019.12.16.15.18.18.noarch.rpm>
Debian - https://ftp.ripe.net/tools/rpki/validator3/prod/deb/rpki-validator-3.1-2019.12.16.15.18.18.deb <https://ftp.ripe.net/tools/rpki/validator3/prod/deb/rpki-validator-3.1-2019.12.16.15.18.18.deb>
Generic build - https://ftp.ripe.net/tools/rpki/validator3/prod/generic/rpki-validator-3.1-2019.12.16.15.18.18-dist.tar.gz <https://ftp.ripe.net/tools/rpki/validator3/prod/generic/rpki-validator-3.1-2019.12.16.15.18.18-dist.tar.gz>

If you have yum repository configured, "yum install rpki-validator" will do the job.

This was an interesting bug - We always relied on the idea that serial numbers of manifest objects increase --- apparently all the Trust Anchors so far (except for some of the sub-repositories under APNIC) generated increasing serial numbers and it always worked. It looks like Krill doesn't do it, that's why Validator 3 doesn't always pick up the latest manifest and can use stale data. According to the RFC serial numbers don't have to increase, they just need to be different (the Krill implementation follows that RFC), so it was a bug on our side that is now fixed.

Thanks for bringing this up.

Nathalie Trenaman
RIPE NCC

v2.23.0 | Report a Bug | By Email