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

"Vishwas Manral" <vishwas.ietf@gmail.com> Tue, 04 March 2008 16:52 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 A001A28C7FC; Tue, 4 Mar 2008 08:52:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.664
X-Spam-Level:
X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
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 VBtDjE+oihUr; Tue, 4 Mar 2008 08:52:15 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFE0328C6C5; Tue, 4 Mar 2008 08:51:19 -0800 (PST)
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 5953028C33D for <sidr@core3.amsl.com>; Tue, 4 Mar 2008 08:51:19 -0800 (PST)
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 m6F1ZrpkOdWK for <sidr@core3.amsl.com>; Tue, 4 Mar 2008 08:51:15 -0800 (PST)
Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.191]) by core3.amsl.com (Postfix) with ESMTP id 0EA7328C6C5 for <sidr@ietf.org>; Tue, 4 Mar 2008 08:49:52 -0800 (PST)
Received: by gv-out-0910.google.com with SMTP id i36so768111gve.15 for <sidr@ietf.org>; Tue, 04 Mar 2008 08:49:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=9f8fEQjfahLWFYmrfZ0DUHPkTOfhlMnVRHVSQugMqCM=; b=kjtXPuZS0oIYjoBcBB5c5LhesqbqkkR1xijD5xRO42PkQEJOzjuVcs2qkFcvUtjw7MPjteL/aTONUvZDpWw7h/ColkXaXbqXIxvQel4xtQfOuR2Crl7L5pqAcAMUyneni7Pv5YcpaPMI13K50wIPy0VbvUJ4/xSlohj3PEHg6P0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f+y/9gaE87TwzJlHQAol2PwEnRuYhVFnwzEG1Xz96cxPUBNNRiI2uuS/wzX8zsIsUuxxyAHuU5K5bDJdCmiK/osIOuHLsmWLBmJfgOn8jPHFGVX2zFfECyAl3swnB4ODJOrU4B7tUgqINRBbG1O0HJDPvqxe6rbRA7dx3qjvXTU=
Received: by 10.142.241.10 with SMTP id o10mr560152wfh.155.1204649381292; Tue, 04 Mar 2008 08:49:41 -0800 (PST)
Received: by 10.143.164.14 with HTTP; Tue, 4 Mar 2008 08:49:41 -0800 (PST)
Message-ID: <77ead0ec0803040849x7f26aa13hdd8ce7f0489b938b@mail.gmail.com>
Date: Tue, 04 Mar 2008 08:49:41 -0800
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Sandra Murphy <sandy@sparta.com>
In-Reply-To: <Pine.WNT.4.64.0803041119370.4228@SANDYM-LT.columbia.ads.sparta.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <47C4E38E.1070105@bogus.com> <77ead0ec0803020837s16bccee8ledbc9ae1bb60e117@mail.gmail.com> <7C9DBE28-7B7A-4053-85AE-4B954FFEEC57@ca.afilias.info> <77ead0ec0803040714v4235cff2u65bd247694e30570@mail.gmail.com> <5B7F4259-8CAB-4895-8F26-8BFD0CE7C56B@ca.afilias.info> <77ead0ec0803040727n24b68e0fm5650e8fb6c1b1dc@mail.gmail.com> <77ead0ec0803040736t55871ebex445e6fe31d6ac129@mail.gmail.com> <6AAD8CE4-1A16-4C8D-A883-EC5D4D80D2FD@ca.afilias.info> <77ead0ec0803040759p4fad1726m9e175625a13d04a6@mail.gmail.com> <Pine.WNT.4.64.0803041119370.4228@SANDYM-LT.columbia.ads.sparta.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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sidr-bounces@ietf.org
Errors-To: sidr-bounces@ietf.org

Hi Sandra,

You are right RIPE is not the only IRR. The reason I brought up RIPE
is because it was mentioned that RIPE provides more secure services.
If it is a good model, I would wonder why other IRR cannot do the
same.

>  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
>  did.)
Sandra, yes you mentioned it clearly in your mail. Let me put an
analogy for the same and let me know if our differences of opinions
match, We have 4 glasses on a window and one of them has been made
fully bulletproof at a big expense. The point you raise is it protects
when you hit against the glass that has been made bulletproof. The
point I bring out is that if at a cheaper cost we can harden the
glasses it may be a better option. That is what I mean by
non-malicious intent.

I guess that is the difference of opinion we have.

Thanks,
Vishwas

On Tue, Mar 4, 2008 at 8:34 AM, Sandra Murphy <sandy@sparta.com> wrote:
>
>
>  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
>  did.)
>
>
>
>  > 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.
>
>  --Sandy
>
>
>  >
>  > 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
>  >
>
>  <snip>
>
_______________________________________________
Sidr mailing list
Sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr