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

Sandra Murphy <> Thu, 28 February 2008 18:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5108528C994; Thu, 28 Feb 2008 10:18:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.828
X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dkXP0IkA8wZI; Thu, 28 Feb 2008 10:18:32 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id A331B28C9AF; Thu, 28 Feb 2008 10:17:12 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26EAC28C9AB; Thu, 28 Feb 2008 10:17:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qed2Kx3ALFbU; Thu, 28 Feb 2008 10:17:10 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6A0AE28C9D9; Thu, 28 Feb 2008 10:13:53 -0800 (PST)
Received: from ( []) by (8.13.5/8.13.5) with ESMTP id m1SIDSkG003371; Thu, 28 Feb 2008 12:13:28 -0600
Received: from ( []) by (8.12.11/8.13.1) with ESMTP id m1SIDScQ019850; Thu, 28 Feb 2008 12:13:28 -0600
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Feb 2008 13:13:28 -0500
Date: Thu, 28 Feb 2008 13:13:27 -0500
From: Sandra Murphy <>
To: Vishwas Manral <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <p06240500c3ebd2c48236@> <> <p06240509c3ebe4459c93@> <> <p0624050cc3ebfc54fb15@> <> <> <>
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Feb 2008 18:13:28.0256 (UTC) FILETIME=[9DFDA400:01C87A35]
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 ( []); Thu, 28 Feb 2008 12:13:28 -0600 (CST)
Cc: Roland Dobbins <>, opsec wg mailing list <>,
Subject: Re: [Sidr] [OPSEC] pccw as17557 leak...
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Thu, 28 Feb 2008, Vishwas Manral wrote:

> Hi Sandra,
> After reading a bit through what Pekka/ Danny/ Joe Abely said away in
> which we could update the filters between peers automatically(only
> relating to routes originated by the peer), from the RIR, we may
> achieve the very same functionality.

Generating filters from IRR (not RIR, a point it took me a while to learn) 
data is indeed similar, with the following differences:

(a) Security (authenticity, integrity and authorization) of IRR data 
varies widely among IRR's.  And there are quite a few IRRs.

(b) Even those IRRs associated with RIRs can protect authn/int/authr of 
only that data that comes from their own members.

(c) RIPE uses the strongest security model among the many IRRs, but their 
system relies on protection of the communication with the user (and the 
protection varies from user to user) and the protection of communication 
to the person accessing the data.  The protection is not stored with the 
data, so the reader must rely on the IRR to get it right.  I don't think 
the reader can tell what protection was used to put the data in there, so 
there's no way for the reader to judge the assurance in the data.

(d) This is not a mechanism that could extent to protection of the other 
BGP features that you have mentioned.  So if/when we decide to work on 
those features, we'd have to start over with the system we are building 
now anyway.


Sidr mailing list