Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-23.txt

[Danny McPherson <[e-mail]>]

On Jan 12, 2012, at 2:11 PM, Randy Bush wrote:
> 
> i think so, but i am a bit worried as about this waterboarding stuff.

I think simple things like asking that rpki-rtr connection-oriented 
transport require protections is reasonable in 2012, particularly
given that the current specification is unsigned prefix,origin 
binding data (i.e., otherwise no object or transport protections).

> i think the norm is to get some experience with v0 (the protocol version
> number in the pdus, a la bgp_4_) before going to v1.  but, as with most
> things, i could be wrong.

This is important.  If you just needed origin,prefix bindings in 
soft-state in the router there are lots of ways you could do that
today without a new protocol (to include with BGP itself).  

If the objective is to use rpki-rtr protocol to onboard actual rpki-rtr
data into the router control plane, e.g., to accommodate 
requirements by BGPSEC, then getting those rpki-derived signed 
blobs in the router is a much higher frequency function and may 
well justify some new onboarding protocol.  

> as i have no idea how to factor a document or how much lead time
> factoring takes, even if i knew when v1 could be out which i don't, i
> would not be able to answer.

Cute...

If you were designing rpki-rtr protocol to load rpki data into routers 
(rtrs) then before standardizing rpki-rtr protocol it would seem to me
we should fully consider at least the initial use case that justifies a 
brand new protocol -- before we 'augment' it with new lego blocks.

If not, then I suggest to the WG that we require a proposal from 
the bgpsec-protocol team for how they intend to accommodate 
their own requirements to onboard this data before we continue 
that work.

> perhaps a focus on engineering, as opposed to mis-guessing and impugning
> others' motives, would be productive.

Which portion am I mis-guessing here, can you be specific? Is the 
BGPSEC design team NOT intending to use rpki-rtr protocol to get
RPKI-derived signed blobs on the router in order to enable BGPSEC?
Your own presentations in operations fora suggestions your thinking 
is rather evolved already in this area.

Attempting to assemble the legos blocks in sidr land and determine 
what the implications might be for operations at the end of the day is 
indeed engineering and architectural in nature, do you disagree?
Should we not be considering and questioning the systemic and 
inter-dependencies these new standards introduce?

> in the current taxonomy, there are three pieces, the rpki, rpki-based
> origin validation, and then path validation.  rpki-rtr as it stands is
> part of origin validation, and the docs for origin validation are going
> through the sausage machine now.  path validation is in early to mid
> design, documents are in high flux or unwritten, and are nowhere near
> ready to be considered sausage.

Perhaps we need to do some architectural work then, and not build 
blocks that are supposed to be pieced together without some amount
of systemic consideration.

Let me give you a simple example..  We're saying RPKI needs 
algorithm agility.  If RPKI was fully deployed, and BGPSEC was 
deployed, and rpki-rtr were used to onboard BGPSEC-required 
signed blobs as specified in the BGPSEC protocol document, 
e.g., S.5 of bgpsec-protocol I-D, then during algorithm rollover 
would the following potentially be required:

1) many  more RPKI objects
2) many more RPKI-derived signed blobs the relying parties (routers) 
    potentially need to onboard via rpki-rtr and store in soft-state
3) more BGPSEC signed data in the routing system
4) more churn in all the elements that rely in RPKI data in subsequent 
    periodic updates, "beacon" functions, etc.
5) BGPSEC speakers as relying parties would need to consider 
    algorithm suites from either new or old algorithms when performing 
    validation from independent certificate hierarchies
6) some other stuff, I suspect.

I think it's all of the above, but I may very well be wrong and I 
don't have this all figured out..  I do know that there are systemic 
implications of many of these things, particularly in concert.

I think consideration of these issues, i.e., the systemic implications 
of a set of assembled lego blocks is within the purview of both the 
iEtf and this WG.   

-danny