- Test - lists.nanog.org

Thanks to all--medical emergency under control
by Howard C. Berkowitz 07 Jan '97

07 Jan '97

Thanks to everyone who responded. I was eventually able to reach one of the providers, who was able to identify the callers through logs, and passed the information to the local emergency people. The patient is now under treatment, and did not take a lethal dose. Howard Berkowitz

5 5

Re: It Continues...Sprint Is played the fool...
by Peter Lothberg 07 Jan '97

07 Jan '97

Hello everybody! I beleive we have a small problem here; Suggested reading are the rules and regulations for common carriers, and just let me make one example; Joe does not like the fact that I call him on the phone, so he calls my local phone operator and have them to block my phone for outgoing calls. My mother is about to die and she needs and ambulance, but the phone does not work. All ISP's should have as a policy to move packets, or for some atlest try to move packets as close they can to the destination. As soon as the ISP enforces an AUP, (wich might be for all good) they might be hold responsible for all traffic that traverses their infrstructure, and that's the end of the ISP's and the Internet. Joe (from my above exaple) has the right to refuce to terminate traffic from whoever he decides, so in this case, he could refuce to talk to my phone, or to my local phone oprator, or the long distance carrier of the local phone operator. Being the Police, is in any contry i knew a job for the Police! --Peter

2 1

Re: It Continues...Sprint Is played the fool...
by Peter Lothberg 07 Jan '97

07 Jan '97

> > - the service provider must have a written and enforcable policy > > prohibiting any of its customers from sending any traffic to > > recipients that have not requested the traffic -- including (but not > > limited to) the sending of off-topic or unsolicited mail messages to > > mailing list exploders, subsets of mailing list registrants, news > > groups, and posters to news groups (termed "mail spamming"). The > > requirement for a response to any such unsolicited message to prevent > > future messages is unacceptable. > > Um, wouldn't this very message I'm typing right this second be prohibited > under the sort of policy you suggest? Is that really what you want to do? > > -- John B. > I would like to se such an agreement for the use of my telephone... --Peter

1 0

Re: It Continues...Sprint Is played the fool...
by John Bashinski 07 Jan '97

07 Jan '97

> - the service provider must have a written and enforcable policy > prohibiting any of its customers from sending any traffic to > recipients that have not requested the traffic -- including (but not > limited to) the sending of off-topic or unsolicited mail messages to > mailing list exploders, subsets of mailing list registrants, news > groups, and posters to news groups (termed "mail spamming"). The > requirement for a response to any such unsolicited message to prevent > future messages is unacceptable. Um, wouldn't this very message I'm typing right this second be prohibited under the sort of policy you suggest? Is that really what you want to do? -- John B.

1 0

Summary (Thanks to all and SPRINT...)
by Ehud Gavron 07 Jan '97

07 Jan '97

From: nanog To: barry@std So sorry, we can't give you useful contact number for IQ or SPRINT. Why don't you just go away. This is NOT what the list is for. --page-- From: nanog To: Hershkowitz@internet Hey, we gave you contacts to find an anonymous user's real provider, contact numbers, home addresses, and you tracked her down for the cops. Please let us know how else we can divulge private information for you. --page-- To: nanog From: Ehud Can we just change the NANOG charter to "Let's do nothing useful for real problems that bother providers, but if someone on IRC says they took an overdose, or threatens to kill themselves, let's fall all over ourselves revealing private info"? Happy New Year E

1 0

Re: It Continues...Sprint Is played the fool...
by William Allen Simpson 07 Jan '97

07 Jan '97

I'm just catching up on this list after the holidays, and am writing somewhat belatedly to disagree with this part of the message (the rest of the message was excellent): > Date: Fri, 3 Jan 1997 23:45:13 -0800 (PST) > From: Michael Dillon <michael(a)memra.com> > ... > Barry, I agree with everyon on this list that this is NOT the place to be > discussing the problem. Please take this to the proper forum. I'm on this list, and _I_ believe this is an appropriate place to discuss this operational problem! It is primarily a problem of inter-provider cooperation, and secondarily a problem of inter-ISP spam policy. Both topics are appropriate for inter-network operations, and thus, this list! Moreover, it was very important to me to learn about this Sprint policy of allowing spamming. I'm in the middle of writing the RFP evaluation criteria for a fairly large network buy. In addition to the paragraphs on accepting routes into its own address space for multihoming (which disqualified Sprint earlier), I'll add some language that: - the service provider must have a written and enforcable policy prohibiting any of its customers from sending traffic with IP Source addresses that are not normally received by the customer (termed "IP address spoofing"). - the service provider must have a written and enforcable policy prohibiting any of its customers from sending traffic with mail "From:" addresses that are not normally received by the customer, or that belong to another user (termed "mail spoofing"). - the service provider must have a written and enforcable policy prohibiting any of its customers from sending any traffic to recipients that have not requested the traffic -- including (but not limited to) the sending of off-topic or unsolicited mail messages to mailing list exploders, subsets of mailing list registrants, news groups, and posters to news groups (termed "mail spamming"). The requirement for a response to any such unsolicited message to prevent future messages is unacceptable. - the service provider must have the capability of isolating any external network addresses and connections within 10 minutes of notification about operational problems of its other customers and network connections -- including (but not limited to) broadcast flooding, connection flooding, routing loops, address spoofing, mail spoofing, and mail spamming. - The service provider will guarantee reimbursement of costs for each minute (or fraction thereof) beyond the specified 10 minutes. I believe these will disqualify Sprint, too. Any additional language or clarification would be helpful. Thanks. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

