Re: AOL Orders the Spam Special
Henry Linneweh <[EMAIL PROTECTED]> wrote: > And just when things looked dismal this had to happen to make it > more so > http://www.washingtonpost.com/wp-dyn/articles/A1898-2004Jun24.html?referrer=email And for those of us who either don't want to give their first born to read it and/or find that their overreliance on Javascript "validation" means it's not possible to register, what does the article actually say? -- I like children. If they're properly cooked. - W.C. Fields
Re: Attn MCI/UUNet - Massive abuse from your network
- Original Message - From: "Dr. Jeffrey Race" <[EMAIL PROTECTED]> To: "Smith, Donald" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, June 24, 2004 6:22 PM Subject: RE: Attn MCI/UUNet - Massive abuse from your network > > On Thu, 24 Jun 2004 21:39:26 -0600, Smith, Donald wrote: > > >I am not a lawyer. I am not aware of the law that requires uunet to > >go to court to prevent spammers who are not their direct customers from using > their network. > > > Doctrine of attractive nuisance When I worked for IBM back in the '60s, on many occasions during my 7 years there I heard upper management say that they were proud to be with a company that tried to be a "Good Corporate Citizen ". One branch manager had a cube on his desk which had printed on each side the(ir) manifesto of Corporate Social Responsibility. >From the AOL theft article: "The revelations come as AOL and other Internet providers have ramped up their efforts to track down the purveyors of spam, which has grown into a maddening scourge that costs consumers and businesses billions of dollars a year." Perhaps those Corporate Citizens who can do something to ensure the viability of E-mail, should. --Michael
Looking Glass Wiki
Since I've been hitting a lot of looking glass sites on traceroute.org lately that no longer worked, I decided to make my own list in wiki form. That way, as links drop off the face of the earth, or as new looking glass pages turn up, the community can edit the wiki page to keep it current. If anyone is interested, its at http://www.bgp4.net/cgi-bin/bgp4wiki.cgi?Looking_Glasses_Wiki and currently lists well over 200 looking glasses.
Re: Looking Glass Wiki
Janet, all, FYI Traceroute.org is updated approx once a month, most of the input is based on user feedback these days since automated checking is usually rejected by a lot (most) webmasters in order to prevent automated querries so I get a lot of false positives. Also, since quite a few of these services are maintained by engineering teams they tend to go offline for hours/days/weeks/months but are valid URLs. Thomas Traceroute.org - Original Message - From: "Janet Sullivan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 25, 2004 12:23 PM Subject: Looking Glass Wiki > > Since I've been hitting a lot of looking glass sites on traceroute.org > lately that no longer worked, I decided to make my own list in wiki > form. That way, as links drop off the face of the earth, or as new > looking glass pages turn up, the community can edit the wiki page to > keep it current. > > If anyone is interested, its at > http://www.bgp4.net/cgi-bin/bgp4wiki.cgi?Looking_Glasses_Wiki and > currently lists well over 200 looking glasses.
The Cidr Report
This report has been generated at Fri Jun 25 21:43:33 2004 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
18-06-04138004 95920
19-06-04138130 95941
20-06-04138165 95988
21-06-04138209 96029
22-06-04138290 96187
23-06-04138373 95506
24-06-04137840 95574
25-06-04137983 95562
AS Summary
17400 Number of ASes in routing system
7055 Number of ASes announcing only one prefix
1420 Largest number of prefixes announced by an AS
AS7018 : ATTW AT&T WorldNet Services
54042880 Largest address span announced by an AS (/32s)
AS721 : DNIC DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 25Jun04 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 138030955644246630.8% All ASes
AS6347 926 162 76482.5% SAVV SAVVIS Communications
Corporation
AS18566 7248 71698.9% CVAD Covad Communications
AS4134 740 160 58078.4% CHINANET-BACKBONE
No.31,Jin-rong Street
AS4323 738 205 53372.2% TWTC Time Warner Telecom
AS7018 1420 978 44231.1% ATTW AT&T WorldNet Services
AS7843 511 128 38375.0% ADELPH-13 Adelphia Corp.
AS6197 704 324 38054.0% BNS-14 BellSouth Network
Solutions, Inc
AS701 1275 913 36228.4% UU UUNET Technologies, Inc.
AS22909 393 34 35991.3% CMCS Comcast Cable
Communications, Inc.
AS9583 460 120 34073.9% SATYAMNET-AS Satyam Infoway
Ltd.,
AS27364 376 38 33889.9% ARMC Armstrong Cable Services
AS6198 568 232 33659.2% BNS-14 BellSouth Network
Solutions, Inc
AS22773 388 64 32483.5% CXAB Cox Communications Inc.
Atlanta
AS1239 949 642 30732.3% SPRN Sprint
AS11172 353 56 29784.1% Servicios Alestra S.A de C.V
AS17676 339 50 28985.3% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS4355 381 99 28274.0% ERSD EARTHLINK, INC
AS9929 314 33 28189.5% CNCNET-CN China Netcom Corp.
AS6478 320 53 26783.4% ATTW AT&T WorldNet Services
AS6467 289 36 25387.5% ACSI e.spire Communications,
Inc.
AS14654 2396 23397.5% WAYPOR-3 Wayport
AS25844 243 16 22793.4% SASMFL-2 Skadden, Arps, Slate,
Meagher & Flom LLP
AS6140 387 165 22257.4% IMPSA ImpSat
AS3356 899 681 21824.2% LEVEL3 Level 3 Communications
AS4766 479 264 21544.9% KIXS-AS-KR Korea Telecom
AS2548 362 165 19754.4% ATCW Allegiance Telecom
Companies Worldwide
AS2386 425 229 19646.1% ADCS-1 AT&T Data
Communications Services
AS5668 385 196 18949.1% CIH-12 CenturyTel Internet
Holdings, Inc.
AS6327 218 34 18484.4% SHAWC-2 Shaw Communications
Inc.
AS14824 278 103 17562.9% NCC-105 NewSouth
Communications Corp.
Total 16083 6194 988961.5% Top 30 total
Possible Bogus Routes
24.138.80.0/20 AS11260 AHSICHCL Andara High Speed Internet c/o Halifax
Cable Ltd.
24.246.0.0/17AS7018 ATTW AT&T WorldNet Services
24.246.128.0/18 AS7018 ATTW AT&T WorldNet Services
64.46.4.0/22 AS11711 TULARO TULAROSA COMMUNICATIONS
64.46.12.0/24AS7850 IHIGHW iHighway.net, Inc.
64.46.27.0/24AS8674 NETNOD-IX Netnod Internet Exchange Sverige AB
64.46.34.0/24
Re: Looking Glass Wiki
Thomas Kernen wrote: Since I've been hitting a lot of looking glass sites on traceroute.org lately that no longer worked, I decided to make my own list in wiki form. > FYI Traceroute.org is updated approx once a month, most of the input > is based on user feedback these days since automated checking is > usually rejected by a lot (most) webmasters in order to prevent > automated querries so I get a lot of false positives. Also, since > quite a few of these services are maintained by engineering teams they > tend to go offline for hours/days/weeks/months but are valid URLs. First, let me say that traceroute.org is a wonderful site. I have no desire to pull all of it into wiki format. All I am interested in are the looking glasses and route servers. Since there are only a few hundred of these, I'll still be able to hand check them every few weeks. Also, being a wiki, users will be able to update the entries themselves. Thanks for all the hard work you to on traceroute.org. I really appreciate and use it a lot.
Re: Attn MCI/UUNet - Massive abuse from your network
> From the AOL theft article: > "The revelations come as AOL and other Internet providers have > ramped up their efforts to track down the purveyors of spam, which > has grown into a maddening scourge that costs consumers and > businesses billions of dollars a year." Interesting. An insider at a network operator steals a copy of some interesting operational data and sells it to a 3rd party with an interest in doing nasty things with said data. And if Homeland Security really does require all outages to be reported to a clearing house where only network operations insiders can get access to it, then what? Will someone sell this to a terrorist organization? Better to leave all this information semi-public as it is now so that we all know it is NOT acceptable to build insecure infrastructure or to leave infrastructure in an insecure state. Fear of a terrorist attack is a much stronger motive for doing the right thing than a government order to file secret reports to a secret bureaucratic agency. --Michael Dillon
RE: Attn MCI/UUNet - Massive abuse from your network
Michael, I agree totally. Every ISP I know of is working to combat spam. They all have a staffed abuse desk. They all coordinate with other ISP's that is one of the reasons I joined this list. I believe its time to move this to the next level. Follow the money. When you see spam report it to the abuse team for the isp the spam came from AND report the advertiser (follow the link in the spam) to their ISP. Getting the advertiser ($$$) site shutdown will be more effective then getting the trojaned/botted/infected pc disabled. When spam is no longer a profitable method of advertisement then it will end. Till then we will continue to see virii and worms add proxy ports to allow the spammers 1000's of points to bounce their spam off of. [EMAIL PROTECTED] GCIA I reserve the right to be wrong but don't exercise it too often. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Michael Painter > Sent: Friday, June 25, 2004 4:11 AM > To: [EMAIL PROTECTED] > Subject: Re: Attn MCI/UUNet - Massive abuse from your network > > > > - Original Message - > From: "Dr. Jeffrey Race" <[EMAIL PROTECTED]> > To: "Smith, Donald" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Thursday, June 24, 2004 6:22 PM > Subject: RE: Attn MCI/UUNet - Massive abuse from your network > > > > > > On Thu, 24 Jun 2004 21:39:26 -0600, Smith, Donald wrote: > > > > >I am not a lawyer. I am not aware of the law that requires uunet to > > >go to court to prevent spammers who are not their direct > customers from using > > their network. > > > > > > Doctrine of attractive nuisance > > When I worked for IBM back in the '60s, on many occasions > during my 7 years there I heard > upper management say that they were proud to be with a > company that tried to be a "Good Corporate Citizen ". > One branch manager had a cube on his desk which had printed > on each side the(ir) manifesto of Corporate Social Responsibility. > > From the AOL theft article: > "The revelations come as AOL and other Internet providers > have ramped up their efforts to track down the purveyors of > spam, which > has grown into a maddening scourge that costs consumers and > businesses billions of dollars a year." > > Perhaps those Corporate Citizens who can do something to > ensure the viability of E-mail, should. > > --Michael > > > > >
Re: Teaching/developing troubleshooting skills
>>> Pete Kruckenberg <[EMAIL PROTECTED]> 6/24/04 5:09:19 PM >>> >It's been so long since I learned network troubleshooting >techniques I can't remember how I learned them or even how I >used to do it (so poorly). > >Does anyone have experience with developing a >skills-improvement program on this topic? I find that it's helpful to teach troubleshooting in two stages: 1) Define the problem. 2) Isolate the problem For stage one, teach them the basic skillset needed to define the issue in a general way based on available information. Is a circuit obviously down? Are certain destinations unreachable? Are *all* destinations unreachable? Is network access slow? You get the picture. Once the nature of the problem is determined, I find that a layered approach to troubleshooting is helpful and that is what I teach to others. The exact order of steps might changed based on information learned in step one, but generally I work my way up the OSI model. If the problem could possibly be caused by a physical layer issue, try to determine such. Check the circuits for errors, bouncing links, indications of mismatched clocking configurations, faulty CSU/DSUs, faulty router interfaces, or bad cabling. If all of that appears to be okay then I consider the datalink layer. Could the problem defined in step one be caused by a datalink layer issue? Was the encapsulation changed on a router interface? If frame relay, is the router seeing LMI from the frame relay switch? Is there evidence of dropped frames completely within the cloud (granted, that's not necessarily datalink layer, but it is a separate 'administrative' layer if it's out of your control.) I'm sure you can think of a number of other examples. Could the problem defined in step one be the results of a network layer issue? Is there evidence of a routing loop? Do the devices involved have routing tables that appear to be correct? What do traceroutes and pings show? Teach them to go hop-by-hop and verify that everything appears as it should, starting with the device closest to the problem if it's possible to narrow it down that far. If routing is determined to be correct, could this be a transport layer issue? Is it possible that an access list or firewall somewhere is blocking only certain types of traffic? Does the problem only involve HTTP? SMTP? Is there policy routing involved that might be redirecting certain types of traffic to the wrong destination? Where there *any* recent configuration changes? If so, what were they? Find out, because they might be the cause of the problem. This is the general framework I use for troubleshooting and that's how I've taught the people that work with me. It's constantly evolving and, of course, the specific steps taken depend on the nature of the issue, but I find that it helps to have a good foundational troubleshooting framework. John --
Re: Attn MCI/UUNet - Massive abuse from your network
Well said sir! Scott C. McGrath On Fri, 25 Jun 2004 [EMAIL PROTECTED] wrote: > > > From the AOL theft article: > > "The revelations come as AOL and other Internet providers have > > ramped up their efforts to track down the purveyors of spam, which > > has grown into a maddening scourge that costs consumers and > > businesses billions of dollars a year." > > Interesting. An insider at a network operator steals > a copy of some interesting operational data and sells > it to a 3rd party with an interest in doing nasty things > with said data. > > And if Homeland Security really does require all outages > to be reported to a clearing house where only network > operations insiders can get access to it, then what? > Will someone sell this to a terrorist organization? > > Better to leave all this information semi-public as > it is now so that we all know it is NOT acceptable > to build insecure infrastructure or to leave infrastructure > in an insecure state. Fear of a terrorist attack is > a much stronger motive for doing the right thing > than a government order to file secret reports to > a secret bureaucratic agency. > > --Michael Dillon >
Re: AOL Orders the Spam Special
On Thu, Jun 24, 2004 at 09:54:14PM -0700, Henry Linneweh wrote: > > And just when things looked dismal this had to happen > to make it more so > > http://www.washingtonpost.com/wp-dyn/articles/A1898-2004Jun24.html?referrer=email http://bugmenot.com/view.php?url=washingtonpost.com -Setzer
Re: Attn MCI/UUNet - Massive abuse from your network
Has anyone noticed that the DHS plan is probably closer to the current status of things than the FCC one is? AFAIK, Currently this information _isn't_ required to be publicly reported. The FCC wants it to be. DHS would prefer that it be semi-public at best - just like Michael Dillion wants. Three options: 1. Status quo - no gov't reporting requirements 2. FCC proposal - completely public reporting requirements 3. DHS proposal - limited access reporting requirements Food for thought: Could an analyst, looking at outage reports over a period of time, build a schematic that would demonstrate that if you took out n points, you'd kill x% of data traffic in and out of $pickyourmetropolitanarea? If this analyst were working for Bin Ladin Some ad hoc terrorists, in a country crawling with US troops, with a communications infrastructure nowhere as advanced as the USA just managed to coordinate a multiple bomb attack simultaneously. What could they do here with the right information? Should we hand them this information freely? At least if someone in this "clearing house" sells it to the terrorists, they will have had to work for it a bit, instead of having us hand it to them on a silver platter, as the FCC seems to want. Let the flames continue. ** Reply to message from Scott McGrath <[EMAIL PROTECTED]> on Fri, 25 Jun 2004 11:22:51 -0400 (EDT) > Well said sir! > > Scott C. McGrath > > On Fri, 25 Jun 2004 [EMAIL PROTECTED] wrote: > > > > > > From the AOL theft article: > > > "The revelations come as AOL and other Internet providers have > > > ramped up their efforts to track down the purveyors of spam, which > > > has grown into a maddening scourge that costs consumers and > > > businesses billions of dollars a year." > > > > Interesting. An insider at a network operator steals > > a copy of some interesting operational data and sells > > it to a 3rd party with an interest in doing nasty things > > with said data. > > > > And if Homeland Security really does require all outages > > to be reported to a clearing house where only network > > operations insiders can get access to it, then what? > > Will someone sell this to a terrorist organization? > > > > Better to leave all this information semi-public as > > it is now so that we all know it is NOT acceptable > > to build insecure infrastructure or to leave infrastructure > > in an insecure state. Fear of a terrorist attack is > > a much stronger motive for doing the right thing > > than a government order to file secret reports to > > a secret bureaucratic agency. > > > > --Michael Dillon > > -- Jeff Shultz A railfan pulls up to a RR crossing hoping that there will be a train.
RE: Unplugging spamming PCs
What I am proposing is have a registry that you must register with before other mail servers will accept mail from you. Similar to how MAPS RBL works, but the mail server itself, enforces it, rather than a firewall or a ancillary device ACL. This could be made a standard of SMTP. LP Best Regards, Larry Larry Pingree 408-543-2190 "Visionary people, are visionary, partly because of the great many things they never get to see." - Larry Pingree -Original Message- From: Joe Shen [mailto:[EMAIL PROTECTED] Sent: Thursday, June 24, 2004 6:36 PM To: Larry Pingree Cc: [EMAIL PROTECTED] Subject: RE: Unplugging spamming PCs Hi, >Mail servers should be registered just like domains and shutdown by a >registrar if they are misusing their registered services. This really >needs to be handled by a multi-lateral legal solution, industry will not >fix it alone. No, I don't think this is good solution First of all, we could not ask customers to register everything they planned with leased line without legal reasons. Second, if I hire DSL/leased_line service from ISP and set up domain name for myself, ISP could not ask me to tell them which port should be opened as I'm not taking a firewalling service, I'm not a member of my service provider. I should be able to do anything that are not perhibited by law or affact someothers. Blocking_port_25 indicates ISP pre-assume that customers will SPAM their network. But, SPAMmer is just a very small group of people. Maybe most of them comes from other countries ( what happens in China). To me, the proper way of anti-spam may ask cooperation between ISPs and Email service providers. Anyway, strengthening anti-spam ability in Email server is a must. regards Joe > >LP > >Best Regards, > >Larry Cool Things Happen When Mac Users Meet! Join the community in Boston this July: www.macworldexpo.com
Re: Unplugging spamming PCs
Larry Pingree writes on 6/26/2004 12:11 AM: What I am proposing is have a registry that you must register with before other mail servers will accept mail from you. Similar to how MAPS RBL works, but the mail server itself, enforces it, rather than a firewall or a ancillary device ACL. This could be made a standard of SMTP. That's great. Let's all return to the good old days of X400 and UUCP -- suresh ramasubramanian [EMAIL PROTECTED] gpg EDEDEFB9 manager, security and antispam operations, outblaze ltd
RE: Attn MCI/UUNet - Massive abuse from your network
At 04:00 PM 6/24/2004, Hannigan, Martin wrote: > >On Thu, 24 Jun 2004, Ben Browning wrote: > this discussion anyways, is access to the internet. When the > actions of a > downstream damage that product(IE more and more networks > nullroute UUNet > traffic), [ Operations content: ] Do you know of any ISP's null routing AS701? ISPs? Not of the top of my head. I know several businesses who have, and a great many people who have blocked UUNet space from sending them email, either by using SPEWS, the SBL, or mci.blackholes.us . ~Ben --- Ben Browning <[EMAIL PROTECTED]> The River Internet Access Co. WA Operations Manager 1-877-88-RIVER http://www.theriver.com
Re: Attn MCI/UUNet - Massive abuse from your network
** Reply to message from Brad Knowles <[EMAIL PROTECTED]> on Fri, 25 Jun 2004 18:14:43 +0200 > At 8:44 AM -0700 2004-06-25, Jeff Shultz wrote: > > > At least if someone in this "clearing house" sells it to the > > terrorists, they will have had to work for it a bit, instead of having > > us hand it to them on a silver platter, as the FCC seems to want. > > Not true. If the information is forced to be completely in the > open, then everyone knows it's not insecure and no one depends on the > fact that it was supposed to be kept secret. This is a case where > you are more secure the more open the information is -- indeed, as we > are in most cases, which is why we have the age-old security mantra > of "security through obscurity is not secure". > Do you realize that the basic element of security, the password, is based on the entire premise you just dismissed? And yet we still use them - and depend on the fact that they are supposed to be kept secret. The problem with being totally open about infrastructure is that there are some vulnerabilities that simply cannot or will not be fixed - wires sometimes have to run across bridges, redundant pumping stations are too expensive... in these cases is it not better to hide where these vulnerabilities are? The problem with your point is that even if the information is forced to be completely in the open, that is no guarantee that it will be fixed, and people _do_ depend on this stuff, regardless of its reliability or security. Do you really think that if we publish all the insecurities of the Internet infrastructure that anyone is gonna stop using it, or business, government, and private citizens are going to quit depending on it? Security through obscurity is not secure - but sometimes it's all you have. -- Jeff Shultz A railfan pulls up to a RR crossing hoping that there will be a train.
Re: Attn MCI/UUNet - Massive abuse from your network
> Food for thought: Could an analyst, looking at outage reports over a > period of time, build a schematic that would demonstrate that if you > took out n points, you'd kill x% of data traffic in and out of > $pickyourmetropolitanarea? > > If this analyst were working for Bin Ladin Yes an analyst could do this. Our job is to make sure that he can't get a very large x% without also requiring a large investment in n attack points. Consider bin Laden's organization in 2000. They had a plan to commandeer 10 airliners and attack 10 targets in the USA including things like the CIA headquarters. Resource constraints caused them to back off to 4 targets. We already win because the targets are not all in the same city block. Next, the attack day arrived and the 4 teams went to work. But only two of them achieved 100% objective. One team failed entirely when they lost control of their weapon. And the third team hit a glancing blow to the target that damaged less than a fifth of the building. And it turned out that they hit a less critical part of the Pentagon as well. This is a typical result of a military or terrorist operation. It is very hard to plan and execute 100% effective coordinated attacks against a large number of targets. On 9/11 the terrorists had no problem making 4 big booms and getting attention. But they missed the Whitehouse entirely and only did minor damage to the military headquarters. Remember, that packet switched networking originated with the desire to build a telecom network that could survive massive destruction on the scale of a nuclear war, but continue to function. If we apply that kind of thinking to planning network deployment then there should be little extra risk from terrorist knowing where the vulnerable points are. Spread the risk by spreading the vulnerable points. > Some ad hoc terrorists, in a country crawling with US troops, with a > communications infrastructure nowhere as advanced as the USA just > managed to coordinate a multiple bomb attack simultaneously. Iraq currently has a cellphone network that is more advanced than the USA, i.e. it's all GSM. But in fact, all they really needed to pull this off was a quiet pub and some accurate watches that could be synchronized prior to the attacks. Better go back and watch those old spy movies again... --Michael Dillon
Re: Attn MCI/UUNet - Massive abuse from your network
** Reply to message from [EMAIL PROTECTED] on Fri, 25 Jun 2004 17:12:45 +0100 > Remember, that packet switched networking > originated with the desire to build a telecom > network that could survive massive destruction > on the scale of a nuclear war, but continue to > function. If we apply that kind of thinking to > planning network deployment then there should be > little extra risk from terrorist knowing where > the vulnerable points are. Spread the risk > by spreading the vulnerable points. I thought the old "nuclear survivable" argument was killed off years ago - I seem to rember it being refuted in "Where Wizards Stay Up Late." Packet switched networking originated with a desire to see if it would work And you are welcome to assume the expense of spreading the vulnerable points. -- Jeff Shultz A railfan pulls up to a RR crossing hoping that there will be a train.
Re: Attn MCI/UUNet - Massive abuse from your network
[EMAIL PROTECTED] wrote something like: > Some ad hoc terrorists, in a country crawling with US troops, with a > communications infrastructure nowhere as advanced as the USA just > managed to coordinate a multiple bomb attack simultaneously. I just got back from lunch at the Wok Inn (Morrill's Corner, in scenic Portland), where a fortune cookie museum has been added to educate the stand-and-waits like me. In the 13th century the dynasty established by Ghengis Khan was overthrown by a synchronized distributed program. The synchronization mechanism was "on date/time execute plan", and the distribution mechanism was moon cakes. This whole thread is wierd. A tunnel in Baltimore isn't exactly a big secret anymore, and we did cover this (knowing, unknowing, and mechanism considered harmful) in the RAVEN list that lead up to rfc2804. Oh, the "crawling with US troops" line of thought is wicked wrong. For the few who care, point a browser at juancole.com from time to time and read a week or so of content. Cheers, Eric
Re: Attn MCI/UUNet - Massive abuse from your network
Jeff Shultz wrote: ** Reply to message from Brad Knowles <[EMAIL PROTECTED]> on Fri, 25 Jun 2004 18:14:43 +0200 At 8:44 AM -0700 2004-06-25, Jeff Shultz wrote: At least if someone in this "clearing house" sells it to the terrorists, they will have had to work for it a bit, instead of having us hand it to them on a silver platter, as the FCC seems to want. Not true. If the information is forced to be completely in the open, then everyone knows it's not insecure and no one depends on the fact that it was supposed to be kept secret. This is a case where you are more secure the more open the information is -- indeed, as we are in most cases, which is why we have the age-old security mantra of "security through obscurity is not secure". Do you realize that the basic element of security, the password, is based on the entire premise you just dismissed? And yet we still use them - and depend on the fact that they are supposed to be kept secret. The problem with being totally open about infrastructure is that there are some vulnerabilities that simply cannot or will not be fixed - wires sometimes have to run across bridges, redundant pumping stations are too expensive... in these cases is it not better to hide where these vulnerabilities are? Not really. Security through obscurity in some circumstance can help, but rarely when it comes to something like that. When it comes to wires crossing a bridge or pumping stations, anyone who tries hard enough will find out pretty easily. You end up with two groups knowing where the vulnerabilities are, the handful of "good guys" who oversee the resources and the bad guys. It strikes me as similar to the outcry from the locksmith community when the vulnerabilities of various master key mechanisms were widely published. Who knew about the vulnerabilities? The "good guy" locksmiths who used the vulnerabilities to break into your office when you lost your keys (and sold you the locks) all knew, and the bad guys who broke into your office to steal stuff knew. Who didn't know? The consumer who was unable to make an informed decision about the security of the various choices of key-lock mechanisms he had available. So the problem with the pumping station or the wires over the bridge are that the limited number of experts know, the bad guys know, but other people who should know (the network engineer judging the reliability of his links or the civil engineer deciding the capacity for an emergency water tower for an industrial site) may not understand the true vulnerability of the system. But that doesn't mean we shouldn't put a fence around the pumping station or a padlock on the door because a key is just "security through obscurity" through some convoluted logic. The problem with your point is that even if the information is forced to be completely in the open, that is no guarantee that it will be fixed, and people _do_ depend on this stuff, regardless of its reliability or security. Somethings cannot be and should not be "fixed." Making the public water supply invulnerable to earthquake damage is not practical. Individuals have the responsibility (even if most don't) to keep a few days supply of potable water available in the inevitable, but unlikely on any given day, event of a powerful earthquake. Making various infrastructure invulnerable to every foreseeable, let alone unforeseeable, attack is not practical either. But those who are affected by the failure of any piece of infrastructure need to know how reliable it is and plan accordingly. Do you really think that if we publish all the insecurities of the Internet infrastructure that anyone is gonna stop using it, or business, government, and private citizens are going to quit depending on it? Of course not. But they may be better able to quantify their risks in depending on the 'Net and make contingency plans where it is prudent. The real world is about risk management; even the US federal government has given up on a risk avoidance model and moved to risk management. Security through obscurity is not secure - but sometimes it's all you have. But it is worse than nothing when you obscure the truth from people who should know. If the vulnerability is exploited, the impact is worse than if those who should have known had had the ability to plan for the contingency. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Attn MCI/UUNet - Massive abuse from your network
>Do you really think that if we publish all the insecurities of the >Internet infrastructure that anyone is gonna stop using it, or >business, government, and private citizens are going to quit depending >on it? That is a totally foolish statement in today's world. The incentive for fixing the problem is going to be the competition's ability to say that they do not suffer from the specified problem. Market forces will push on the area of problem and force a solution. To take away the exposure limits the incentive to fix the problem. Companies are not going to spend $$ on something that does not directly effect the income. Reporting your problems to someone who doesn't effect the income isn't going to result in the fixing of any problems. One only has to look at the telephone history to see that. Jerry
RE: Attn MCI/UUNet - Massive abuse from your network
On Fri, 25 Jun 2004, Ben Browning wrote: > At 04:00 PM 6/24/2004, Hannigan, Martin wrote: > >[ Operations content: ] Do you know of any ISP's null routing AS701? > > ISPs? Not of the top of my head. I know several businesses who have, and a > great many people who have blocked UUNet space from sending them email, > either by using SPEWS, the SBL, or mci.blackholes.us . Do these people know how much legitimate email they're missing, for every spam message that's blocked? I noticed that from my personal mailbox (which I do filter with spam assassin), for every one legit mail that gets blocked/tagged by SPEWS, there's maybe 1-2 junkmails. Thats not a very impressive ratio...
RE: Attn MCI/UUNet - Massive abuse from your network
I think that is a bit irresponsible for the simple reason that MCI has many co-lo clients and any of their machines could be vulnerable, I think also that needs to addressed so that blanket statements are supported by fact and not the need to competitively break a company down in hopes the you can steal away it's customer base -Henry --- "Tom (UnitedLayer)" <[EMAIL PROTECTED]> wrote: > > On Fri, 25 Jun 2004, Ben Browning wrote: > > At 04:00 PM 6/24/2004, Hannigan, Martin wrote: > > >[ Operations content: ] Do you know of any ISP's > null routing AS701? > > > > ISPs? Not of the top of my head. I know several > businesses who have, and a > > great many people who have blocked UUNet space > from sending them email, > > either by using SPEWS, the SBL, or > mci.blackholes.us . > > Do these people know how much legitimate email > they're missing, for every > spam message that's blocked? > > I noticed that from my personal mailbox (which I do > filter with spam > assassin), for every one legit mail that gets > blocked/tagged by SPEWS, > there's maybe 1-2 junkmails. Thats not a very > impressive ratio... > >
Re: Looking Glass Wiki
I noticed that recently on Geektools also and that needs to updated and or fixed -Henry --- Janet Sullivan <[EMAIL PROTECTED]> wrote: > > Thomas Kernen wrote: > > >>Since I've been hitting a lot of looking glass > sites on traceroute.org > >>lately that no longer worked, I decided to make my > own list in wiki > >>form. > > > FYI Traceroute.org is updated approx once a > month, most of the input > > is based on user feedback these days since > automated checking is > > usually rejected by a lot (most) webmasters in > order to prevent > > automated querries so I get a lot of false > positives. Also, since > > quite a few of these services are maintained by > engineering teams they > > tend to go offline for hours/days/weeks/months > but are valid URLs. > > First, let me say that traceroute.org is a wonderful > site. I have no > desire to pull all of it into wiki format. All I am > interested in are > the looking glasses and route servers. Since there > are only a few > hundred of these, I'll still be able to hand check > them every few weeks. > Also, being a wiki, users will be able to update the > entries themselves. > > Thanks for all the hard work you to on > traceroute.org. I really > appreciate and use it a lot. >
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to [EMAIL PROTECTED] If you have any comments please contact Philip Smith <[EMAIL PROTECTED]>. Routing Table Report 04:00 +10GMT Sat 26 Jun, 2004 Analysis Summary BGP routing table entries examined:142373 Prefixes after maximum aggregation: 85321 Unique aggregates announced to Internet:68213 Total ASes present in the Internet Routing Table: 17497 Origin-only ASes present in the Internet Routing Table: 15162 Origin ASes announcing only one prefix: 7068 Transit ASes present in the Internet Routing Table: 2335 Transit-only ASes present in the Internet Routing Table: 73 Average AS path length visible in the Internet Routing Table: 4.9 Max AS path length visible:26 Illegal AS announcements present in the Routing Table: 8 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 19 Number of addresses announced to Internet: 1314051868 Equivalent to 78 /8s, 82 /16s and 215 /24s Percentage of available address space announced: 35.5 Percentage of allocated address space announced: 58.2 Percentage of available address space allocated: 60.9 Total number of prefixes smaller than registry allocations: 65586 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:27046 Total APNIC prefixes after maximum aggregation: 14017 Prefixes being announced from the APNIC address blocks: 25273 Unique aggregates announced from the APNIC address blocks:13910 APNIC Region origin ASes present in the Internet Routing Table:2069 APNIC Region origin ASes announcing only one prefix:614 APNIC Region transit ASes present in the Internet Routing Table:335 Average APNIC Region AS path length visible:4.9 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 150449920 Equivalent to 8 /8s, 247 /16s and 175 /24s Percentage of available APNIC address space announced: 68.7 APNIC AS Blocks4608 - 4864, 7467 - 7722, 9216 - 10239 17408 - 18431, 23552 - 24575 APNIC Address Blocks 58/7, 60/7, 202/7, 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes: 81982 Total ARIN prefixes after maximum aggregation:49940 Prefixes being announced from the ARIN address blocks:63077 Unique aggregates announced from the ARIN address blocks: 21940 ARIN Region origin ASes present in the Internet Routing Table: 9279 ARIN Region origin ASes announcing only one prefix:3303 ARIN Region transit ASes present in the Internet Routing Table: 909 Average ARIN Region AS path length visible: 4.7 Max ARIN Region AS path length visible: 17 Number of ARIN addresses announced to Internet: 225859360 Equivalent to 13 /8s, 118 /16s and 87 /24s Percentage of available ARIN address space announced: 74.8 ARIN AS Blocks 1 - 1876, 1902 - 2042, 2044 - 2046, 2048 - 2106 2138 - 2584, 2615 - 2772, 2823 - 2829, 2880 - 3153 3354 - 4607, 4865 - 5119, 5632 - 6655, 6912 - 7466 7723 - 8191, 10240 - 12287, 13312 - 15359 16384 - 17407, 18432 - 20479, 21504 - 23551 25600 - 26591, 26624 - 27647, 29695 - 30719 31744 - 33791 ARIN Address Blocks24/8, 63/8, 64/6, 68/7, 70/8, 198/7, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary Prefixes being announced by RIPE Region ASes: 26020 Total RIPE prefixes after maximum aggregation:18441 Prefixes being announced from the RIPE address blocks:22802 Unique aggregates announced from the RIPE address blocks: 15175 RIPE Region origin ASes present in the Internet Routing Table: 5606 RIPE Region origin ASes announcing only one prefix:3018 RIPE Region transit ASes present in the Internet Routing Table: 973 Average RIPE Region AS path length visible: 5.5 Max RIPE Region AS path length visible: 26 Number of RIPE addresses announced to Internet: 165059392 Equivalent to 9 /8s, 21
Re: Unplugging spamming PCs
On Fri, 25 Jun 2004 09:11:36 PDT, Larry Pingree said: > > What I am proposing is have a registry that you must register > with before other mail servers will accept mail from you. Similar to how > MAPS RBL works, but the mail server itself, enforces it, rather than a > firewall or a ancillary device ACL. This could be made a standard of > SMTP. Yet another "it won't do any good till everybody deploys it". http://www.rhyolite.com/anti-spam/you-might-be.html pgpCbp2QR30lO.pgp Description: PGP signature
Re: Unplugging spamming PCs
On Sat, 26 Jun 2004 00:15:37 +0800, Suresh Ramasubramanian said: > That's great. Let's all return to the good old days of X400 and UUCP I have to congratulate you... it's been a while since anybody's managed to bring back two entirely distinct sets of repressed nightmares in one line. :) pgpPcvC1R9J3d.pgp Description: PGP signature
Re: Attn MCI/UUNet - Massive abuse from your network
On Fri, 25 Jun 2004 09:47:07 PDT, Jeff Shultz <[EMAIL PROTECTED]> said: > The problem with being totally open about infrastructure is that there > are some vulnerabilities that simply cannot or will not be fixed - > wires sometimes have to run across bridges, redundant pumping stations > are too expensive... in these cases is it not better to hide where > these vulnerabilities are? Anybody with a Rand McNally map of Manhattan can connect the dots for themselves. Unless you're proposing that we issue Soviet-style maps that show the Brooklyn Bridge between Williamsburg Bridge and Queens-Midtown Tunnel. Or did you mean we should make the Brooklyn Bridge invisible so we can't see it? There's this magician looking for another prime-time TV special, you know??? pgpHzWJsTUjwr.pgp Description: PGP signature
Re: Can a customer take IP's with them?
> Only one customer? There are a couple "consulting" firms in > particular around here that use arbitrary space on internal > networks. Sometimes a currently-dark IP block is configured, so > "it works for us". It gets annoying after a while. The worst one I've seen so far is Ticketmaster... last month. If you want to sell tickets through them and connect via the network, they require you to have a private, backend connection to them and then require you to route 29.2.0.0/15, 29.4.0.0/15, and 29.6.0.0/16 via that connection. I could be wrong, but somehow, I don't think that they are also known as or have received addresses from: OrgName:DoD Network Information Center OrgID: DNIC Address:7990 Science Applications Ct Address:M/S CV 50 City: Vienna StateProv: VA PostalCode: 22183-7000 Country:US NetRange: 29.0.0.0 - 29.255.255.255 CIDR: 29.0.0.0/8 NetName:MILX25-TEMP NetHandle: NET-29-0-0-0-1 Parent: NetType:Direct Allocation Comment:Defense Information Systems Agency Comment:Washington, DC 20305-2000 US RegDate: Updated:2002-10-07 The argument of "what if one of the DoD research groups on campus is trying to connect to this space for classified work?" didn't work... especially given that the blocks aren't in our BGP tables. Alas, my protests failed against the might of our self-funding sports program. Eric :)
RE: Unplugging spamming PCs
Authentication and Authorization are two separate and distinct issues. TLS and Authentication have been around for quite a while, but without centralized authorization it will never be deployed by disparate corporations for inter-domain mail! This will not stop spam. Unless of course you want to manage user accounts or certificates with every single customer that you want to have conversations with. Authorization must still be authorized by a third party agency which verifies validity between everyone involved in communications. LP Best Regards, Larry Larry Pingree "Visionary people, are visionary, partly because of the great many things they never get to see." - Larry Pingree -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, June 25, 2004 12:14 PM To: Larry Pingree Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Unplugging spamming PCs On Fri, 25 Jun 2004 09:11:36 PDT, Larry Pingree said: > > What I am proposing is have a registry that you must register > with before other mail servers will accept mail from you. Similar to how > MAPS RBL works, but the mail server itself, enforces it, rather than a > firewall or a ancillary device ACL. This could be made a standard of > SMTP. Yet another "it won't do any good till everybody deploys it". http://www.rhyolite.com/anti-spam/you-might-be.html
email server registry (was: RE: Unplugging spamming PCs)
On 2004-06-25T12:47-0700, Larry Pingree wrote: ) single customer that you want to have conversations with. Authorization ) must still be authorized by a third party agency which verifies ) validity between everyone involved in communications. You seem to be making a case for only accepting GPG-signed email, or at best only accepting SMTP connections over SSL with a certificate issued by a trusted CA. These both go to identity, though, not authorization. I do not see an obvious way for a third party to verify that two entities can validly communicate with each other--unless both entities are involved in making that decision, or both parties have agreed on some set of criteria beforehand. If you are simply after identity-tracking, there are ways to enforce that other than creating a new "email server registry." If you mean to suggest that you want someone else to decide who should be able to talk to you--using their own criteria--it does not sound like you are proposing something I would opt to be a part of. -- Daniel Reed <[EMAIL PROTECTED]> http://people.redhat.com/djr/ http://naim.n.ml.org/ There are people who do things and people who take the credit, and the trick is to be in the first group; there is a lot less competition. -- Dwight Morrow, American Diplomat
Re: Can a customer take IP's with them?
At 3:29 PM -0400 6/25/04, Eric Gauthier wrote: > Only one customer? There are a couple "consulting" firms in particular around here that use arbitrary space on internal networks. Sometimes a currently-dark IP block is configured, so "it works for us". It gets annoying after a while. The worst one I've seen so far is Ticketmaster... last month. If you want to sell tickets through them and connect via the network, they require you to have a private, backend connection to them and then require you to route 29.2.0.0/15, 29.4.0.0/15, and 29.6.0.0/16 via that connection. Several third-party health payors, as well as a few HMOs and the like, do exactly this sort of thing with medical service providers. It makes hospital addressing, at times, rather interesting. Some of them used the rationalization that if the space wasn't in the Internet routing table, it was more secure. To make it worse, a couple further expected you to address some of your hosts with their bogus address space, and then run transport-mode IPSec to them. If you have never had a good sized hospital decide you are their new ISP (or network manager), it's good to find someone that will write prescriptions for legal drugs. On your first site visit, when you start discovering some of their addressing oddities, you will want to go to the pharmacy and get the scripts filled, to help you get through the day. While newer applications, if anything, go overboard for security, some earlier medical applications, especially laboratory instrumentation, just send all their data to 255.255.255.255. I asked one of the programmers why they did that, and he said they didn't know if somebody might plug in a device that needed the data, so they didn't want to be bothered putting in support for it. You will find there are now an assortment of security and privacy laws that the hospital has to support, HIPAA being the best known, but also 21CFR11 for clinical trials, DEA electronic prescribing of controlled substances, and COPPA for pediatric data. Unfortunately, no one has ever decided to harmonize the security requirements for the different mandates. If it helps put things in perspective, the legislation enabling recent extensive modifications and additions to HIPAA was titled the HIPAA Administrative Simplification Act. George Orwell would have loved it.
Question from NETCONF working group
Hi, The IETF's NETCONF WG is trying to select a retrieval filter mechanism for use with and operations. The fundamental issue is whether to use a subset of the XPath language or whether to define a mechanism based on XML subtree matching. Your comments can help us decide which propsal to choose. Here's the basic NETCONF protocol operation exchange: ... filter data ... ... XML selected by the filter criteria ... There are two options under consideration for the mandatory filter mechanism (i.e., standard values for the 'filter-type' attribute). If we can't get consensus on the mandatory to implement filter, then we will probably make both optional. A) XML sub-tree filtering A mechanism that allows exact match of element and attribute content, as well as the selection of specific subtrees. (This is implemented in Junoscript.) B) Xpath subset A small subset of the Xpath standard that provides essentially the same (or more) filtering functions as the subtree filter. (Note that full implementation of the Xpath 1.0 standard will be optional, and identified by the #xpath capability.) Operator and application programmer preference is really the deciding factor here. Approach (A) uses XML encoding that looks like the data model XML that will be returned in the response. Approach (B) uses an Xpath string encoding in the request, and the corresponding XML is returned in the response. Here are some example requests in both formats, followed by the response that would be returned in both cases. - E1) Select the entire sub-tree Request: (A) subtree http://example.com/schema-1"/> (B) xpath http://example.com/schema-1"/> t://users Reply: http://example.com/schema-1";> root superuser Charlie Root 1 1 fred admin Fred Flintstone 2 2 barney admin Barney Rubble 2 3 - E2) Select all 'name' elements within the 'users' sub-tree Request: (A) subtree http://example.com/schema-1";> (B) xpath http://example.com/schema-1";> t://users/user/name Reply: http://example.com/schema-1";> root fred barney - E3) One specific entry Request: (A) subtree http://example.com/schema-1";> fred (B) xpath http://example.com/schema-1";> t://users/user[name="fred"] Reply: http://example.com/schema-1";> fred admin Fred Flintstone 2 2 - E4) Specific elements from a specific entry Request: (A) subtree http://example.com/schema-1";> fred (B) xpath http://example.com/schema-1";> t://users/user[name="fred"]/name | t://users/user[name="fred"]/type | t://users/user[name="fred"]/full-name Reply: http://example.com/schema-1";> fred admin Fred Flintstone - C.7) Multiple sub-trees Request: (A) subtree http://example.com/schema-1"/> root fred barney superuser (B) xpath http://example.com/schema-1";> t://users/user[name="root"]/company-info | t://users/user[name="fred"]/company-info/id | t://users/user[name="barney" and type="superuser"]/company-info
Re: Unplugging spamming PCs
Larry Pingree [25/06/04 12:47 -0700]: > > Authentication and Authorization are two separate and distinct > issues. TLS and Authentication have been around for quite a while, but > without centralized authorization it will never be deployed by disparate I'm sure the IETF MARID list would be delighted to hear it, if you have any --srs -- suresh ramasubramanian [EMAIL PROTECTED] gpg # EDEDEFB9 manager, security & antispam operations, outblaze limited
Re: Teaching/developing troubleshooting skills
On 04/6/24 at 5:09 PM -0600, Pete Kruckenberg wrote the following : >I'm working on trying to teach others in my group (usually >less-experienced, but not always) how to improve their >large-network troubleshooting skills (the techniques of >isolating a problem, etc) I took a 5 day course in another era, fortunately for me at the beginning of my career, on analytic trouble shooting (Kepner Tregoe?). The 5 day course can be boiled down really to one concept that can be taught in 5 minutes... 'half-splitting'. (The other 4.95 days were spent making sure we understood the concept and learning to implement it, the length of time was overkill but the course vendor had to make money somehow :-) (In another discussion* it was pointed out to that that wasn't the correct name in the writers view... it was "binary search". Google may have proved the writer correct, but I still refer to it as half splitting as I spent a week learning to call it that :-) The point of this note is troubleshooting boils down finding the problem in the fewest steps. Half-splitting ensures the number of steps are at a minimum. The troubleshooters knowledge of the system and equipment provides the ability to devise tests at the half-splitting point. Half-splitting is a 5 minute concept. System/equipment knowledge is of course a lifetime endeavor. The reason I am writing this note is as I went through a career of troubleshooting I was surprised at the number of colleagues who had no concept of "half-splitting" and used "linear" or "random" techniques to determine test points/tests with a corresponding dramatic reduction in effectiveness. Cheers, Darrell *p.s., I just remembered where my previous discussion was; http://db.tidbits.com/tbtalk/tlkmsg.lasso?MsgID=15775 http://db.tidbits.com/tbtalk/tlkmsg.lasso?MsgID=15787 http://db.tidbits.com/tbtalk/tlkmsg.lasso?MsgID=15788 Searching with Google for "half-splitting" will produce some useful hits.
