- NANOG - lists.nanog.org

Re: Hi, we're from the government and we're here to help
by Sean Donelan 11 Mar '00

11 Mar '00

On Fri, 10 March 2000, "Kelly J. Cooper" wrote: > THEN the next big thing comes along, people get scared, the > consortia suddenly get well-attended, NEW groups spring up, > the community starts complaining again and the cycle is > renewed. That is, until people get bored again, or budgets > change or the NEXT big thing that comes along has nothing > to do with security. > > This cycle is old. I know I'm bored with it. A very good summary of past cycles. There is no lack of groups. But I certainly don't have time or funding to attend meetings of all these groups, or even the groups that will have me as a member. And I definitely don't think the solution is creating yet another group. > So now what? > > How do you propose to cull the wheat from the chaff? Get all > the right information about what ISPs are trying to do, and > going into the lab to test, and researching into the right > ears (of other ISPs)? How are you going to get the right > people to speak and the wrong people to shut up for a few > minutes? > > Because if it was just as easy as kicking in a few bucks to > yet another consortium, I'd do it in a heartbeat. I think a paid professional secretariat is mandatory. But costs a lot of money. It can't be a stand-alone consortium, but must be part of a larger industry group to handle the inevitable cycles of interest. It must be composed of a critical mass of industry. Groups with less than a thirty or so members tend to stagnate. -- What I do on my days off http://www.irishparade.org/ or spot me on the webcam broadcast at http://www.iwannasee.com/

1 0

Re: Hi, we're from the government and we're here to help
by Kelly J. Cooper 11 Mar '00

11 Mar '00

On Mar 10, 9:57am, Patrick Greenwell wrote: > Subject: Re: Hi, we're from the government and we're here to help * *On 9 Mar 2000, Sean Donelan wrote: * *> The US Government as been amazingly pro-active in this area, or at least *> some small groups have been. They've also consistently said the government *> can't protect the Internet. The infrastructure is owned by private companies *> and individuals; and industry has to work together to protect it. *> *> The question is does industry think its worthwhile to work together? * *Funny you should ask that. There was a lot of discussion on Bugtraq *recently about the attacks and from those discussions another list was *started to discuss formation of an "Assocation of Responsible Internet *Providers" (ARIP(a)SECURITYFOCUS.COM) Discussion ensued regarding what the *organization should be doing. There seemed to be general agreement *on the idea of first creating a NOC<->NOC communication *protocol/procedures(this is at the people layer, not the technical *layer.) I suggested that the group develop a charter, form a 501(c)(6), *elect officers, obtain D&O insurance and then proceed. I also stated that *any such venture was going to require very real money to accomplish, and *asked if there was anyone willing to put their money where there mouth is, *and monetarily contribute to such a venture(I offered to put up a few *hundred dollars.) * *Suddenly, the list got very, very quiet. In fact, since I posted that *message, there hasn't been a single post to the list. Emperically, this *suggests to me that while everyone is quick to spend countless *hours expressing an opinion on mailing lists, there is nobody willing to *invest in making this happen. People who coordinate these kinds of consortia do so on a practically full-time basis if they want to get anything done. Asking someone who already has a full-time job (and if it has anything to do with security, several full-time jobs and a bad case of paranoia) to take on that level of additional involvement could be considered prohibitive. If a specific ISP sponsors the group, what's to stop the rest of the world from accusing that ISP of bias? Same issue with a vendor. The problems of anti-trust are very serious in this arena. If you have an elected board doing volunteer work and meeting on a periodic basis to discuss security, you suffer from the same problem of resources without someone more dedicated to sheparding the process along. Everybody wants a NDA (Non-Disclosure Agreement), but their NDA has to look like THIS while the other ISPs want the NDA to look like THAT. If the government sponsors the group, they can circumvent the anti-trust issue, but the gov't doesn't ever seem to be happy about just letting things be. Everything has a tendency to become a political pawn. There's a very real possibility that gov't sponsorship of a group trying to set standards for work and incident response could evolve into the basis for regulation. The "r" word frightens everyone in the ISP industry, so no one's taking a proposal to D/ARPA (whichever they are this week) to convince them that this is a good idea. The "r" word frightens a lot of people in gov't as well - many don't want the added overhead of another regulated industry. The gov't has created a bunch of crisis centers (like NIPC) who won't/can't sponsor an ISP Consortium, but want to be invited to one if it happens. You have CERT, keeping things close the vest unless you establish a long-term relationship with them. You have SANS, trying to be an industry leader but maybe getting lost in all the noise created by BUGTRAQ and NT BUGTRAQ and the CVE and the Abuse newsgroups and the Abuse mailing lists and ALL the OS security warnings and ALL the Firewall security warnings and the MAPS RBL and the ORBS list and NANOG and the IETF (particularly the GRIP working group) and the FBI's INFRAGARD every freakin' person who stands up and claims to be a security expert who wants things done HIS way or his university's way or his consortia's way and ON AND ON. So you have places like CNRI (a non-profit organization which sponsors the XIWT, aka the Cross-Industry Working group, which spawned IOPS, the Internet Operators Consortium) and ICSA (a for-profit organization which sponsors a bunch of consortia, but most relevant here they sponsor ISPSEC, the ISP Security Consortium). Both charge a certain amount of money for membership & they try and get things done, but their efforts are often met with jeers from the community (in fora like, OH I DUNNO, NANOG?) because their consortia cost money, so they aren't open to everyone, so they couldn't possibly provide an accurate representation of the community. But they aren't the only groups out there. There are others. However, there are only so many of us who go to these things - and we can't spend all of our time going to meetings or we become useless, not having time to do our jobs and stay in the loop and able to contribute. All the groups suffer from the same problems - they slack off, lose funding, re-invent themselves, start some new subgroup, try to drum up interest, etc. Because sustained volunteer work is HARD. If you don't think it's hard, then you don't have enough to do. THEN the next big thing comes along, people get scared, the consortia suddenly get well-attended, NEW groups spring up, the community starts complaining again and the cycle is renewed. That is, until people get bored again, or budgets change or the NEXT big thing that comes along has nothing to do with security. This cycle is old. I know I'm bored with it. So now what? How do you propose to cull the wheat from the chaff? Get all the right information about what ISPs are trying to do, and going into the lab to test, and researching into the right ears (of other ISPs)? How are you going to get the right people to speak and the wrong people to shut up for a few minutes? Because if it was just as easy as kicking in a few bucks to yet another consortium, I'd do it in a heartbeat. Kelly J. -- Kelly J. Cooper - Internet Security Officer GTE Internetworking - Powered by BBN - 800-632-7638 3 Van de Graaff Drive Fax - 781-262-2819 Burlington, MA 01803 http://www.bbn.com

