On 11/10/2010 11:55 AM, Sandra Murphy wrote:
Can you say a bit more about how you generated this test data?
Sure. This purpose of this testbed is to make sure BBN's validator is
(1) correct and (2) fast enough to handle ~300,000 objects. Our testbed
generation software automatically constructs one or more statistically
realistic repositories, based on current counts for RPKI certificates,
CRLs, ROAs, and manifests.
We are *not* running up/down software. However, creating parent-child
relationships in a top-down manner necessarily requires us to carry out
similar request/suballocation actions in memory.
The input to our testbed is a specification file that defines (1) the
resources of the trust anchor, (2) a number of CA types and the *amount*
of resources assigned to each type, and (3) the parent-child
relationships + branching factors.
For example (this isn't the exact format and there are more fields, but
it gives you the main idea):
[IANA]
ipv4resources = 0/0
ipv6resources = ::/0
asresources = 1-4294967295
children = 5 * RIR, 1 * MISC
[RIR]
ipv4resources = /8, /8, /8, /23, range(129)...
ipv6resources = /64, /64, /96, ...
asresources = 10, 3, 78, ...
children = 6 * NIR, 200 * LIR, 1 * ROA_TYPE1
[NIR]
ipv4resources = ...
ipv6resources = ...
asresources = ...
children = 100 * LIR, 1 * ROA_TYPE1
[LIR]
ipv4resources = ...
ipv6resources = ...
asresources = ...
children = 3 * ROA_TYPE1, 4 * ROA_TYPE2
[ROA_TYPE1]
...
[ROA_TYPE2]
...
The testbed generation program starts from the trust anchor and
recursively builds an RPKI hierarchy (suballocates resources and
instantiates children), based on the counts and resources defined above.
There can be an arbitrary number of sections, so as we get more
information about how many CAs/resources are out there, we can build a
better simulation of reality.
Currently, the ~12,000 objects at rpki.bbn.com are all valid, and the
BBN validator can process them in under 5 minutes. However, we will be
scaling to ~300,000 in the next few weeks as well as hand-constructing
some error cases such as data mismatch, stale CRL/manifest, out-of-order
certificate arrival, and directory being updated in the middle of an rsync.
-Andrew
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
