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

[Christopher Morrow <[e-mail]>]

On Tue, Apr 10, 2012 at 9:15 PM, Danny McPherson <[e-mail]> wrote:
>
> On Apr 10, 2012, at 8:56 PM, Christopher Morrow wrote:
>
>> yes, my goal was to have updated the wiki today at the office, work
>> intruded... tomorrow I'll do that with some more content for each
>> item, and hopefully better coordinates as well for the location.
>
> Thanks.

I think the 2 above items are done... please have a look when you get
some time, comments/questions welcome.

>>> Also, are we collecting requirements for these (e.g., object scale, RPs, etc..)?  Basing these discussions on requirements that exist somewhere already?  Or simply discussing solutions that have already been developed and deployment experience?  If the latter, then we can we ensure we reference and prepare to discuss what requirements drive to the development of those solutions?
>>>
>>
>> I think the only bit in the 3 that has a current 'requirements'
>> discussion is the 'freshness' (item 2). The first item 'deployment
>> discussion' is really a discussion of:
>>  "Should there be some document that describes the top N (3?)
>> deployment scenarios && where should that document/presentation/etc
>> live?" (I suppose implicit in that is 'requirements for format,
>> content, intended audience')
>
> I was thinking more simply along the lines of "a fully deployed RPKI today would have o objects and r RPs a c churn and we ought to ensure our designs accommodate that" -- only then can we have a reasonable discussion on, e.g., data freshness?  What have we based these design goals on thus far - do we have a stable reference for this?
>

hopefully this is captured in the wiki update.

> 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].
>

The rtr cert/ee-cert part was never planned/designed to be done via rpki-rtr.
Ideally at provisioning time your ee-cert is dropped onto the box,
similar to base-config today. Potentially your fav vendor has a
methodology in their plan for this. I can't imagine it's too tough,
nor that it's exact specification needs to be in an IETF doc (since it
seems implementation specific). Could be wrong though.

> Only when we get to that point will we really begin to understand the dynamics of RPKI and it's employment for secure routing (well beyond "authorized" origin policy configuration), and the impact of rate+state in both the RPKI and it's effectuating in the routing system, and perhaps most importantly, the inter-dependencies between the two (even basic stuff like the rate of updates from an RPKI cache to a router in a fully loaded system given today's RPKI object counts).
>

sure, some modelling seems like a good thing here, I think this was
asked for at the mic in PAR as well, no? (in response to some
discussions with Sriram?)

>>> Also, it looks to me like we're in dire need of a charter update...
>>
>> for which? (I didn't think that any of the 3 items was actually
>> outside of the current charter)
>
> I meant the goals and milestones, apologies for not being clear.

we can chat about that on-list or in the meeting... I suppose there's
a slew of milestones which are 'complete', there aren't really any
changes (that I planned) from an 'adding things' perspective. The
ops-documentation (see wiki) to me is probably NOT an ietf document,
again happy to talk at the meeting about that though.

-chris