[sidr] RPKI <-> allocation consistency

"Murphy, Sandra" <Sandra.Murphy@sparta.com> Fri, 10 August 2012 20:45 UTC

Return-Path: <Sandra.Murphy@sparta.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 25DE421F86F1 for <sidr@ietfa.amsl.com>; Fri, 10 Aug 2012 13:45:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.542
X-Spam-Level:
X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 jtM8cghXko7C for <sidr@ietfa.amsl.com>; Fri, 10 Aug 2012 13:45:06 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBBB21F86EF for <sidr@ietf.org>; Fri, 10 Aug 2012 13:45:05 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7AKj5St002895 for <sidr@ietf.org>; Fri, 10 Aug 2012 15:45:05 -0500
Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7AKj4JI008774 for <sidr@ietf.org>; Fri, 10 Aug 2012 15:45:04 -0500
Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Fri, 10 Aug 2012 16:45:04 -0400
From: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
To: "sidr@ietf.org" <sidr@ietf.org>
Thread-Topic: RPKI <-> allocation consistency
Thread-Index: Ac13EBo5wrqMsPdrRdKYnzi7/aF9Vw==
Date: Fri, 10 Aug 2012 20:45:03 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.185.63.137]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [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: Fri, 10 Aug 2012 20:45:07 -0000

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.

The sky's not falling, we're OK, we can do this, etc.

--Sandy, speaking as regular ol' member