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
