(no hats today!) 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
(note this probably strays a tad from 'requirements', I think there's also some utlity coming from the RPKI that's NOT necesarily ) One way I looked at this was that if the router that originates a route today slaps an ASN on, no one is the wiser as to where/what originated the actual route. A router in the middle of AS701 can announce a route origined AS7018... if you look closely the route looks 'odd' but other than that it's all good. Signing, in the case of origin validation, the route on the origin router (or from the origin ASN border router(s) ) means that you can say with some certainty that: 1) the route was originated by the owner of the certificate for that ASN 2) the owner of that ASN cert lost his/her private key :( Hopefully it's more 1 than 2... and hopefully if 2, the owner CRL's the cert 'quickly'. Regardless downstream ASN's can say: "Yes, I see that route is origined by AS701, she signed the route for us, w00t!" Ideally with origin-validation + prefix-lists and as-path filters you have better assurance that the route you see is really from that origin. With the addition of RPKI data you should be able to query the IRR, join that against the RPKI and create a concise prefix-list that doesn't include legacy data users never cleaned out :( For some period of time the best part of this should be the RPKI data for use in making the prefix-list stuff better/faster/cleaner. I think what's also missed some in the discussions is that prefix-list + as-path filters (+ other things you already do as a provider to protect yourself from naughty customer devices) will continue to live on. > side-band channel like RPKI and/or IRR is used today. While I have grave > concerns over in-band > signing & verification, I am [much] less concerned about the latter for > several reasons. With > respect to in-band: > > 1) I'm extremely concerned over dependencies of automatically "trusting" > signed data in-band > within the control plane and not being able to reach servers (RP's?) to > verify the contents of the > PDU's are legitimate. At least with prefix-filters and/or AS_PATH filters, > it's very easy for me to > manually disable some or all filtering for particular destinations in order > to, say, get reachability to > servers (RP's) to verify the authenticity of data. The architecture should provide, or the design includes the provision, to have the data as close to your router(s) as you think is relevant. It also includes the ability to NOT validate, or decide to do nothing with the validation state info. Additionally, the routers keep a local cache of the data that the RPKI global system contains (minus some skew perhaps)... In a fresh-boot scenario you most certainly won't have rpki data to use, you'll just not-validate data from your customers until you have that data. Keep in mind though that the RPKI data has helped you to build prefix-list/as-path filters so hopefully it's not all sunk :) you can accept what prefixes you should expect from your customer(s) and pass those along as normal. Later, once security-data is available to you, you can start verifying that the announcements you see are valid. some more discussion of cold-start is necessary, and some ideas in the -ops doc(s) will be helpful surrounding this (cold-start) and placement of caches inside a network. (outlining the tradeoffs of distance from the router who needs to use the cache) > > 2) Related to point #1, we really should go back to first principles ask > ourselves if we're really > intending to conflate the _transport_ method (BGP) with the requirement to > verify the data > _inside_ of BGP. If so, what is the reason? Is it solely for convenience, > (because BGP transport > is already there), or other reasons? I think, that today you receive a route in BGP, you believe it's proper and pass it on. you have no real way to tell if the route was originated by the ASN in the first (last? right-most) AS hop, you have no real assurance that the prefix-list you used to fllter the route is actually correct, and you have no understanding of the path seen in the as-path aside from what the text says. (see pilosov/kopella) > > 3) I really, really don't like the idea of "will need crypto assist and more > ram" on my RE/RP's for > several reasons, namely: > a) It's one more set of variables that my already over-worked Capacity > Planning and NOC > groups need to keep track of and attempt to stay ahead of. > b) It's extremely costly to upgrade RE/RP's, because said RE/RP's are > only available from one > source -- equipment vendors. And, the upgrade paths typically don't buy you > much in terms of > more CPU, etc., because vendors are obligated to source "established" > components they know > they'll be able to acquire for several years into the future. And, worst of > all, the cycle to get those > RE/RP's into the network is extremely long when you start to consider the > budgeting, testing of > new code, physical installation, customer disruption during maintenance > windows, etc. > ... at least with respect to (b), if I were able to use offboard CPU (i.e.: > Intel/AMD servers, like in > the RPKI/IRR world), then I have a much larger selection of HW to choose from > and I can > upgrade those in the network much, much more quickly. Some of the 'more ram, 64-bit os, faster-cpu, crypto-offload' non-worry for me was that both large vendors stated: "We are working toward 64-bit OS, ability to have much more RAM on board and faster CPU's. If you think crypto-offload is helpful, we can add that as well in the right rev of device/card/etc" I am under the impression that if we believe the ability of SIDR output (rpki + protocol changes) to be used in ~7-10 years, I think we made this timeline based on normal cycle times for routers in larger networks. I hope that in the next rev or so of gear everyone buys we'll see capacity for RAM increase, crypto-help (* if necessary) and faster/more cpu. I believe both large vendors are on track to provide 64-bit OS's soonish as well. > At least with respect to #1 and #2, I don't see any discussion of the above > in the current draft > (although maybe I missed it?). But, IMHO, those are _fundamental_ > requirements that need to > be discussed among the WG. Before touching on any of the other points in > Russ White's e-mails > in this thread, (which I agree with), I think it's important to get back to > basics. what would you add to the reqs draft? (some example/short text to be fleshed out, bullets?) >> and the operators with whom we discussed (note that i am an operator, >> not a vendor with a bad habit of speaking for operators) this thought >> that this needed to be said from both ends of the scale. we did not >> want the future security constrained by a 7200, nor did we want an >> explosion in costs. as dollars are the bottom line in our capitalist >> culture, constraining them seems quite reasonable. > > It wasn't discussed with me. :-) wanna discuss it now? -Chris > > -shane > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
