Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)

[Christopher Morrow <[e-mail]>]

(if the ads want off this train, speak up)

On Wed, Apr 11, 2012 at 2:23 PM, Brian Dickson
<[e-mail]> wrote:
> My understanding is, that at least for the origination aspect, the
> "freshness" argument is that the keys get rolled periodically.

they can get rolled periodically, sure. That could be as often as 1/yr
or 1/N yrs... your (operators) choice, within reason... which the mic
discussion also spun around in PAR.

> And this has to occur on all the routers, with new keys published along with
> the key roll, and possibly a unique key per router.

could be per router? per POP? per METRO? per REGION? per Continent?
per Country? per ASN?

> So, the key roll frequency alone, there are operational scalability things
> to be concerned about.

Sure, just like updating prefix-lists for all your customers today...
which L(3) does ~4x/day? NTTA does ~6x/day?

> The keys in question (which go into ee-cert?) have to have private keys on
> routers, and public keys in RPKI, right?
>

Sure, you are updating 2 things here, potentially. Or pulling data
from a single store to put in 2 places (depends on your perspective
and systems/OSS I suppose).

> This isn't a "do it once when you build the router" thing, this is a live
> update of all aspects of the whole system (router + RPKI).

there are 2 systems there... with potentially very different
operational requirements.

we already all manage routers in the field ... this is just another
'prefix-list' or 'acl' or ... (or I hope it's just like that anyway -
see 'stab in eye' vendor comment)

> As in, we should probably take at least some of the time allotted for the
> meta-discussion of, is private/public key really what we should be doing
> here?
> And if so, what are the ways that that can be done, with some analysis of
> scaling factors (order of magnitude at a minimum).
>
> E.g. it is one thing to say "sort the data", and quite another thing to say
> "When you sort the data, be aware that bubble-sort is really a bad idea, and
> quicksort is what you should use for N>6".
>
> (Some thought should be given to comparative analysis of non-PKI crypto
> mechanisms, such as hashing (SHA-256), including security, performance, and
> whether onboarding-offboarding-purging are needed.)

I think that ship sailed... but it seems like a fun list discussion.

-chris

> Brian
>
> On Wed, Apr 11, 2012 at 2:08 PM, Chris Morrow <[e-mail]>
> wrote:
>>
>>
>>
>> On 04/11/2012 01:57 PM, Danny McPherson wrote:
>> >
>> >
>> >> I suppose, to me this looks like any other configuration thing you
>> >> do today on routers... beating the vendor over the head to support
>> >> sane (netconf? maybe?) methods for provisioning, is already done.
>> >
>> > So how we onboard, update, or purge information from RPKI and sign
>>
>> I think there are 2 things here:
>>  1) router-signing-cert (ee-cert?)
>>  2) rpki-digested-data (prefix + origin + cert-sig/etc)
>>
>> they don't have to get to the router in the same way, do they? (I
>> suppose they COULD, but that isn't necessarily mandatory and isn't how
>> it's currently spec'd)
>>
>> > stuff on n routers in z locations that 10's of thousands of others
>> > will evaluate in millions of routers to determine reachability of our
>>
>> wait, now you added a 3rd item:
>>  3) rpki data repository/publication-point
>>
>> > information is relegated to "out of scope" of SIDR?
>>
>> nope, I think the part I was talking about was JUST #1 above. you put
>> that cert on your router in some implementation-specific manner. Does
>> the IETF have to (should it?) state there are some operational security
>> concerns with this? ie: "It is probably a bad idea to copy/paste an
>> unencrypted private key on a telnet session across the open Internet to
>> the router."  (that sort of thing could be placed in the bgpsec-ops doc,
>> it's not there as near as I can tell today).
>>
>> -chris
>> _______________________________________________
>> sidr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidr
>
>
>
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr
>