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

Sandra Murphy <sandy@sparta.com> Mon, 10 March 2008 20:55 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 6E9583A6E1A; Mon, 10 Mar 2008 13:55:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.978
X-Spam-Level:
X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 FqNpNXzIJzKe; Mon, 10 Mar 2008 13:55:08 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D536D3A6B07; Mon, 10 Mar 2008 13:55:07 -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 3A7DA3A6DD0; Mon, 10 Mar 2008 13:55:06 -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 b5Hx2Vd21P8o; Mon, 10 Mar 2008 13:55:04 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id F0FF53A6D4D; Mon, 10 Mar 2008 13:55:03 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m2AKqgwL032415; Mon, 10 Mar 2008 15:52:42 -0500
Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m2AKqgPx021522; Mon, 10 Mar 2008 15:52:42 -0500
Received: from localhost ([130.129.20.112]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Mar 2008 16:52:41 -0400
Date: Mon, 10 Mar 2008 16:52:41 -0400
From: Sandra Murphy <sandy@sparta.com>
To: Curtis Villamizar <curtis@occnc.com>
In-Reply-To: <200803060534.m265Y4To002722@harbor.brookfield.occnc.com>
Message-ID: <Pine.WNT.4.64.0803101616140.648@SANDYM-LT.columbia.ads.sparta.com>
References: <200803060534.m265Y4To002722@harbor.brookfield.occnc.com>
X-X-Sender: sandy@nemo.columbia.sparta.com
MIME-Version: 1.0
X-OriginalArrivalTime: 10 Mar 2008 20:52:41.0703 (UTC) FILETIME=[AED53770:01C882F0]
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Mon, 10 Mar 2008 15:52:42 -0500 (CDT)
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sidr-bounces@ietf.org
Errors-To: sidr-bounces@ietf.org


On Thu, 6 Mar 2008, Curtis Villamizar wrote:

>
> In message <Pine.WNT.4.64.0803041119370.4228@SANDYM-LT.columbia.ads.sparta.com>
> Sandra Murphy writes:
>>
>> [---8<---snip---]
>>

<< snip >>
>
> 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
>

I commented last July on the security model (RPSS) used in RIPE

http://www.ietf.org/mail-archive/web/sidr/current/msg00207.html

To expand a bit.

The model in RPSS has a similar basis as the model used in the RPKI, 
namely that delegation of a prefix requires authority over a covering 
prefix - that comes from the inetnum authorization requirement.  The RPSS 
model also insists that the prefix holder is the one who authorizes 
origination of routes to that prefix.

The RPSS model goes further to insist that authorization to originate 
routes (actually, to create a route object for a prefix) must also be 
granted by the AS mentioned.  In that the authorization model in RPSS is 
different than the RPKI model.

That makes revoking authorization different as well.  To delte a route 
object in RPSS, you need the authorization of both the prefix holder and 
the AS.  (This could cause difficulties if some prefix holder changes 
providers and wishes to remove the route object, if its former provider is 
not interested in OK the route object deletion.)

RFC2769 addresses the problem (I think) of invalidating inetnums that are 
derived from an inetnet that gets deleted.  (If that is what is meant as 
"repeating authorization checks".)  It seems to me that there is no way to 
bound the number of database objects that are potentially effected by one 
object deletion.

But the biggest difference is in the trust model.  RPSS assumes that the 
IRR has a way to authenticate the principles - the maintainers.  A 
particular object might have multiple maintainers (of various types) and 
each can have more than one way to be authenticated.  The maintainers 
authenticate in some way to the IRR and the IRR stores the data.  Those 
referring to the data must have some way to retrieve the data from the IRR 
that is itself secure.

But even with a secure retrieval, the data retrieved carries no hint of 
the authentication with which it was transmitted to the IRR.  You don't 
know which maintainer placed the info there and you don't know what 
authentication mechanism was used in accepting the data.

No one can authenticate the data except the IRR, and no one can know what 
assurance to place in the data, aside from a blind "I trust my IRR".

There are also issues of staleness of data, as there is no mechanism to 
state and enforce a validity period.  (From reports, stale IRR data played 
a part in the spread of bogus info in the Con Ed incident last year.)

An IRR might go to using the strongest authentication possible, and to 
accepting signed data and storing the signature.  And publishing the certs 
it assigned to users.  That would go pretty far to giving the same 
assurance of the RPKI.  But that's kind of what I meant about adopting the 
same mechanisms as the RPKI, and therefore the cost

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