Danny,
On 2013-03-18 10:47, Stephen Kent wrote:
There are at least two issue here: how quickly a new/changed ROA is
published
after it is created/modified, and how quickly one should expect all
RPs to have acquired this info. The RPKI propagation model for ROAs was
based on the observation that, typically, the binding between an
address space holder
and the AS originating routes to that space changed very
infrequently, and
not very fast. Conversations with RIR staff supported this notion,
based on
IRR DB experience. So, suggesting that this data needs to be
propagated in
minutes, vs. 1/2 a day, is quite a change.
No, it's not.
My comment applies to the statement about the frequency with which IRR
DB entries, some of which are
very analogous to ROAs, change. Your assertion (below) might be that
folks who do not rely on these
dabatases accept changes in asserted prefix/ASN bindings at the speed of
routing updates. I
agree with that observaiton, but note that it's also what made the
Pakistan Telecom vs. YouTube
incident possible.
The system converges at the speed of routing today, if I have to wait
12 hours to mitigate an attack for someone then that could be a
problem. If the RIR's actually conducted any qualitative study to this
effect I'd appreciate a reference - I've seen none. However, I can say
for certain that there are many companies that need "minutes" of
convergence, just like they have today, else they won't be able to
perform things like DDoS mitigation for hours or longer, and that's
not acceptable to many current operations. We have a business that
utilizes this today.
You cite DDoS mitigation as _an_ example, whereas it seems to be more
_the_ example. Also, it's not clear
that asserting a new origin AS for a target of such an attack is the
only way to deal with the problem,
just the way that it is performed today, for ASes that do not make
arrangements in advance to counter
such attacks.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr