North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: [admin] [summary] RE: YouTube IP Hijacking

  • From: Greg VILLAIN
  • Date: Sun Mar 02 11:40:30 2008

On Feb 27, 2008, at 2:09 AM, Adrian Chadd wrote:


(speaking as someone who has built large ACLs/prefix-lists and has
6MB+ configs that can't be loaded on my routers. without vendor support
those that want to do the right thing can't, so the game is lost).

I remember the days of making rtconfig work properly in various
situations (heck, do people still use that? Does it even do IPv6 right?)
and building router configs out of both public and private IRR data.

Perhaps if the entry barrier to building dynamically generated router
configurations were lowered significantly (to the point of it being
free, GUI, and multi-platform) then it may be used for new network
designs by people starting off.

Getting Cisco/Juniper/etc to push -that- as part of their best practices
for network design would be quite helpful.

The problem isn't that the router config is too easy Jared, its that
there's no nice and easy way of doing it right from scratch that matches
the sort of newbie network operators that exist today. For examples
of what "new school" netops are like, visit isp-* lists. There's a lot of
clue there, its just "different" and "haven't learnt from the old school
experience" clue, and its amusing/sad to watch people make the same
mistakes you all did in the 90s. :)

(Where's vijay now when science for generated network configurations
is needed?)

Make the public tools better. Push the tools as best practice.

ADrian

Well there is a slight risk that the more you will improve the automated tools, the less net engineers will actually understand the reasons why it is done...
That being said, all the filtering work is a significant part of every Network Engineer's work, and is not that big of a deal.
Education is the art of repeating, and has always been. I'm not saying we should systematically point the ones making mistakes and make it public, what I'm saying is that the reason why mailing lists such as nanog exist is actually mutual education.

I'm sure the people involved in this incident were (or now are) Nanog readers, and that they've understood the message.

Still, what should be done is, I assume, centralizing the info in one single mail, kept for the record:
- list the incident chronology
- analyze what technical mistake lead to that
- list -all- the ways to prevent it
Another mean of education is including the analysis of this incident (troubleshooting, resolution, implementing means to avoid it) next Nanog agenda, which I already think is the case :)

Greg VILLAIN