Eric,
More comments in line:
On Nov 16, 2012, at 4:44 PM, Eric Osterweil <[email protected]> wrote:
> Hey Bryan,
>
> Thanks a lot for the comments! My thoughts are inline:
No problem. I'm happy to provide feedback.
>
> On Nov 14, 2012, at 11:29 PM, Bryan Weber wrote:
>
>> I have quite a few questions/statements about this document. If you feel
>> that this list is not the appropriate place to answer them please respond to
>> me at [email protected]. Thanks.
>>
>> *) Aren't the EE certs contained in the Certificate, Manifest and ROA
>> artifacts? Should they be counted as separate items to retrieve?
>
> afaik, EE certs are not contained in manifests. Manifests enumerate things
> like EE certs, but they are separate objects (with a different cardinality).
> I do believe that the cardinality of EE certs is 1:1 with ROAs. Though, they
> are still separately managed objects and have different management overheads
> (like managing crypto information when reissuing, etc).
>
Yes the manifest enumerates the certificates, ROAs and CRL associated with (or
signed by) the certificate, but it also contains an EE cert.
From RFC 6486 that describes the RPKI Manifest:
Every RPKI signed object includes, in the Cryptographic Message
Syntax (CMS) [RFC3370] wrapper of the object, the EE certificate used
to verify it [RFC6488]. Thus, there is no requirement to separately
publish that EE certificate at the CA's repository publication point.
It does recommend a one time use EE cert.
And yes, ROAs do have a 1:1 cardinality with an EE cert assuming a one time
cert as the RFC recommends. The ROA is also a CMS object that always contains
an EE cert. For performance reasons an EE cert could be re-used to prevent the
expensive key generation portion on the crypto side.
>>
>> *) I'm not sure about the status of ghostbuster records today. Has any RIR
>> implemented or deployed them yet? To my knowledge an RPKI repository
>> contains CA certs with RFC 3779 extensions, manifests, CRLs and ROAs.
>> Admittedly I am not familiar with the implementations of all of the RIRs.
>
> Well, I think by the same token, not all ASes have deployed SIA repositories,
> or issued ROAs yet. The goal of the document is to represent a global RPKI
> as prescribed. In the future, if an AS is to run its own SIA (which I
> believe is envisioned to be far and away be the common case), I believe it
> _must_ have a ghostbuster record so that RPs can tell whose Cert they are
> dealing with. There's no other way to (say) find the administrative contact
> for a routing object.
>
Certainly not all of them have. :) But point taken on what you are trying to
accomplish.
>>
>> *) Is there any reason that ARIN's pilot is listed? The service is
>> deprecated and the production system is live at this point. Granted it
>> probably does not have a large volume of data yet.
>
> We only listed the repositories in the the cited presentation, but we felt it
> was important to include them all for completeness and to avoid bias. We
> were trying to be unbiased and use the numbers and measurements that the
> BGPSEC design team has been publicizing. I don't know what their metric was
> for including those measurements, but I suspect others in the wg could
> explain better.
>
OK, so this was just point in time data.
>>
>> *) You note that
>>
>> "In addition, in regards to multihoming, we need one ROA and one EE
>> certificate for each feasible origin for
>> a prefix, yet we will only see on entry in a RIB."
>>
>> but on the other hand because of the maximum length in a ROA I believe that
>> it is very difficult to surmise a relationship between the number of ROAs
>> and the number of entries in the RIB.
>
> It is, admittedly, a rough estimate, and we are totally open to other
> systematic measures. However, to illustrate why it is tough to find a good
> estimate, while some aspects of using the RIB cause this number to seem large
> (as you have stated), consider also that the
> allocation/suballocation/subsuballocation hierarchy requires resource holders
> to issue a chain of certificates (from holder to holder to holder). From
> there, a single entry in the RIB could correspond to multiple allocation
> objects. This would inflate the number of objects, but we didn't see an
> obvious/clean way to estimate this either. As such, we definitely
> acknowledge that this is an imperfect estimator, but we felt it was likely a
> good ballpark. Make sense?
>
I think that a heuristic, like average, is probably the only way this estimate
can be done, but likely we'll need more participation to get enough data for
the average to be statistically significant (my guess). I would also expect to
see a power law distribution here (again my guess).
>>
>> *) Just as a side note, combining tables 1 and 2 might make the data easier
>> to read. In separate tables I am forced to keep find the correlated rows.
>
> Gotcha, thanks.
>
>>
>> *) Just for my own education, what are the router EE certs?
>
> In BGPSEC, each router must be able to sign each update it transmits
> (originates and forwards). The design team seems to have recently
> acknowledged that pushing a single organizational signing cert's private key
> to all routers in (say) a multinational AS could be a security concern. As
> such, each CA can/should have separate EE certs issued for routers, such that
> these certs have their authority delegated from an organizational CA cert.
>
And the intent of the EE cert is to verify the transmitted updates? I'll have
to read up a little more on this side of the specs, but I'm assuming that the
EE private key associated with the EE cert must be kept by the router to sign
the updates? I could be way off base here, I'll go read more like I suggested.
:)
>>
>> *) Another question: should the set of interconnected repositories be
>> considered a directed graph or a tree hierarchy? Since the certs are
>> hierarchical shouldn't the URIs pointing to external repositories be
>> hierarchical as well?
>
> Well, can you be sure that there will be no cycles in this envisioned set?
> I, for example, cannot be sure that an object in one repo does not point to
> an external repo that in turn has an object that does not point back to the
> original. In fact, this issue is mentioned in the RPKI arch RFC (6480) as a
> possibility. Nothing ever goes to plan in the Internet, so I think it is a
> very realistic concern.
>
OK, I see and I agree. I can envision business partnerships that could lead to
this sort of scenario.
>>
>> *) Does cache synching have to be done serially?
>
> I believe the time estimates in the presentation that we cited are actual
> downloads, so I believe this is using whatever the current best practices
> are, though I admit the details were not 100% clear to me.
>
>>
>> If these estimates are accurate then the I think the current expiry periods
>> of manifests in some of the RIRs would be considered woefully inadequate.
>
> Agreed. :(
>
> Eric
Thanks,
Bryan
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