3 2

Re: It Continues...Sprint Is played the fool...
by Rob Liebschutz 07 Jan '97

07 Jan '97

> - the service provider must have the capability of isolating any > external network addresses and connections within 10 minutes of > notification about operational problems of its other customers and > network connections -- including (but not limited to) broadcast > flooding, connection flooding, routing loops, address spoofing, mail > spoofing, and mail spamming. I can't think of any provider in existence today, that implements reconfiguration of there routers, or guarantees response to any network problem within 10 minutes. How much do you plan to pay for your network connection? > - The service provider will guarantee reimbursement of costs for each > minute (or fraction thereof) beyond the specified 10 minutes. I also can't think of any provider that doesn't have a disclaimer clause in their contract about not being liable for any damage due to loss of service. Good luck finding a provider. Rob

1 0

Call blocking, please...
by Michael Dillon 07 Jan '97

07 Jan '97

Barry wants Sprint to block port 25 traffic from a Sprint customer to his ISP. On Mon, 6 Jan 1997, Sean Donelan wrote: > The phone company equivalent of Barry's request is call blocking, "beep, > boop, BEEP, The number you have dialed is blocked at the subscriber's > request." A major impetus for this feature was 'the' telephone company's > desire to get out of the abuse and harrassment complaint handling business. > The subscriber doesn't have to give a reason why they want the number > blocked, they just ask the phone company to do it. Due to the way SS7 > works, the blocked announcement (usually) comes from the telephone company > at the origin's location. > > BBNPlanet installs firewalls and filters for all sorts of customers > that don't want to recieve traffic from some sources. You don't need > a court order to install a firewall to block traffic, just the customer's > request. A traffic filter may be installed in any of several places, on > the destination customer's equipment, on the provider's equipment serving > the destination customer, at some intermediate point in the provider's > network, or in the provider's equipment serving the source customer. It > could also be placed in the source customer's equipment, but in most of > these cases we are dealing with an uncooperative source customer. > > There may be management reasons why an ISP doesn't want to fullfill a > customer's or non-customer's request to stop forwarding bits to/at them. > If you follow the rule used by the RBOC's managing the ATM NAP's, a PVC > may be terminated at the request of *either* subscriber. Their policies > cause an occasional routing blackhole, but don't seem to have opened > PacBell or Ameritech up to a lot of legal liability. And since the telco's > are extremely risk adverse, this is a pretty strong precedent. > > Maybe I'll add a section to my internet-draft on Responsible Internet > Service Provider Guidelines. > > - An ISP may stop forwarding traffic at the request of either the > source or destination. > > - Traffic forwarding filters should be symetrical, unless otherwise > requested by *both* the source and destination. This isn't exactly > what I want to say, the intent is to prevent people from using their > ISP as a shield while attacking a site that can't respond. But > most networks use asymtrical filters, e.g. anyone can FTP out, not > in. If you tell AOL you don't want mail from cyberpromo.com, you > shouldn't be able to mailbomb cyberpromo.com from AOL either. > > As always, a big concern is financial. Who should pay for traffic forwarding > filters? The prudish person who wants to keep the traffic out? Or the > annoying person who wants to bother as many sites as possible? So far the > net has had a policy, the person keeping the traffic out has to pay for > the firewall or cybernanny. > > - An ISP may charge the requestor a $100 processing fee (indexed to > the CPI) to install or remove a traffic forwarding filter. This > makes it profitable for an ISP to become a spammer's haven. > -- > Sean Donelan, Data Research Associates, Inc, St. Louis, MO > Affiliation given for identification not representation > Michael Dillon - Internet & ISP Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael(a)memra.com

1 0

Status Report - Mail Bombing of World.std.com by Sprint Client + FAQ
by Barry Shein 06 Jan '97

06 Jan '97

