On 11/30/12 2:00 PM, "Danny McPherson" <[email protected]> wrote:
> >On Nov 30, 2012, at 1:37 PM, Montgomery, Douglas wrote: > >>> >>> The RPKI needs to react in seconds, rather than minutes, hours, or >>>days. >> >> Based upon what analysis or requirement? > >Good question Doug. > >Today I have a requirement as an operator to mitigate DDoS attacks in >seconds to single digit minutes and this commonly requires routing system >changes that may not have been envisioned beforehand - hours and days of >delay [imposed by a system that does little more than control what's >routed - not if it's routed in a way I believe is secure] breaks this. I for one have long recognized that the current proposed system may have limits on its reaction time. Certainly from my perspective, more suited to pre-publishing preventative data, then creating reactionary data. The question is if there is consensus on the use cases like those above, if it is impossible to pre-publish the potential origination ROAs before their need/use, and if not, could the system be made more reactive and at what other scaling cost? Remember a ROA is an authorization to originate, not a declaration that is currently happening. If the business relationships that bring customers to your DDoS mitigation service are established at a slower rate, might one pre-publish the necessary ROAs? > >Where are the requirements that informed the current design? My own opinion is ... The observation that ResCerts are inherently linked to the business process of number resource allocation, and the time scales that operators seemed comfortable in current systems that construct policy from out of band data sets. RPKI should be able to move faster than those current processes. Also a personal opinion, but I am not sure that policy systems that operate much much faster than the underlying processes/human systems they are linked to, is necessarily a good thing. I hear lots of operator feed back on relative comfort levels of things becoming "too automated". Dougm > >-danny _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
