Re: [sidr] RPKI validator testing summary

Tim Bruijnzeels <tim@ripe.net> Tue, 06 December 2011 16:55 UTC

Return-Path: <tim@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76BB21F8B0B for <sidr@ietfa.amsl.com>; Tue, 6 Dec 2011 08:55:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4OPK8TV-urP for <sidr@ietfa.amsl.com>; Tue, 6 Dec 2011 08:55:08 -0800 (PST)
Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 1986721F8AD8 for <sidr@ietf.org>; Tue, 6 Dec 2011 08:55:08 -0800 (PST)
Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1RXyIL-0006Xh-E0; Tue, 06 Dec 2011 17:55:06 +0100
Received: from timbru.vpn.ripe.net ([193.0.21.62]) by ayeaye.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1RXyIL-0001G6-86; Tue, 06 Dec 2011 17:55:05 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <4EDE40B0.8090903@bbn.com>
Date: Tue, 6 Dec 2011 17:55:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A6FEED2E-987B-4C81-8574-9646ED1C5CEF@ripe.net>
References: <4ED64E04.7030408@bbn.com> <E3871AC3-6960-433A-8A34-7F10087A7EC7@apnic.net> <E03612FA-E271-4243-AE29-858D242B91CE@apnic.net> <m2r50m8gk2.wl%randy@psg.com> <1BADD28A-5808-48BB-A85D-275ED141D2D8@apnic.net> <m2liqu8aw4.wl%randy@psg.com> <4EDE40B0.8090903@bbn.com>
To: Andrew Chi <achi@bbn.com>
X-Mailer: Apple Mail (2.1084)
X-RIPE-Spam-Level: ----
X-RIPE-Spam-Report: Spam Total Points: -4.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07195492d968e8de334a6b0419e369fa5068
Cc: sidr wg <sidr@ietf.org>
Subject: Re: [sidr] RPKI validator testing summary
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Dec 2011 16:55:09 -0000

On Dec 6, 2011, at 5:20 PM, Andrew Chi wrote:

> On 12/3/2011 12:47 AM, Randy Bush wrote:
>>>> so are you saying bottom up is just a no-go?
>>> I believe I am, in that by following the AIA pointers you may be lead
>>> to places that may not match your chosen trust anchors.
>>> This is particularly the case for those who want to set up local TAs
>>> as per some draft or another.
>> 
>> as at least one validation implementation, bbn, is bottom up, and was
>> done by clueful folk next to some draft or another, i suspect we need to
>> document this in a warning some place.
>> 
>> randy
> 
> BBN's validator does have both top-down and bottom-up capability (currently, both run by default).  This was intended to handle any future use cases where a child is somehow obtained before its parent. As it turns out, all use cases that we've tested so far only require top-down.  And the bottom-up capability only leads us to old, abandoned data.
> 
> Note that Local TA is unaffected; that "tree" is shallow, locally managed, and processed in a manner that doesn't require AIAs.
> 
> As others have mentioned, bottom-up introduces complexity with (1) stray AIA pointers, and (2) multiple issuers if AIAs must be strict.  We have a countermeasure for 1, and currently we aren't strict about 2.  But if no bottom-up use cases ever come up, we will default the BBN validator to run top-down only.



Our command line validator supports ad-hoc bottom-up validation at this time, meaning:
- it will follow the AIA pointers up to a self-signed cert, the FIRST rsync pointer is used.
- insist that the self-signed cert matches (one of) your chosen trust anchor(s)
- perform a top-down validation for this chain only

But it needs some work. We are thinking of this:
- from the next release of our validator we will start supporting doing top-down validation, and most importantly re-validation, as a background service
- when asked to do bottom-up validation (in a future release):
	- we check if we have seen an exact binary match for the object content from a previous top-down run
	- if not we follow pointers up and fetch missing certificates until we find a pointer to something in our cache
	- I would define a match as a CA certificate with the correct subject (matching issuer) and public key, publication point may differ
	- The big assumption here is that people use unique key pairs, but I should hope that's a safe bet


I think bottom-up validation has a use for manual validation of objects that disappeared from the rpki (but may still be valid). And possibly in future for other (non-sidr even) object types that an address holder may not necessarily want to publish in the global rpki, but send directly to any RP for validation instead. In that case, assuming a CMS is used with an embedded EE with an AIA pointer to the normal CA cert for this holder, it's just one hop up into the 'known territory'.


Tim