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

Sandra Murphy <> Tue, 04 March 2008 16:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EBEE828C62F; Tue, 4 Mar 2008 08:36:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.636
X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[AWL=-0.199, 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 gviiZSpmkyw2; Tue, 4 Mar 2008 08:36:36 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id AE74F28C481; Tue, 4 Mar 2008 08:35:43 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62AEF28C6F5; Tue, 4 Mar 2008 08:35:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pCRMZmcwWFjy; Tue, 4 Mar 2008 08:35:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CE26A28C6F4; Tue, 4 Mar 2008 08:34:38 -0800 (PST)
Received: from ( []) by (8.13.5/8.13.5) with ESMTP id m24GYJdG026841; Tue, 4 Mar 2008 10:34:19 -0600
Received: from ( []) by (8.12.11/8.13.1) with ESMTP id m24GYJd8029474; Tue, 4 Mar 2008 10:34:19 -0600
Received: from localhost ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Mar 2008 11:34:19 -0500
Date: Tue, 04 Mar 2008 11:34:18 -0500
From: Sandra Murphy <>
To: Vishwas Manral <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Mar 2008 16:34:19.0190 (UTC) FILETIME=[9822F560:01C87E15]
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 ( []); Tue, 04 Mar 2008 10:34:19 -0600 (CST)
Cc: 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 Tue, 4 Mar 2008, Vishwas Manral wrote:

> Hi Joe,
> If you saw the mail exchange between Sandra and I, you will notice she
> mentioned the reason they have to go ahead with SIDR even though we
> have tools available from RIPE. What I have been trying to do is to
> figure out weaknesses. in the current infrastructure to get a secure
> behavior. As a first step I found out this weakness and updated RIPE/
> Daniel about the same.

Please keep in mind that RIPE is not the only IRR.  And RIPE can not 
verify authorization for prefixes and ASs outside its range.  So improving 
RIPE does not buy you what you want.

> As we discussed earlier SIDR does not provide a totally secure
> infrastructure. The point here is that SIDR is giving some very basic
> improvements in the security, generally in the non-malicious case.

Please keep in mind that I have said SIDR does most definitely protect 
against malicious attacks for those attacks it is addressing.

SIDR makes no difference between maliciousness or carelessness in the 
attacks it counters.

There are plenty of malicious and accidental ways to attack routers that 
are not in the realm of what SIDR is considering now.  Maliciousness is 
not the distinguisher here.

To be plain, to say SIDR addresses only non-malicious cases is flat out 
WRONG.  (And sorry for not having pointed that out before, I thought I 

> The
> idea is can we get a similar security with the current infrastructure,
> by doing minor improvements. There is a certain cost involved with the
> SIDR infrastructure.

No, we cannot get similar security with current infrastructure, even with 
MAJOR improvements to the security of the current infrastructure.  The 
structure of the current infrastructure does not permit similar security 
to what the RPKI provides.

Unless, of course, you want to add all RPKI features to the IRR model, so 
that the IRR becomes the same as the RPKI.  Of course, you adopt the cost 
as well.


> I do not think the SSL channel has not been done because it is
> unnecessary. I guess there hasn't been an attack on that side of the
> infrastructure yet, but these are well known issues/ attacks in other
> fields.
> Thanks,
> Vishwas

Sidr mailing list