Let's not pick apart the strawman details of an abstract idea. One could imagine aspects of an approach that only adds one sig to an udpate, signed by the prefix owner, not the first hop AS .. I.e., not an entire ROA CMS object. One could imagine this as and optional way of doing this for emergency announcements, with the existing approach being done for the vast, vast majority of updates, etc.
The real high level point is one way of dealing with a requirement where authorization must move at the speed of updates, is to include the authorization in the update, when necessary. Clearly that will have trade offs. The points you make below would have to be considered *if* someone actually fleshed out that idea ... dougm On 12/1/12 10:48 AM, "Bryan Weber" <[email protected]> wrote: >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. That is if the hijack needed a persistent address. If it just needs to be on the net long enough to do something specific, then maybe not. dougm > >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