We are now well into day four and about to enter day five of this. As of about 9PM EST the mail-bombing of world.std.com by the Sprint client iq-internet.com continues full bore. It had stopped between about 8AM EST until about 8PM EST Sunday 1/5/97 and then restarted leading me to believe someone at iq-internet.com manually restarted the mail-bombing. There is no reason to believe there were any 12 hour connectivity problems between us or similar external explanations, someone at iq-internet.com most likely noticed it had stopped and restarted it. Sprint's position (explained to me at around 8:45PM EST when I called to report this status, also emailed Sprint the logs) is that they will meet during business hours tomorrow (Monday 1/6/97) to discuss this issue. To save hearing the obvious suggestions etc again, increasing traffic on these lists here is a brief FAQ: Q1. Are you (std.com) a Sprint customer? A1: No, we are not. Q2: Why don't you just block it at your router? A2a: It's effectively blocked at our host, which no doubt is faster than the router anyhow (a 16 cpu SGI Challenge XL w/ 1.5GB ram), but this gives me full logs. A2b: Note that blocking it at the router does nothing to free up our bandwidth to the internet we are trying to provide to our customers. Since the path between our router and world.std.com is a 100mb/s FDDI letting it go that one more hop is inconsequential to the harm being done. Q3: Ok, why don't you ask your provider (Alternet) to block it? A3a: A lot of this has to do with Sprint's reluctance to deal with their customer in any timely manner (four days, including two weekdays, would seem sufficient for them to simply put one route block in at iq-internet.com's router.) I want the logs for now, I want the bigger problem which seems to prevent Sprint front-line NOC personnel from fixing operational problems fixed. Burying it as another router block at our end or our backbone provider's end doesn't deal with the real problem here, that Sprint has policies in place preventing them from dealing with malicious, disruptive and damaging customers. A3b: Yes Alternet has offered to do this as soon as I request it. Q4: Why don't you email bomb, SYN attack, etc the host doing this to you? A3: Although I have sent a lot of email to a lot of accounts at the host periodically asking them to stop I don't think malicious behavior will help get to the root problem here which is Sprint's policies forbidding their personnel from intervening into even the most egregious and outrageous abuse of network facilities without self-defeating and lengthy bureaucratic process (I think that's a fair characterization as we go into the FIFTH day of this.) Q5: Ok, why don't you redirect it to addresses at sprint or mailbomb them or something similar to get their attention? A5: Again, self-defeating. But it is nice to know the people who are empowered to make this decision are enjoying *THEIR* weekend. Q6: Do you believe this is an isolated incident or a real failure in policy at Sprint? It seems fairly outrageous that they can't stop a customer whose behavior is so malicious, it doesn't seem possible that the customer doesn't know that this has gone way beyond "spam". A6: I believe this is a total failure of express Sprint policy and not an isolated incident in any way. I have been told many times now by Sprint personnel (at their NOC) that official policy forbids them from acting against this mail-bombing and there exists no process to get a decision made otherwise which takes less than the five days it looks like it is going to take (eg, there's no single manager they can call who has the authority to order the route block or some action be taken, or these people feel they can put such decision-making off until it is convenient for them personally.) Q7: Well, I can see Sprint's reluctance to block this loathsome creature entirely from the net without some process, these are litigious times, but you're saying Sprint refuses to even block the single route between iq-internet.com (the mail-bomber) and your host? Is there any legitimate reason for this site to be able to get to your host? A7: Yes, I am saying that Sprint policy is such that their personnel is not authorized to install even one route block without lengthy bureaucratic process taking several days. Q8: Why do you think this is so? A8a: Because there is an atmosphere of fear, essentially, at Sprint's NOC and their personnel have been completely unempowered from taking operational actions they know are required of them to operate within the greater internet. Essentially, they (Sprint policy-makers) apparently believe that any damage to the greater internet or any host or site is less important than their ability to run internal bureaucratic process at whatever pace and using whatever management style which suits them. A8b: As far as I can tell once they identify a customer as a "spammer" then they can take no action against him, no matter what the actual behavior is. At this point this is clearly an operational/technical problem, the "spam" has been blocked for four days now, the spammer has been told this, yet messages are still being looped from his machine almost non-stop. It is only via some bizarre exercise in "mind-reading" that someone, in my opinion, could surmise that the perpetrator's intention is to deliver advertising to mailboxes at our site. Yet, Sprint personnel are not empowered to do anything about this without lengthy internal process. Q9: Wow, this is quite outrageous, I'd go so far as to say "scary". Many of us sit here naively thinking that large companies such as Sprint selling internet services basically do their jobs within some reasonable range of quality, but this sounds like a very deep and worrisome failure of management at Sprint. How can any network emergencies be taken care of if they won't let their front-line NOC personnel take any operational responsibility, and it takes days and days to escalate internally what seem to be relatively straightforward problems with straightforward solutions which really should be dealt with quickly, in minutes, or certainly a very few hours? A9: No comment. -- -Barry Shein Software Tool & Die | bzs(a)world.std.com | http://www.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD The World | Public Access Internet | Since 1989

8 8

Continuing on medical emergency...
by Howard C. Berkowitz 06 Jan '97

06 Jan '97

Tnanks to everyone who has responded. Unfortunately, this is not a joke. The person involved is one whom I've been corresponding for some time, and have been giving some medical advice within my expertise. Her last message to a chat room gave the name and dose of the overdose I have been trying the numbers given in the whois response, but have just been getting voicemail. I'm sending email to every address I can guess might be a support person at uniserve.com. I have called the Vancouver police, but they are stumped--I can't reach anyone above the telephone supervisor level. Altavista searches on the email name have turned up nothing.

2 1