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

Randy Bush <randy@psg.com> Fri, 29 June 2012 19:36 UTC

Return-Path: <randy@psg.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 BA23B21F88B9 for <sidr@ietfa.amsl.com>; Fri, 29 Jun 2012 12:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level:
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 IqOqUle2xpL2 for <sidr@ietfa.amsl.com>; Fri, 29 Jun 2012 12:36:47 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 3D62621F88BA for <sidr@ietf.org>; Fri, 29 Jun 2012 12:36:47 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <randy@psg.com>) id 1Skgzl-000DUa-Q2; Fri, 29 Jun 2012 19:36:46 +0000
Date: Fri, 29 Jun 2012 09:36:44 -1000
Message-ID: <m28vf56hbn.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <AFAF174A-F3D0-4D5C-A375-D7C8D283E5CE@ripe.net>
References: <24B20D14B2CD29478C8D5D6E9CBB29F625F1340A@Hermes.columbia.ads.sparta.com> <AFAF174A-F3D0-4D5C-A375-D7C8D283E5CE@ripe.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
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 19:36:47 -0000

> Prefix validate assumes full knowledge of all applicable ROAs (or
> other sources of information if they are used) 

no, it can not.  there is no notion of global completeness in the RPKI,
only manifests to resist object removal attack.  from origin-ops

6.  Notes

   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.

   Operators should beware that RPKI caches are loosely synchronized,
   even within a single AS.  Thus, changes to the validity state of
   prefixes could be different within an operator's network.  In
   addition, there is no guaranteed interval from when an RPKI cache is
   updated to when that new information may be pushed or pulled into a
   set of routers via this protocol.  This may result in sudden shifts
   of traffic in the operator's network, until all of the routers in the
   AS have reached equilibrium with the validity state of prefixes
   reflected in all of the RPKI caches.

randy