On Mon, Feb 14, 2011 at 12:07 PM, Shane Amante <[email protected]> wrote: > 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. >
sounds great. > 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, I think not 'configuration' but 'on router cache' - akin to a dns-cache... > 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. > yup, 'make me a prefix-list' > 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)? roa's don't end up in bgp even in the case of this draft, nor do certs. 'signed updates' do. An optional-transitive attribute is one model to look at using for this, I think. I think the reasoning behind carrying a signature (well, adding a signature at each AS-hop) is so you can see that the AS in the path has actually seen this announcement. The presence of the signature data and your router checking that ends with (as the draft says) "valid" or "invalid", you can choose to do something with that in your local bgp policy, for example: route-map bloop permit 10 match validity-state valid set localpref 100 route-map bloop permit 20 match validity-state invalid set localpref 5 I don't want to see certs or roas shipped in bgp either, shipment of that data remains in the rpki 'system'. -Chris > > 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
