A push model is just an idea. It is highly likely to have lots of problems. I haven't thought much about it. Has it come up before and was it discredited? Is it worth developing?
-- Jakob Heitz. > -----Original Message----- > From: Sandra Murphy [mailto:[email protected]] > Sent: Wednesday, August 10, 2011 12:47 PM > To: Jakob Heitz > Cc: Montgomery, Douglas; sidr wg list; George Michaelson > Subject: Re: [sidr] beacons and bgpsec > > 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
