Re: [sidr] RPKI validator testing summary

Andrew Chi <> Tue, 06 December 2011 16:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5C8D21F8BDE for <>; Tue, 6 Dec 2011 08:20:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.449
X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JbaK3FeC5CkJ for <>; Tue, 6 Dec 2011 08:20:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6D12021F8BDC for <>; Tue, 6 Dec 2011 08:20:08 -0800 (PST)
Received: from ([]:51520 helo=[]) by with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <>) id 1RXxkR-000I20-Nm; Tue, 06 Dec 2011 11:20:03 -0500
Message-ID: <>
Date: Tue, 06 Dec 2011 11:20:00 -0500
From: Andrew Chi <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Randy Bush <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: sidr wg <>
Subject: Re: [sidr] RPKI validator testing summary
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Dec 2011 16:20:09 -0000

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 

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.