On 05/04/2012 10:30 PM, Osterweil, Eric wrote:
Well, when u compared the key mgmt that is done today w/ the key mgmt
that will need to be done with bgpsec keys on routers, I think there
was an strained analogy. I'm talking about the latter, but I was
trying to indulge the discussion. ;)
tis late on a friday... and this has a tiny screen... but:
I was under the impression that Danny was originally asking about how to
get the AS or ROUTER key material (used to sign updates as the pass by)
onto the device in question.
Take for example a router of in the disputed territory of crapinderburg:
1) you either shipped a device with a person to install it (or a
person with secure comms and a router arrived separately)
2) that person would install the requisite cert material/key at
installation time.
Alternately that person does basic config (or the device is drop-shipped
with basic config) and a remote/NOC/automation-job does the rest over a
secure (I hope) channel, ie: ssh/scp. This would include installing the
cert/key on the device (in some form of protected storage)
There was mention in danny's note of 'the rpki distribution system...'
and both sandy and I (and randy?) noted that the rpki-to-rtr (or like)
protocol was never meant to handle this sort of thing, that other normal
router configuration/management systems were meant to do it.
Are we crossed up on the rpki-rtr vs 'other means' discussion currently?
For reference, here's danny's quote that got the crossed up conversation
started:
"From there, we can discuss the issue of, for example, HOW TO onboard
and purge signing and validating certificates to routers from the RPKI
[I suspect the intention was to use rpki-rtr protocol for this, but it
doesn't currently support it, nor are the security implications clear]."
-chris
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
