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

"Vishwas Manral" <vishwas.ietf@gmail.com> Thu, 28 February 2008 17:56 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 5F9B128C8AB; Thu, 28 Feb 2008 09:56:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.302
X-Spam-Level:
X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_SORBS_WEB=0.619, 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 VB1tPvSGAzPT; Thu, 28 Feb 2008 09:56:36 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDC6428C62E; Thu, 28 Feb 2008 09:56:36 -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 E20853A69D9 for <sidr@core3.amsl.com>; Thu, 28 Feb 2008 09:56:35 -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 Pi7K4wAXm2WK for <sidr@core3.amsl.com>; Thu, 28 Feb 2008 09:56:30 -0800 (PST)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 78AD73A68E1 for <sidr@ietf.org>; Thu, 28 Feb 2008 09:56:30 -0800 (PST)
Received: by wf-out-1314.google.com with SMTP id 25so3232652wfa.31 for <sidr@ietf.org>; Thu, 28 Feb 2008 09:56:23 -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=e5qlXvwcpsaWBQEAKyqzbIRI8x3fMOA1tM+Q9pxW3uE=; b=gLEZ9TsCIPM0RytDz9+0XndFriEiwfPiVhSlKsOgInCxo1IijF4urDx1Bys3x8LpPORuVe3KnkdcyzwOWtaHgici58d5P7gDlAmpIMJ4A1l956w9BRC8JThrExbJZYSCydDc7/Q1R95z7qidBvN96Uhlg2exyrAczxFWKsMRp08=
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=e68fTfVLzH+TafDJAFzTHxClhqcFGX4sbS3XBTZ9HVhQcsxkA+qqh0JUvTu6JO4Sy1ZqKSBJr0MEKZr5AOyf+C14ssbE50qeEDlV3uG5kTKFOrbFQUBlh54RWqZhoT/+r+wmkUxtCsNJrui5EqFgekwdyX/YqnQXeWJcyUiFUf8=
Received: by 10.143.40.18 with SMTP id s18mr2624271wfj.156.1204221383592; Thu, 28 Feb 2008 09:56:23 -0800 (PST)
Received: by 10.143.164.14 with HTTP; Thu, 28 Feb 2008 09:56:23 -0800 (PST)
Message-ID: <77ead0ec0802280956s3dcff81cx25fd152ea1c798fb@mail.gmail.com>
Date: Thu, 28 Feb 2008 09:56:23 -0800
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Sandra Murphy <sandy@sparta.com>
In-Reply-To: <Pine.WNT.4.64.0802281109260.2416@SANDYM-LT.columbia.ads.sparta.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <47C4E38E.1070105@bogus.com> <3DD63532-9442-4B12-B1DF-5EA70A66C87D@cisco.com> <77ead0ec0802271712m53e8a1d4sc9cae09ee75686f7@mail.gmail.com> <p06240500c3ebd2c48236@192.168.101.9> <77ead0ec0802271913u2c032ec2y2d03b73cb36de37f@mail.gmail.com> <p06240509c3ebe4459c93@169.223.13.71> <77ead0ec0802272031j6d958279tf3028c4096093020@mail.gmail.com> <p0624050cc3ebfc54fb15@169.223.13.71> <77ead0ec0802280649k66671fc9s9fc24314963c68a0@mail.gmail.com> <Pine.WNT.4.64.0802281109260.2416@SANDYM-LT.columbia.ads.sparta.com>
Cc: Roland Dobbins <rdobbins@cisco.com>, 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,

Thanks for the reply. You put forward the all the points correctly and
precisely.

My concern is that, unlike the normal PKI model where the final output
is to authenticate the user using the just the certificate, the
Routing based model we are now talking about verifying just a small
bit of information which is used for the BGP Best Path selection - the
sanity of which we are trying to protect, and protecting just the
Origin does not make sense in a malicious case at all. Though you may
say that it protects in case the malicious person plays with the
Origin attribute, it however does not protect much as with the same
amount of effort a malicious person can still cause the same attacks.
What increases is the over head in each of the domains to maintain the
new PKI information.

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.

Thanks,
Vishwas

On Thu, Feb 28, 2008 at 8:34 AM, Sandra Murphy <sandy@sparta.com> wrote:
>
>
>  On Thu, 28 Feb 2008, Vishwas Manral wrote:
>
>  > Hi Stephen,
>  >
>
> > Ok, I understand the model you talk about now. Yes the CPU may not be
>  > the biggest concern as the server is verifying the Cert's offline. I
>  > guess this would also lead to models like CRL's for revocation.
>  >
>  > Like I said earlier as SIDR does not stop malicious attacks, but only
>  > ones caused unintentionally, is it not possible to actually use a
>  > simpler mechanism to get over such errors?
>  >
>  > Thanks,
>  > Vishwas
>  >
>
>  Vishwas, the current SIDR work is focused on preventing attacks
>  (faulty/misconfigured/subverted/malicious/whatever) against the
>  origination of routing advertisements, by providing strong assurance of
>  who holds what prefixes, and therefore who can authorize origination of
>  a prefix.
>
>  (And in the leak that is the subject of this email chain, the fully
>  deployed system would indeed have detected the mis-origination, in any AS
>  that had received the mis-origination, not just the direct link up from
>  the customer.)
>
>  The concerns you raise are recognized subjects for further work.
>
>  But all of the very many proposals for securing BGP (see: S-BGP, soBGP,
>  psBGP, SPV, etc., etc.) rely on protecting this initial bit of routing
>  information: originating a route to a prefix.  So defining this work is a
>  basis for defining future fuller protection techniques as well.
>
>  All simpler mechanisms I have ever heard of for protecting origination of
>  routing advertisements are either much lower assurance, or based on data
>  with similar strong protections but not more assurance, or not extensible
>  to protecting more features of BGP exchanges.
>
>
>  --Sandy
>
_______________________________________________
Sidr mailing list
Sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr