[admin] [summary] RE: YouTube IP Hijacking

Sun Mar 2 16:29:07 UTC 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