On Sat, May 23, 2009 at 5:52 AM, Iljitsch van Beijnum <iljitsch@xxxxxxxxx> wrote: > [belatedly] > > On 12 mei 2009, at 21:42, Phillip Hallam-Baker wrote: > >> As for adding IPSEC to BGP, I would not want to comment on the >> competence of the person involved. > > We need to replace the MD5 hack with IPsec, because MD5 doesn't have any DoS > potection, crypto algorithm agility or key rollover mechanisms. But of > course that only protects your BGP sessions, not the content of the > information in those sessions. We should replace the MD5 hack with something that makes for easier management. It is somewhat disturbing to be reading specs that only support one algorithm with a reference to a paper describing how that algorithm was broken. >> In particular I find it utterly unbelievable that large backbone >> corporation A is going to configure its border routers to simply >> accept routing information from large backboe corporation B. If I was >> responsible for large corporation A then every piece of external >> routing data would be funnelled into a control center and the edge >> routers would only respond to control instructions from the control >> center. No matter what specifications and standards might opine, that >> is how I would run my network. > > Sounds like a plan. Now explain to us how your control center knows which > routing information is valid and which isn't? You have in the order of 30 > seconds to decide for every update before your customers start to complain > that "the internet" is broken. 30 seconds sounds a reasonable response time to aim for. Central control need not be a single centralized control room. In fact much better it is not. Rather what you want is to have centralized policy development and localized enforcement. But I think we need to restate the problem. We don't need to prove that the information is valid so much as determine whether it is likely to break things or not. This looks much more like a spam filtering type problem to me than pure access control. So a first cut we might make on the data is to identify route advertisements that are within previously established 'normal' bounds. We do not need to vet every route advertisement, we only need to look at those that are 'surprising'. Something of this sort must be taking place already since each network has to decide whether to (1) use the new route itself and (2) send out updated advertisements itself. Having reduced the volume of routes to those that represent 'surprises' we have a problem that cannot be solved for the individual route announcement in isolation. Like the spam problem we can only evaluate routes by bringing in additional information to bear. In particular we need to know if the routes that we are attempting to use are connecting to the valid endpoints or not. We do not need to do that for every route advertisement, just as we do not need to content analyze every potential spam. We can also use reputation. But we do need a source of grounding data if we are going to use reputation. Traditional route analysis has to work with the IP level data that is exposed in the current day Internet. That is fine provided that you are not under attack from an intelligent adversary. Simply sending out a bogus BGP announcement is not going to allow you to perform a long term DDoS attack. The route is going to be quickly discarded if there is nothing there to connect to. So in summary, I think that to solve the BGP issue we need to look up the stack as well and work out methods that allow for reliable reporting of attack conditions. -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf