Re: [Sidr] [OPSEC] pccw as17557 leak...

Stephen Kent <kent@bbn.com> Mon, 10 March 2008 02:45 UTC

Return-Path: <sidr-bounces@ietf.org>
X-Original-To: ietfarch-sidr-archive@core3.amsl.com
Delivered-To: ietfarch-sidr-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C99B728C130; Sun, 9 Mar 2008 19:45:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.985
X-Spam-Level:
X-Spam-Status: No, score=-99.985 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyT+8TJPWHvq; Sun, 9 Mar 2008 19:45:03 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02F33A6BFA; Sun, 9 Mar 2008 19:45:01 -0700 (PDT)
X-Original-To: sidr@core3.amsl.com
Delivered-To: sidr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA0C3A68B9; Sun, 9 Mar 2008 19:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAHUVzEiNyaA; Sun, 9 Mar 2008 19:44:58 -0700 (PDT)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 4266A3A686D; Sun, 9 Mar 2008 19:44:58 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.150.134.25]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1JYXyG-0001PT-5m; Sun, 09 Mar 2008 22:42:36 -0400
Mime-Version: 1.0
Message-Id: <p0624050fc3f76d67e3b3@[128.89.89.71]>
In-Reply-To: <200803060534.m265Y4To002722@harbor.brookfield.occnc.com>
References: <200803060534.m265Y4To002722@harbor.brookfield.occnc.com>
Date: Sun, 09 Mar 2008 22:42:45 -0400
To: curtis@occnc.com
From: Stephen Kent <kent@bbn.com>
Cc: opsec wg mailing list <opsec@ietf.org>, sidr@ietf.org
Subject: Re: [Sidr] [OPSEC] pccw as17557 leak...
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Type: multipart/mixed; boundary="===============0234045005=="
Sender: sidr-bounces@ietf.org
Errors-To: sidr-bounces@ietf.org

At 12:34 AM -0500 3/6/08, Curtis Villamizar wrote:
>I...
>
>
>Sandy,
>
>Would you please enumerate those things that the IRR model does not
>support after reading RFC2725 and RFC2769.
>
>Note that RFC2769 has not been implemented but would provide the
>missing functionality (ability to authenticate information held in
>other registries).  It also provides efficient replication of
>databases so anyone can have a local copy of any database of interest
>to improve query time.
>
>I am not advocating going in that direction, simply pointing out that
>SIDR to a large extent reinvents the wheel.  If anything I think SIDR
>not implementing the full RPSL semantics is deficient.
>
>Curtis

Curtis,

My impression was that 2769 does not address the same set of concerns 
that the RPKI work is addressing.

The RPKI provides a strong, cert-based link between the resource 
allocation hierarchy and signed objects that attest to resource 
holdings. The use of ROAs and analogous signed objects (verifiable 
under the RPKI) enable resource holders to make clearly defined 
assertions about resources, e.g, the authorization of an AS to 
originate a route to a prefix. These assertions can be verified 
without worrying about the integrity of the management of an IRR, 
e.g., the path via which the object was obtained.

2769 seems to focus on authorization to manage objects in the IRR, a 
very important but distinct concern.  The integrity model seems to 
emphasize transitive trust (e.g., tracing data integrity back to an 
authoritative directory), and authorization of manage an object. This 
is different from the use of signed objects that can be verified 
through use of an authoritative PKI. (I note that the term PKI does 
not appear anywhere in the RFC, and the term certificate (or cert) 
appears only a few times. There are references to use of PGP keys for 
authenticating a user who wants to manage objects, but that is a very 
different use of public key crypto.)

It is appropriate to examine the intersection of the IRR/RPSL model 
and the SIDR work to see how the two can fit together, but I disagree 
with the suggestion that SIDR "reinvents the wheel." SIDR adopts a 
different initial focus, i.e., defining a profile for certs that 
represent resource holdings. As we move to introduce additional 
signed objects, e.g. ROAs and BOAs, then  we get closer to some of 
the functionality of RPSL.

Steve
_______________________________________________
Sidr mailing list
Sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr