Re: [sidr] WGLC for draft-ietf-sidr-pfx-validate-06

Tim Bruijnzeels <tim@ripe.net> Fri, 29 June 2012 16:03 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 3E1A621F862A for <sidr@ietfa.amsl.com>; Fri, 29 Jun 2012 09:03:39 -0700 (PDT)
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 4ZuHLARauL-p for <sidr@ietfa.amsl.com>; Fri, 29 Jun 2012 09:03:38 -0700 (PDT)
Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 6719C21F859B for <sidr@ietf.org>; Fri, 29 Jun 2012 09:03:38 -0700 (PDT)
Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1SkdfT-0001xA-2m; Fri, 29 Jun 2012 18:03:36 +0200
Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-33.ripe.net) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1SkdfS-0005wE-Mn; Fri, 29 Jun 2012 18:03:34 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <m2vcia5ir6.wl%randy@psg.com>
Date: Fri, 29 Jun 2012 18:03:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E1C466D8-B8D8-464B-85B6-ABA4C140DC33@ripe.net>
References: <24B20D14B2CD29478C8D5D6E9CBB29F625F1340A@Hermes.columbia.ads.sparta.com> <AFAF174A-F3D0-4D5C-A375-D7C8D283E5CE@ripe.net> <27839AC4-30E4-4C02-A64E-EAAC6F8B58D4@ripe.net> <FE0B25DE-6166-4A46-9435-3A58DAA51BC2@cisco.com> <A13B6A1C-188D-4EE3-A182-8F0CD7A1A0FF@ripe.net> <m2vcia5ir6.wl%randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.1084)
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120629 clean
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_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: 784d7acfe6559f2a0b602ec6519a07194dc45b91c74a0713b5059d3c31ef02b6
Cc: sidr wg <sidr@ietf.org>
Subject: Re: [sidr] WGLC for draft-ietf-sidr-pfx-validate-06
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: Fri, 29 Jun 2012 16:03:39 -0000

Hi,

On 29 Jun 2012, at 15:51, Randy Bush wrote:

>> With inconsistencies I did not mean that the validated cache is out of date, which I agree, will always be there even if it could be minimised.
>> 
>> The inconsistencies I refer to are different in nature. It's that the snapshot that the RP tool got when it validated is in itself inconsistent: surplus or missing ROAs, or the hash of 1 or more ROAs doesn't match. Longer discussion omitted, but at this point the RP just doesn't know for certain what to do and guidance is needed. This is where *explicitly* stating a strong requirement, rather than leaving it implicit, in pfx-validate comes in..
> 
> would you like us to pull in the crucial paragraph from sec 6 of
> origin-ops?
> 
>   Like the DNS, the global RPKI presents only a loosely consistent
>   view, depending on timing, updating, fetching, etc.  Thus, one cache
>   or router may have different data about a particular prefix than
>   another cache or router.  There is no 'fix' for this, it is the
>   nature of distributed data with distributed caches.
> 

No, not exactly. I think it makes more sense to have this kind of guidance in an ops targeted document. Here I would just like to see it documented that the same kind of concerns raised with someone able to mess with the validated cache database (adding/removing records) apply to attacks or operational problems that happen before stuff goes into that database.

Addressing this to the best of our abilities in operations and relevant standards is another discussion. One that I would like to save for another thread, and which does not have to block pfx-validate as far as I am concerned.



Tim