I can think of several possible problems with sticking a ROA in a BGP update.
*) The crypto to validate the ROA must be performed. My third hand knowledge of this is that since this can be expensive the router vendors don't want to do this on the actual routers. Thus the reason for the repository caches in the first place. So this is not a technical reason as much as a real world reason. *) Are ROAs sufficient? What about BGP speaking server certificates or whatever other CMS objects end up being part of BGPSec? For the DDoS example a ROA might be sufficient, but would there be cases where other types of objects should be disseminated via update messages? *) Can a BGP update accommodate the amount of extra data that would be required? *) Finally, an actual technical hurdle. In a hosted model, you might not have the private key for your address allocation. It may be protected and only live in memory on an HSM somewhere… And do you *really* want to share your private key with another company anyway? Just my opinion, but I suspect that a party attempting a hijack would probably be more patient than a legitimate party. The hijacker would care more about being able to take over the traffic successfully as opposed to quickly I suspect. Quick would just be a bonus. The party being DDoS'd on the other hand has financial incentive to alleviate the attack as quickly as possible. Just my 2 cents. -Bryan On Dec 1, 2012, at 10:17 AM, "Montgomery, Douglas" <[email protected]> wrote: > > On 11/30/12 4:19 PM, "Danny McPherson" <[email protected]> wrote: > >> >> On Nov 30, 2012, at 4:08 PM, Christopher Morrow wrote: >> >>> On Fri, Nov 30, 2012 at 3:11 PM, Danny McPherson <[email protected]> wrote: >>>>> limits on its reaction time. Certainly from my perspective, more >>>>> suited >>>>> to pre-publishing preventative data, then creating reactionary data. >>>> >>>> And the state of the art in DDoS mitigation doesn't allow this, period. >>> >>> it sure does, if there's a contract in place... it's the 'oh noz! now >>> we're under attack and need to bring in $DDOSPROVIDER!!' that isn't >>> covered. >> >> Right, IF there's a contract in place.. >> >> Perhaps this new latency will drive folks to be more proactive.. not! >> :-) >> >> -danny > > It is kind of interesting to think about this requirement - the ability to > need to announce a prefix from a new, previously unseen origin, driven by > a previously non-existant business relationship, anywhere in the world > with a moments notice ... This will be a challenge to any system that > where the users of resource certification information caches data from its > authoritative sources. > > It is also interesting to consider that these requirements are basically > the requirements of a hijack, with the exception that some-where, at the > speed of light, some-one declared this one is "OK". > > Not trying to be provocative (dialing that down in general would be a good > thing) ... Just actually trying to think about this as a serious system > requirement. > > Maybe we should have just put the ROA in the BGPSEC update! Call up your > DDOS mitigation provider, give them the private key for your Address > Allocation .. And your done! The new BGP update, contains the ROA. That > is the authorization of the new origin moves at the same speed of the > updates that need it. > > Just and idea. > > 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
