Chris, Rather than waste a lot of time doing a point-by-point response, let's boil this down to the most simple question. Once we get a common understanding on that, we can (hopefully) discuss other points.
First, I understand how the current RPKI is intended to be deployed and operationalized. I also acknowledge the present "capabilities" in the RPKI that we knew about the time RPSEC wound down and SIDR was formed, namely that the RPKI only contains ROA's, and associated certificate material, that is intended to allow 3rd-parties to authenticate a given ASN is "allowed" to originate a given prefix (or, set of prefixes, i.e.: /16 upto /24). However, and here's the key part, in my understanding all RPKI material (namely, ROA's and associated certificate material) is carried around "out-of-band" amongst a hierarchy of 'commodity' servers from IANA -> RIR's -> LIR's/ISP's. At present, there's two things SP's may do to get that material from those servers into their routers, (doing the actual forwarding): 1) "Pull Model": Routers can use draft-ietf-sidr-rpki-rtr-07 to pull RPKI info from the RPKI servers and absorb it into their configuration; or, 2) "Push Model": Operators can (re-)use their existing tool-chains, if they so desire, to push information from the RPKI servers into their routers using existing BGP policy-statements/route-maps applied to eBGP sessions that have existed for several years. Either of those models will work. However, and again here's the key point, either of the above are *not* forcing any RPKI information, (in particular ROA's, certs, CRL's, etc.), in BGP transport sessions. IOW, BGP continues to blindly (and, quickly) pass around forwarding information and it's up to [very simple] policy on each router to decide whether to accept or reject that forwarding information as "legitimate". OTOH, if my understanding of this draft is correct, we're talking about moving away from that and carrying not just forwarding information, but also certs and possibly other RPKI material, etc.? Why? Or, more importantly, why is that a MUST? Why can't additional RPKI material, (e.g.: beyond ROA's), continue to be pulled or pushed into routers as I outlined above, (in particular Model #2)? On Feb 11, 2011, at 13:37 MST, Christopher Morrow wrote: > On Fri, Feb 11, 2011 at 10:51 AM, Shane Amante <[email protected]> wrote: >> Randy, >> >> On Jan 30, 2011, at 20:40 MST, Randy Bush wrote: >>>> 3.3 As cryptographic payloads and loading on routers are likely to >>>> seriously increase, a BGPsec design may require use of new hardware. >>>> It must be possible to build routers that do BGPsec with within >>>> acceptable (to operators) bounds of cost and performance. >>>> >>>> This should be left out of any requirements document, and various >>>> proposed system compared based on their costs and deployment >>>> difficulty. >>> >>> i take your point. the intent was that compatibility with current >>> hardware abilities is not a requirement that this document imposes on a >>> solution. it is quite likely that provider routers will need crypto >>> assist and more ram. though one hope that the stub customer edge will >>> not. >> >> Whoa there. I couldn't disagree more wrt the above. >> >> First, let's start with the most fundamental question. Why is it that >> routers MUST sign, pass >> around and verify _in-band_ in the control plane various contents/PDU's >> _within_ BGP? Note my >> very careful use of the work _in-band_. By that I mean inside the BGP >> session itself, not on a -shane _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
