Re: [sidr] RPKI <-> allocation consistency

Eric Osterweil <eosterweil@verisign.com> Thu, 23 August 2012 14:21 UTC

Return-Path: <eosterweil@verisign.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 B357C21F856F for <sidr@ietfa.amsl.com>; Thu, 23 Aug 2012 07:21:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 cIOaX2emecPV for <sidr@ietfa.amsl.com>; Thu, 23 Aug 2012 07:21:39 -0700 (PDT)
Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 50E1121F856C for <sidr@ietf.org>; Thu, 23 Aug 2012 07:21:30 -0700 (PDT)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKUDY8aScR6i6Uqf+La6qMfPoXPXtRvhad@postini.com; Thu, 23 Aug 2012 07:21:36 PDT
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q7NELP9P016826; Thu, 23 Aug 2012 10:21:25 -0400
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Aug 2012 10:21:24 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <D857A4BB-E484-45A4-A09F-FB8FAF2215AC@tcb.net>
Date: Thu, 23 Aug 2012 10:21:24 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <C5B88834-3A10-41F7-A4F3-2B7C9B540197@verisign.com>
References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <D857A4BB-E484-45A4-A09F-FB8FAF2215AC@tcb.net>
To: Danny McPherson <danny@tcb.net>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 23 Aug 2012 14:21:24.0676 (UTC) FILETIME=[93867040:01CD813A]
Cc: "Murphy, Sandra" <Sandra.Murphy@sparta.com>, "sidr@ietf.org" <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, 23 Aug 2012 14:21:41 -0000

On Aug 22, 2012, at 10:41 PM, Danny McPherson wrote:

> 
> Admittedly, I'm not certain what triggered this, but clearly, your email to me suggests that others have expressed concern of consistency and collisions, a concern expressed by the IAB as well.  As such, I have a question below.
> 
> On Aug 10, 2012, at 4:45 PM, Murphy, Sandra wrote:
> 
>> speaking as regular ol' member
>> 
>> About allocation <-> RPKI consistency
>> 
>> The RPKI is a certification of resource holding.  Because the allocation databases continue to also record allocations, there's duplication of information between the RPKI and the allocation databases.
>> 
>> Having duplicate records of the same data always presents an issue of consistency.  We know we have this issue (have known it from the beginning), any resource certification outside the allocation system would, so we need to work on how to handle it.
>> 
>> Handling it is out-of-band.  Consistency will be a matter of process, to ensure that allocation actions are bound to issuance of consistent CA certificates (if and when one is issued) and vice versa.  Monitoring the two to spot inconsistencies will be another process.
>> 
>> Duplicates may be valid.  There may be reasons for multiple CA certificates being issued for exactly the same prefix space.  Transfer (or at least the only method of transfer discussed in the wg) would result in multiple CA certificates being issued for exactly the same prefix space, for make-before-break purposes.
>> 
>> We already have a potential for inconsistency.  As noted in the IAB statement on the RPKI, multiple trust anchors present a risk of conflicting certifications for the same address block.  We do not yet have a single root trust anchor.  No need for panic, the RIRs are aware and I trust they have process in mind to ensure consistency.   (This is a contentious issue - hopefully that's worded with sufficient care and balance.)  But that's another case where consistency is/will be ensured by process.
> 
> 
> Sandy (or others in the know), can you shed any light on the process you have in mind to ensure consistency?  Particularly from the perspective of a prospective RP?  Pointers to process (e.g., RIR processes in the works) are fine.

Indeed, I vaguely recall some conversations (on the list?) about the specific consistency model that the RPKI is trying to achieve.  I wasn't able to unearth the thread, but what was the conclusion?  That is, what is the consistency model that the RPKI design team is striving for?

Thanks,

Eric