Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

Russ White <russw@riw.us> Tue, 08 November 2011 14:27 UTC

Return-Path: <russw@riw.us>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F6E21F8C67 for <sidr@ietfa.amsl.com>; Tue, 8 Nov 2011 06:27:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.372
X-Spam-Level:
X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jej8j3TQGTe0 for <sidr@ietfa.amsl.com>; Tue, 8 Nov 2011 06:27:30 -0800 (PST)
Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 91C4821F8AEE for <sidr@ietf.org>; Tue, 8 Nov 2011 06:27:30 -0800 (PST)
Received: from [12.180.141.130] (port=54093 helo=[63.140.190.249]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <russw@riw.us>) id 1RNme9-0007MN-3q for sidr@ietf.org; Tue, 08 Nov 2011 09:27:29 -0500
Message-ID: <4EB93C4F.1070302@riw.us>
Date: Tue, 08 Nov 2011 09:27:27 -0500
From: Russ White <russw@riw.us>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: sidr@ietf.org
References: <CAL9jLaa+L-C7+Gp54BpM8FjAj+EFMabwQB9SsPW0N4QnFEfVGw@mail.gmail.com> <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <p06240808cad5c4d268eb@193.0.26.186> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <p06240804cad81a9e4485@193.0.26.186> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com>, <CAL9jLaZ1GoN-iG4SWocVVhTKp5ppPOgHWcjh1J30GPnfwBPf+A@mail.gmail.com> <D7A0423E5E193F40BE6E94126930C49308E9E3555C@MBCLUSTER.xchange.nist.gov>
In-Reply-To: <D7A0423E5E193F40BE6E94126930C49308E9E3555C@MBCLUSTER.xchange.nist.gov>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - riw.us
Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Tue, 08 Nov 2011 14:27:31 -0000

> Now if we consider a BGPSEC island of 100,000 participating prefixes
> (multiple ISPs form a BGPSEC island and there is BGPSEC between
> them and also in each ISP's entire customer cone):
> With 24 hour beaconing interval, we would have:
> Prefix Updates per Day = 100,000 (seen at each BGPSEC router)

It's one additional update per table entry per day, assuming a 24 hour 
beacon. If the table is 300,000 routes, it's 300,000 additional updates 
a day --on top of normal churn.

The 24 hour "beacon rate," is a bad assumption anyway --once operators 
catch on to this being the actual amount of time you're willing to allow 
others to hijack your routes, the rate will shorten up considerably. 
There's no "downward limit" on the time, and there's no real economic 
incentive for the originator to choose longer times.

At some point you're going to be forced to put in timers per AS Path hop 
--since the signature in the packet represents the policy and 
connectivity between every pairwise set in the AS Path, every pairwise 
set also needs a timer.

Added together, we are talking at least a doubling of the rate at which 
updates are received (and probably more like a tripling or quadrupling 
over time), at least a quadrupling of the total traffic in terms of 
bits/second (assuming the lowest possible update rates)--and all of this 
counts the cost of actually handling the crypto inbound and outbound as 
zero.

Russ