Re: [sidr] RPKI <-> allocation consistency

Christopher Morrow <morrowc.lists@gmail.com> Thu, 30 August 2012 17:17 UTC

Return-Path: <christopher.morrow@gmail.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 40FD421F8540 for <sidr@ietfa.amsl.com>; Thu, 30 Aug 2012 10:17:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eb+HDYCT+B83 for <sidr@ietfa.amsl.com>; Thu, 30 Aug 2012 10:17:14 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5AA21F853E for <sidr@ietf.org>; Thu, 30 Aug 2012 10:17:14 -0700 (PDT)
Received: by vcbfo14 with SMTP id fo14so2586374vcb.31 for <sidr@ietf.org>; Thu, 30 Aug 2012 10:17:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ctMdfR8/MTfQwrvVrbSjcyHsRiO2BYw6ySWYHpSRafg=; b=slFp3ms8yVl8h7ykuLKoN1IOWXW/8pF9fM0DI3myC9p+oWSH6Xb1+thRFbdL0cPyPN AAkGqZDk9yZGJXwdOOI+GNFMapFY+Pyf7iyWXIvpzwg+Km6U2V0GcelZ+ZOueb5PCKfs a5PAqNnyzwoSPgux6Ne8eu4pdSioeHeQRJ1pXQvumE1ljx6jhM6kO33zgk9E3/+0B873 NA8XHnZX44daB0JEtuQeQGLXpXb67ekfVMMUD85StZ7mZnJgqn8DOs918pv/NUtcsUpW b3p651vE4uYtl2Ab1bbKxIhw9fLIvSn07lzdRpYxgTqYYLTnlaUBJkobudlKSW8sss/y cUBQ==
MIME-Version: 1.0
Received: by 10.221.11.138 with SMTP id pe10mr2223285vcb.54.1346347033996; Thu, 30 Aug 2012 10:17:13 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.58.216.42 with HTTP; Thu, 30 Aug 2012 10:17:13 -0700 (PDT)
In-Reply-To: <3A791D9E-4F16-4481-94AE-BD38A5389593@verisign.com>
References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <D857A4BB-E484-45A4-A09F-FB8FAF2215AC@tcb.net> <C5B88834-3A10-41F7-A4F3-2B7C9B540197@verisign.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> <303C576D-D1F8-4F62-8E0E-0D74A28B2771@verisign.com> <503D141F.1060404@bbn.com> <3A791D9E-4F16-4481-94AE-BD38A5389593@verisign.com>
Date: Thu, 30 Aug 2012 13:17:13 -0400
X-Google-Sender-Auth: KaitXx9v7CV1PffoZ-84vKD1r8g
Message-ID: <CAL9jLaaew6HLdHK4=UrsUF2JKsRRV=sbXzCOFiDnLRKtVSK1tw@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Eric Osterweil <eosterweil@verisign.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: sidr@ietf.org
Subject: Re: [sidr] RPKI <-> allocation consistency
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: Thu, 30 Aug 2012 17:17:15 -0000

On Thu, Aug 30, 2012 at 10:59 AM, Eric Osterweil
<eosterweil@verisign.com> wrote:
>
> On Aug 28, 2012, at 2:55 PM, Stephen Kent wrote:
>
>> Eric,
>>
>> Perhaps what you are looking for is some text in an operations doc, suggesting what
>> an RP can expect, depending on how it elects to interact with the repository system,
>> maintain its local cache, etc.
>
> Actually, I was looking for some intuition/guidance for people in a position to take a systematic look at how to implement the design.  I'm not sure which draft, or which section, etc.  Basically, I'm trying to get things worked out, but I keep having issues w/ ensuring that ingestion of data by a process at (say) one router has something/anything to do with the ingestion of the same thing at (say) another router.  Consistency models tell me what properties I can rely on at time t_0 at location r_0 vs time t_1 at r_1, etc.  Right now, I'm having a lot of trouble ensuring that anything agrees with anything else in the Interwebz and I don't know if I should just let that be the case, or there is some sort of consistency I need to adhere to...
>

right, for the whole system you want to know:
  'how long between ROA create and ROA-foo on router'

I think what you really want (because across the whole of the realm
it's a 'simple' model, where inside islands there is potentially lots
more fudgery) is:
  1) 'how long from roa-create -> roa-at-all-ASNs'
  2) 'what model of timing makes sense for 'once a ROA is at a remote
ASN, how long before that data is available on 1 routing-device, then
all routing-devices in that realm'
  3) should this set of numbers apply to ALL objects in the RPKI
equally? or should some object types have different timing
requirements?

-chris

(using ROA as the unit, you could use CRL update, EE-cert, etc... 'one
item in the RPKI')

> Eric
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr