Re: [sidr] beacons and bgpsec

Sorry, where did the 2% load come from?
Does that mean that every prefix in the Internet is already being advertised 50 times every day?
Then, one more advertisement per day would make it 2% extra load.

Also, note that a beacon every day means a timeout of 3 days. Previous suggestions were a timeout of ~24 hours and a beacon of ~8 hours.

An alternative to beaconing is a push model instead of pull. That is, every router registers it's interest with the repository instead of querying it periodically. Then the repository would tell all registered parties when a change occurred rather than waiting for them to ask.

--
Jakob Heitz.

On Aug 10, 2011, at 6:35 AM, "Montgomery, Douglas" <dougm@nist.gov> wrote:

> 
> On 8/9/11 9:42 PM, "George Michaelson" <ggm@pobox.com> wrote:
> 
>> 
>> On 10/08/2011, at 11:34 AM, Danny McPherson wrote:
>> 
>>> 
>>> On Aug 9, 2011, at 9:23 PM, George Michaelson wrote:
>>> 
>>>> 
>>>> You seemed to be saying "some people are saying beacons wont work"
>>> 
>>> No, that's precisely why I referenced Randy's presentation, if you
>>> didn't see it you should have a look at the proceedings...
>>> 
>> 
>> Will look
>> 
>>>> when you said: "I think Randy successfully convinced me during his
>>>> talk at the Quebec City WG session that "beacons" at a frequency of 24
>>>> hours (or anything in the "hours" range) are pretty much useless and
>>>> add considerable churn and complexity with little return from a
>>>> practical attack surface perspective.  "
>>>> 
>>>> So, I am asking, are we removing support for beacons in BGPSEC because
>>>> we don't understand their impact on BGPSEC and they add complexity
>>>> which makes BGPSEC harder to push uphill.
>>> 
>>> I was contemplating the ROI for a newly designed protocol (bgpsec) and
>>> why they were put there in the first place (replay attacks [and more
>>> frequent wedgie oscillation :)]) and considering attack surface and
>>> practical implications, realizing that from an engineering tradeoff
>>> perspective they're quite likely not worth the effort.  Hence my broken
>>> attempt at a corollary with phishing site lifetime and RIPv1 scaling
>>> properties, because I don't have quantitative empirical data handy of
>>> routing hijack duration, nor could I possibly predict what it might
>>> entail in a bgpsec-enabled world, but I do suspect 24 hours is, umm...
>>> quite a while.
>> 
>> Popup announcements for spamming might well lie under 24h lifetime. I
>> think some people have notes on that. You can inject a humongous amount
>> of store-and-forward from far far less than 24h of routing.
> 
> I think it important to remember that BGPSEC and Origin Validation are
> basically preventative, not reactionary/response mechanisms.   That is
> infrastructure that is manipulated in human time scales (e.g., ROAs,
> AS/router Certs) that prevent future false announcements.   I think it is
> the assumption that having ROAs in place will address most pop-up spam
> false announcements.
> 
> The issue of expire time and beacons - and reducing the vulnerability
> window of "stale" BGPSEC signed announcements - is a bit more of a
> reactionary measure.   The idea of expire time exists to address an BGPSEC
> signed update that *was a valid signed path* at one time but is no longer.
>  Given the assumption that the RPKI is a fairly stable and slowly
> reacting infrastructure (and one that requires administrative actions to
> change) it was seemed better to just bound the useful lifetime of a
> BGPSSEC signed update, than to propose to churn the RPKI to invalidate
> previously valid paths.
> 
> At the 24hour + range, our estimates are that it adds 1-2% load of
> announcements.
> 
> Dougm
>> 
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr