On Fri, Nov 4, 2011 at 11:57 AM, Eric Osterweil <[email protected]> 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? _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
