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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
