Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Yahoo! Lessons Learned

  • From: Kai Schlichting
  • Date: Wed Feb 09 11:03:21 2000

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


Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.