2 1

The CIDR Report
by Bandy Rush 11 Mar '00

11 Mar '00

I generally follow my habits of not leaving my office until I receive my weekly copy of the CIDR report. I havent received one in a few weeks, and I need to go home to change clothes. With that being said, I have generated the below CIDR report. -BR This is a MANUALLY-generated mail on Fri Mar 10 19:25:00 PST 2000 It is not checked before it leaves my Commodore64. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of deaggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Losses by deaggregating at the origin AS level This lists the "Top 30" players who if they decided to deaggregate their announced classful prefixes at the origin AS level could make a significant difference in the expansion of the current size of the Internet routing table. This calculation does not take into account the exclusion of holes when deaggregating so it is possible even larger routing tables should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of additions. 3) Interesting deaggregates Interesting here means a deaggregate made as a set of funkadelic routes. Thanks to yahoo.com for giving me access to their services once aday. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of the REAL CIDR report. ------------------------------------------------------------------------------ CIDR REPORT for 10Mar000) General StatusTable History -------------Date Prefixes180200 72321190200 72203200200 72346210200 72296 220200 72419230200 72364240200 72455250200 72608 of the table history.Possible Bogus Routes--------------------- *** Bogus 0.0.0.0 from AS701*** *** Bogus 10.0.0.0/8 from AS31337*** AS Summary----------Number of ASes in routing system: 6762 Number of ASes announcing only one prefix: 3701 (2011 cidr, 1690 classful) Largest number of cidr routes: 198774 announced by AS701 Largest number of classful routes: 8891009 announced by AS701 1) Gains by aggregating at the origin AS level --- 10Mar00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS4200 167 104 63 37.7% AGIS (Apex Global Information Ser **Dont worry, their address space will be returned in a few weeks...** _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

1 0

Whereis the CIDR report?
by Jeffry Roberts 11 Mar '00

11 Mar '00

Anyone know? Two weeks in a row now. How else am I supposed to know when it's friday? J/K, I really do like to browse through it though. Jeff

2 1

Fiber Cut?
by John Fraizer 11 Mar '00

11 Mar '00

Anyone know anything about a fiber cut between Chi<->SF/San Jose? John Fraizer EnterZone, Inc

1 0

Re: Here we go again
by brandon＠rd.bbc.co.uk 11 Mar '00

11 Mar '00

> What can you do? I would say "not much"- Tailor your output, too many requests for same page from same address gets a larger proportion of adverts on the page. May as well make some money off them, choose adverts for whatever it is they're protesting against then you can sell premium highly targeted ads. brandon

6 8

Re: Hi, we're from the government and we're here to help
by Sean Donelan 10 Mar '00

10 Mar '00

On Thu, 09 March 2000, Randy Bush wrote: > actually, in working with the other large providers, i have not found this > to be the case. and most smallish folk seem cooperative. it is usually the > middle sized folk who have not scaled to meet the problems, and occasionally > let things fall through the cracks. The key is the ability to reach the right person. In a small provider its easy because the boss answers the phone, or someone who knows the boss answers the phone. In a large provider, you might know a "famous" person. And even though they won't be the right person, they'll know the right person. If AT&T does something stupid, Randy might call Steve Bellovin (the wrong person) who in turn could hit the right manager over the head with the clue-by-four. Replace with the appropriate provider/person UUNET/Mike O'Dell, Verio/Randy Bush, etc. The problem is with providers without famous people and too many people, so they don't know each other. If you don't already know someone at, for example, NTT or BT or Qwest, navigating through their public contacts usually doesn't get you too far. What may be interesting is looking at how other industries handle the problem. In the banking industry, where failure to contact another bank can result in millions of losses, Thompson Publishing has an extensive directory of the security contacts for essentially every bank in the world. Thompson actively verifies the contact information, and banks pay a bunch of money for current copies of the directories. In the chemical industry, where failure to respond to a leak can result in millions in liability, the chemical manufactures' association maintains a 24-hour number which will contact the appropriate company's response group. Again, the contact information is actively verified.

6 5

Re: Here we go again
by Scott Solmonson 10 Mar '00

10 Mar '00

What can you do? I would say "not much"- Assuming you truly cannot separate out the "legitimate" requests- Your choices are left to these: Bleed off all traffic above the POP's allowed levels- Increase capacity- Employ a distributed caching system- That's about it as far as I can see. "Scott McGrath" wrote: > > What to we need to do to nip this one in the bud > > "Henry R. Linneweh" wrote: >> >> If this is the case then lets kick butt now >> before they have a chance to start >> >> ?Hactivists? plan DDoS Web attack >> Electrohippies? software could be as effective as >> distributed denial of service tools used in last >> month?s Web attacks. >> http://www.msnbc.com/news/380065.asp?cp1=1 -- Scott Solmonson Speedera Networks Inc. -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* scosol(a)speedera.com / 408.970.1591

1 0

Here we go again
by Henry R. Linneweh 10 Mar '00

10 Mar '00

If this is the case then lets kick butt now before they have a chance to start Hactivists plan DDoS Web attack Electrohippies software could be as effective as distributed denial of service tools used in last months Web attacks. http://www.msnbc.com/news/380065.asp?cp1=1 -- Thank you; |--------------------------------------------| | Thinking is a learned process so is UNIX | |--------------------------------------------| Henry R. Linneweh

3 2

Network Probes
by Scott McGrath 10 Mar '00

10 Mar '00

Hi, Has anyone else noticed probes against their network with a spoofed source address and Src (80) and Dst(2183) ---Snip. Mar 8 17:40:16: %SEC-6-IPACCESSLOGP: list 110 denied tcp 216.52.56.50(80) (Ser ial0 *PPP*) -> 216.64.1.198(2183), 1 packet .Mar 8 17:44:28: %SEC-6-IPACCESSLOGP: list 110 denied tcp 208.194.150.10(80) (S erial0 *PPP*) -> 216.64.1.142(2183), 1 packet .Mar 8 17:45:45: %SEC-6-IPACCESSLOGP: list 110 denied tcp 216.52.56.50(80) (Ser ial0 *PPP*) -> 216.64.1.198(2183), 3 packets .Mar 8 17:49:45: %SEC-6-IPACCESSLOGP: list 110 denied tcp 208.194.150.10(80) (S erial0 *PPP*) -> 216.64.1.142(2183), 2 packets .Mar 9 07:39:04: %SEC-6-IPACCESSLOGP: list 110 denied tcp 209.143.228.10(80) (S erial0 *PPP*) -> 216.64.1.82(2183), 1 packet .Mar 9 07:44:18: %SEC-6-IPACCESSLOGP: list 110 denied tcp 209.143.228.10(80) (S erial0 *PPP*) -> 216.64.1.82(2183), 9 packets .Mar 9 09:53:46: %SEC-6-IPACCESSLOGP: list 110 denied tcp 209.185.181.10(80) (S erial0 *PPP*) -> 216.64.1.227(2183), 1 packet .Mar 9 09:59:24: %SEC-6-IPACCESSLOGP: list 110 denied tcp 209.185.181.10(80) (S erial0 *PPP*) -> 216.64.1.227(2183), 9 packets .Mar 9 12:11:55: %SEC-6-IPACCESSLOGP: list 110 denied tcp 10.2.1.6(80) (Serial0 *PPP*) -> 216.64.1.144(1319), 1 packet .Mar 9 12:17:29: %SEC-6-IPACCESSLOGP: list 110 denied tcp 10.2.1.6(80) (Serial0 *PPP*) -> 216.64.1.144(1319), 8 packets .Mar 9 12:22:30: %SEC-6-IPACCESSLOGP: list 110 denied tcp 10.2.1.6(80) (Serial0 *PPP*) -> 216.64.1.144(1319), 4 packets ---snip Thanks

4 5