Hi Danny, WG,
People have mentioned that if the security was somehow part of the updates
themselves, then you could have security at the speed of updates. I don't see
how this could work, it would have to be a completely different set of
standards from what's currently being worked on. Most likely this would result
in lots of cycles on routers, but without any concrete proposals on this there
really isn't much more I can sensibly say about this approach here..
So for the sake of argument let me just stick to the model that we have now
where the RPKI is an external system, separate from the BGP updates.
This means that when operators make changes in BGP, they will also need to edit
part of the RPKI.
Chris described a path from roa (or any rpki object) creator to consumer:
On Dec 18, 2012, at 10:52 PM, Christopher Morrow <morrowc.li...@gmail.com>
wrote:
> The architecture as laid out is, from 'roa creator' to 'roa consumer',
> roughly:
> A publication point (nominally one per roa-creator)
> B gatherers (nominally one per roa-consumer)
> C internal-cache-systems (some number per roa-consumer)
> D routers
Strictly speaking there is a step before A: creating the new objects. Dependent
on the system (and especially if a remote pub server is used) there may be a
short delay before the objects are actually published.
But the basic model is right in my opinion. So following Chris's line of
thought:
> (yes, there is the iana->rir part of the tree
> yes, there are are more than just ROAs in the repositories)
>
> So, the part that Randy and Danny and Eric are talking about is, as
> far as the global system, is the A -> B conversation. Once you get
> beyond B (to C and D) the problem is entirely inside some operator's
> network and nothing on the outside matters.
>
> Essentially the problem here is distribution of 10k of data to ~40k
> endpoints (today, it'll grow tomorrow, fine) in ~2 mins time (or 5
> mins or 10 mins or ... someone draw a line in the sand so we know what
> the target is)
I would really like to echo Chris's last paragraph here. What do you think is a
reasonable time to propagate from an operator editing the RPKI (A) -> 99.9% of
Bs?
I understand that half a day is way too long. Instantaneous is theoretically
impossible when BGP and RPKI are separate. But is there really no reasonable
pragmatic indication of what would be 'good enough' for the real world? E.g. if
we can come up with a structure that enables repositories to support 100k RP
tools ('B', assuming 2 gatherers per ASN) getting their *updates* (full dump
separate thread please) every 10 minutes, is that good enough?
Cheers
Tim
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
