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

"Vishwas Manral" <vishwas.ietf@gmail.com> Thu, 28 February 2008 14:49 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 E3A1928C1BB; Thu, 28 Feb 2008 06:49:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.312
X-Spam-Level:
X-Spam-Status: No, score=-0.312 tagged_above=-999 required=5 tests=[AWL=-0.494, 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 LwZuyR1-v46Y; Thu, 28 Feb 2008 06:49:14 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E313A6EC2; Thu, 28 Feb 2008 06:49:14 -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 23F683A6EC2 for <sidr@core3.amsl.com>; Thu, 28 Feb 2008 06:49:13 -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 EyDtsLAexUin for <sidr@core3.amsl.com>; Thu, 28 Feb 2008 06:49:12 -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 578433A6916 for <sidr@ietf.org>; Thu, 28 Feb 2008 06:49:12 -0800 (PST)
Received: by wf-out-1314.google.com with SMTP id 25so3097721wfa.31 for <sidr@ietf.org>; Thu, 28 Feb 2008 06:49:04 -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=2LMqDnRhvtGFCnWRT3C5RJ7jv08T5vrohuF7JpwZQNw=; b=dsjhhhrY6s0R9B2S4UzL9RrqWlu+b/yswNsPKbw9YLW1e5IgjsVsYGXHv5um9rJYwpyLLaxrTDEv3kq5kDFJBV7HC+OrWMcwu8uXkFQbgdeXnGIJ6N3Wg9+Sof578B6czCsv0S3+R2cE9BOmhM16qw99ETG4sNSOOHQrMKr9aEc=
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=XJfK7ZaRJZr2ICoc9qzEHuZUa5b7aa91lNYeRTBMgKnEwiV9c5PPjiseO5cthYxd0OGamHvd4zKLkXuDQJO4iXPm8fiYrvGEcJWqWuov9RVexuFVPp28ratVppFnWFlPBzkqa/+QmQqexyEl8/49R2DqR4ShmWOls3ToUA3f0ew=
Received: by 10.142.114.15 with SMTP id m15mr6337766wfc.235.1204210144900; Thu, 28 Feb 2008 06:49:04 -0800 (PST)
Received: by 10.143.164.14 with HTTP; Thu, 28 Feb 2008 06:49:04 -0800 (PST)
Message-ID: <77ead0ec0802280649k66671fc9s9fc24314963c68a0@mail.gmail.com>
Date: Thu, 28 Feb 2008 06:49:04 -0800
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Stephen Kent <kent@bbn.com>
In-Reply-To: <p0624050cc3ebfc54fb15@169.223.13.71>
MIME-Version: 1.0
Content-Disposition: inline
References: <47C4E38E.1070105@bogus.com> <77ead0ec0802262229wd5e695ag95021040d7492828@mail.gmail.com> <E54F9525-AE5E-4F96-A044-FCEBEBCA6DB3@tcb.net> <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>
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 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

On Thu, Feb 28, 2008 at 3:35 AM, Stephen Kent <kent@bbn.com> wrote:
>
>
> At 8:31 PM -0800 2/27/08, Vishwas Manral wrote:
> Hi Stephen,
>
>  The point I raise is that there is a cost associated with this, using
>  certificates has a CPU cost associated with it.
>
>  I may be missing the point but even if you leave aside the cost of an
>  off line server to do this check but if the checks are done on each
>  new prefix we can still overload the off line server. If we do things
>  like rate limiting we can still have an attacks, or cause delays in
>  the convergence times.
>
>  Thanks,
> Vishwas
>
>
> I think you are missing the point. So long as the processing is done as an
> offline operation, not as a gating item in routing, it does not strike me as
> a DoS concern. The initial use of the infrastructure is analogous to
> downloading IRR databases and processing the RPSL assertions, an operation
> many ISPs perform today on a daily basis.
>
>
> More to the point, folks have implemented the necessary software and tested
> it with about 20K certs and CRLs and 10K ROAs, a reasonable starting point.
> I don't have the precise figures in front of me now, but I believe their
> results show that the time to do all the processing (on a laptop) is about
> 20-30 minutes, and the time is dominated by the retrieval of the data from
> online repositories, not by the crypto operations per se. For a once daily,
> offline operations, this seems quite reasonable.
>
>
> Steve
_______________________________________________
Sidr mailing list
Sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr