Speaking as a regular ol' member
On Wed, 10 Aug 2011, Jakob Heitz wrote:
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.
I'm not sure I understand your suggestion that the repository push
changes, as the bgpsec protocol (where beaconing occurs) is not a
repository based system.
The bgpsec protocol draft describes an in-band system, where protections
for bgp routes get transmitted synchronously with the bgp routes. Trying
to couple transmission (whether push or pull) of protections of the bgp
routes via a repository system would present difficulties in getting the
protections to the recipients at the right time.
OTOH, the RPKI *is* a repository system, and that works for the types of
data stored in the RPKI because it changes infrequently (or infrequently
compared to the rate of change in BGP routes), changes can be anticipated
and uploaded ahead of time, etc. For the RPKI, one could imagine a
service that would push changes out to RPKI customers, as you suggest.
--Sandy
--
Jakob Heitz.
On Aug 10, 2011, at 6:35 AM, "Montgomery, Douglas" <[email protected]> wrote:
On 8/9/11 9:42 PM, "George Michaelson" <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
