Looks to me that we have an obscurity based 'security' system going on there. The security of the system depends on various net-ops using their skill and judgment to discriminate between purported updates. Such systems tend to fail catastrophically once there is an incentive to attack them. At RSA there was a presentation on security holes in IPSEC and SSH. In the IPSEC case the response 'from the IETF' (i.e. from a well known individual speaking on his own behalf) was that the security issues with using IPSEC without authentication were well known and that this is not new. To which the reply came, well why did you continue to make support for encryption only mandatory? I think we will have the exact same set of events here. The security problems in BGP are well known but nothing will be done to actually fix the running code until there is a disaster. At which point some Kaminsky type will put together an attack that is dismissed by the PR flacks as 'not new', which will hopefully then result in the question 'well why didn't you fix it then'. Novelty is an important trick for the academy. We have to remember that it is not an important objective for engineers. The original objective of the IETF was research. Now we have an entirely different mission - sustaining a network the is critical infrastructure. Yet our design processes are unchanged and we still have no concept of maintenance. There is unfortunately a naive view that we can solve the BGP security issue by simply sprinkling some IPSEC pixie dust on it. I think that view is based on a profound misunderstanding of what is possible with a packet layer security protocol. Key agreement and crypto-packaging are trivial problems that can be solved by a moderately competent grad student. The hard part is the problem that IPSEC never solved, how to establish the trust context. And once you look at that problem you soon realize that IPSEC is the wrong tool entirely as the routing problem requires you to take an accountability approach which in turn requires you to work at the message level. It would be nice to think that we will deal with this problem in some other way than waiting for it to break. But we wont. On Wed, May 6, 2009 at 5:37 PM, john heasley <heas@xxxxxxxxxxxxx> wrote: > Wed, May 06, 2009 at 08:49:42AM +0200, Mans Nilsson: >> > Is the 15ms moritorium excessive? >> >> No. Perhaps even short. A month should be appropriate. Those who update >> their filters based on RIR data with some support system assistance do >> so daily/weekly. Those who have manually updated filters are losing >> this battle already, and those who accept any from any are utterly lost >> (but in this particular instance in ignorant bliss). > > That is the "disservice" that I had in mind. > > ASNs I returned nearly 10 years ago have not been reassigned. Surely > sufficient is far fewer than 10 years. 16 bit exhaustion is magnified by > policy. > >> Only clue helps these cases; no moratorium will ever save them. >> >> -- >> >> _______________________________________________ >> Ietf mailing list >> Ietf@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > -- -- 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