Re: [sidr] RPKI validator testing summary

Andrew Chi <achi@bbn.com> Tue, 06 December 2011 16:20 UTC

Return-Path: <achi@bbn.com>
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 E5C8D21F8BDE for <sidr@ietfa.amsl.com>; Tue, 6 Dec 2011 08:20:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.449
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbaK3FeC5CkJ for <sidr@ietfa.amsl.com>; Tue, 6 Dec 2011 08:20:08 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6D12021F8BDC for <sidr@ietf.org>; Tue, 6 Dec 2011 08:20:08 -0800 (PST)
Received: from dhcp89-089-139.bbn.com ([128.89.89.139]:51520 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <achi@bbn.com>) id 1RXxkR-000I20-Nm; Tue, 06 Dec 2011 11:20:03 -0500
Message-ID: <4EDE40B0.8090903@bbn.com>
Date: Tue, 06 Dec 2011 11:20:00 -0500
From: Andrew Chi <achi@bbn.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Randy Bush <randy@psg.com>
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>
In-Reply-To: <m2liqu8aw4.wl%randy@psg.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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: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 
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.

-Andrew