[27103] in North American Network Operators' Group
Re: Yahoo! Lessons Learned
daemon@ATHENA.MIT.EDU (Kai Schlichting)
Wed Feb 9 10:59:09 2000
Message-Id: <4.2.2.20000209103452.00dbf7f0@mail.speedus.net>
Date: Wed, 09 Feb 2000 10:57:27 -0500
To: nanog@nanog.org
From: Kai Schlichting <kai@pac-rim.net>
In-Reply-To: <38A0E6B2.D596079D@senie.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Errors-To: owner-nanog-outgoing@merit.edu
At Tuesday 11:01 PM 2/8/00 , Daniel Senie wrote:
>Please refer to RFC2644/BCP34 on the subject of directed broadcasts.
>This RFC recommends router vendors disable directed broadcasts by
>default. It also recommends ISPs disable directed broadcast on ALL
>routers. In light of the recent events, it would be good to see a
>concerted effort made by everyone to ensure this has been done.
I recall that SprintLink had some, uhm, plans to put ingress (and
egress?) filters on all interfaces facing dedicated customers that
were not multi-homed. This came after realization that education of
the end-user was a fruitless and herculian task: Network smarts
are virtually non-existent in IT departments, and even loads of
smaller ISPs everywhere. Whatever became of this project ?
At what traffic level (across the entire box) do Cisco 7{0;2;5}00
routers with RSP{2;4} cards fall over and die because of CPU load?
>Of course as Paul has mentioned, we wrote RFC 2267 several years ago to
>address this very issue. I strongly encourage folks to take a hard look
>at ingress filtering. Hardware vendors have implemented features in
>dialup servers and routers which can help.
Without wanting to bash my favorite NAS vendor: I have asked for
'ip verify unicast reverse path' in their boxes as much as
2+ years ago. They recently admitted to having no record of this
request, and it has just now become a request for engineering.
Vendors do not have their focus on security, just like most
everyone else in the Internet "industry". Skating on thin ice
has a price...
>While implementing these measures may not directly benefit your network,
>doing so may thwart an attack against someone else's net. Tomorrow, the
>roles could be reversed. As with many areas of managing the Internet,
>cooperation is key.
Like the kind of cooperation that is making people close their open SMTP
relays voluntarily because closed relays are A Good Thing <tm> or
are a BCP? That always and only worked with threats of loss of connectivity
or humiliation through public exposure. Some networks have taken it upon
themselves to shield their customers from such well-deserved scrutiny
from the outside (Hi Dave!).
Nothing will change until Yahoo decides that the legitimate operators of
the Trinoo/Tribe/whatever slaves have acted with reckless neglect by not
keeping their system secured with vendor-issued patches.
But when they do, duck and cover for the wave of lawyers hitting like an
Ion-storm.
bye,Kai
