IETF Logo Mail Archive

Re: [sidr] RPKI <-> allocation consistency

Tim Bruijnzeels <tim@ripe.net> Fri, 31 August 2012 13:24 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 78C2521F855D for <sidr@ietfa.amsl.com>; Fri, 31 Aug 2012 06:24:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.49
X-Spam-Level:
X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 yIu2y442HVVw for <sidr@ietfa.amsl.com>; Fri, 31 Aug 2012 06:24:18 -0700 (PDT)
Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 5160F21F848B for <sidr@ietf.org>; Fri, 31 Aug 2012 06:24:18 -0700 (PDT)
Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1T7RCm-0003LJ-C2; Fri, 31 Aug 2012 15:24:17 +0200
Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-136.ripe.net) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1T7RCm-0003Nu-4i; Fri, 31 Aug 2012 15:24:12 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-11-892548278"
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <CAH1iCiqScOwzcAWEuFfHKH4kP6gj45fKqs6rdPq97PsYO+uEMQ@mail.gmail.com>
Date: Fri, 31 Aug 2012 15:24:11 +0200
Message-Id: <40FB7E48-E808-4FC7-9458-E236FB356EC7@ripe.net>
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> <CAL9jLaaew6HLdHK4=UrsUF2JKsRRV=sbXzCOFiDnLRKtVSK1tw@mail.gmail.com> <CAH1iCirWo+JYOpFjVhtxXYKGB86nLhcogC20bEy0-Ldkp7Oc8A@mail.gmail.com> <CAL9jLaY3JLBf7H5H2zWvxv2T=9ZsSQbOAxM+mTixefZkF8oVFw@mail.gmail.com> <CAH1iCiqScOwzcAWEuFfHKH4kP6gj45fKqs6rdPq97PsYO+uEMQ@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
X-Mailer: Apple Mail (2.1084)
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120831 clean
X-RIPE-Spam-Level: ---
X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.2 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] 0.0 HTML_MESSAGE BODY: HTML included in message
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719a85578b6760c40726855bd43b9d10a6c
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: Fri, 31 Aug 2012 13:24:19 -0000

Hi,

On 31 Aug 2012, at 14:34, Brian Dickson wrote:
> So, does it not make sense that the RPKI, meaning its design, architecture, procedures, etc., should actually enforce exclulsivity?

I think that INRs appearing on certs in multiple locations, different TAs, or different branches, are not really a *technical* problem. Meaning that if these certs are used to sign objects they are just complementary. It doesn't matter whether one CA signs a set of objects or the same set (content) is signed by multiple CAs. Plus, this feature is actually needed when doing make-before-break transfers of live networks.

Of course it's important that information is correct. But the notion that uniqueness of resources in the tree guarantees correctness seems fundamentally flawed to me. Correctness is assumed by transitive trust placed in the TA(s), and can only be manually verified by comparing certs to public registration databases.

Regards,

Tim

v2.23.0 | Report a Bug | By Email