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

[Christopher Morrow <[e-mail]>]

On Fri, Nov 4, 2011 at 11:57 AM, Eric Osterweil <[e-mail]> wrote:
>
> On Nov 3, 2011, at 11:59 AM, Stephen Kent wrote:
>
>> At 9:32 PM -0400 11/2/11, Danny McPherson wrote:
>>> On Nov 2, 2011, at 11:04 AM, Stephen Kent wrote:
>>
>
> <snip>
>
>>> More specifically, if I have perform a cost/benefit analysis it's not at all clear to me
>>> that tightening exposure windows to the frequency (hours/days) you're suggesting
>>> is worth the investment and fundamental shift from the stateful BGP model we know
>>> today, particularly given the drive-by and targeted nature we see in all other aspects
>>> of security today (e.g., APT, phishing, etc..).
>>
>> I presume that your statement "fundamental shift from the stateful BGP model..." refers to beaconing. Beaconing does create a new basis for propagating a route, but an AS could cause the same impact on the routing system by changing other route parameters at the same frequency, consistent with the BGP spec. I'd prefer a better solution, but I don't have one to offer at this time.
>
> ooc, in regards to the above: is there any detailed analysis of how much extra overhead we can expect from these beacons if BGPSec were deployed universally today?  Specifically, the comment above, "an AS could cause the same impact on the routing system by changing other route parameters at the same frequency" seems to miss the point I think I see in the objection: what if _every_ AS must do this all the time (not just a rogue, or select few).  How much extra overhead would ensue if (say) someone took the current set of all ASes and prefixes and simulated the extra update traffic needed in (say) a day?  Maybe if we saw some numbers that told us how many additional updates and how much additional bandwidth this approach would require in a routing system like today's we could understand another aspect of much of a shift we are talking about?
>

my recollection is we ran some of these numbers (based, I think, on
routeviews dump/mrt data), perhaps randy or stephen has this sort of
number available?