Eric
Chris said much better than me. Hosted rpki is like the "go-daddy" of
RPKI. It is intended as a bootstraping solution to take rpki up.
The hosted solution is not aimed to everybody, it is aimed to
small/medium operators that otherwise would struggle to sign their
resources, run a CA, and run a repository.
Large operators DO NOT need to use the hosted solution, they can if
they want but they can run their own CAs and they should.
If a hosted ISP wants to go to up/down and run their own CA they can do
that with a key-rollover and a "make before break" strategy.
About the EE certs for router I didn't explain correctly. Hosted
solution do not have it now because they haven't been defined yet (we
are still arguing about BGPSEC specs). However, in the moment that the
specs are ready router certs will be supported.
Regards,
as
On 06/12/2012 18:56, Eric Osterweil wrote:
>
> On Dec 6, 2012, at 2:33 PM, Arturo Servin wrote:
>
>> Yes, the hosted keep your private key, but you can modify your ROAs
>> anytime you want. At least the hosted systems that I know provide a web
>> interface to do that. The ROA would be published immediately or a few
>> minute/hours later, depending of the rpki-operator (my personal view and
>> with my network operator hat on is that it should be immediately or in
>> minutes).
>
> That's all fine and dandy, and while I agree with what Russ said in his
> response, you should note that I did say, ``no big deal.'' That said, after
> thinking about what Russ said and your response, I actually do think this is
> a big deal... now... ;)
>
> If/when I (as a prospective user of the system) decide to move my information
> from your hostage model to my own repository, how will I be able to migrate
> the private portion of my certificate from _your_ hosted system to my own?
> How are we doing this private key exchange? Do you realize that you won't be
> able to use an HSM at all if the private portion will ever need to be
> exported? Maybe I missed that part of the explanation?
>
>> You could argue that effectively the hosted system "does it for you"
>> and "you require conversation with them", but the way described is a bit
>> misleading because it gives the impression that it is a slow or
>> human-driven process when in reality its not.
>
> Sorry, this was just a colloquialism... Not meant to be misleading. I
> understand that this would likely be a web interface, or whatever. That
> said, in either case, aren't we now saying that for someone to update their
> secure routing information, they need to go through you? Is that a Single
> Point of Failure (SPF)? What if your web interface is being DDoS'ed when I
> need to update my ROA (perhaps because _I'm_ being DDoS'ed and am engaging a
> DDoS mitigation service for the first time)? Anyway, these are (as I said)
> complexities to note....
>
>>
>> As for EE cert for routers those do not exist yet in the rpki-operator
>> systems (AFAIK), so anything here would be a guess.
>
> I seriously disagree here... We are building a system that is intended to do
> this! The rpki must have router certs in it (according to the bgpsec
> design), and we therefore must to be proactive in evaluating that aspect. In
> the above hosted model, you absolutely will be on the hook for this, and if
> you invest in a system whose design will be architecturally (or even
> operationally) unable to accommodate this eventuality, you are doing yourself
> a _huge_ disservice by ignoring the writing on the wall. The bottom line is,
> there needs to be some thinking around this, or it will bite all of us (I
> have packets on the interwebz too).
>
> My 0.02, I worry that your web interface is inadequate for the eventual
> secure provisioning of router certs.
>
> Eric
>
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
