Re: Average case performance vs. Worst-case guarantee
> When an ISP buys a router does it want a worst-case guarantee about the > router's capabilities? Or will it buy a router which can give better > performance in the average case (it may drop some packets if the traffic > pattern changes suddenly)? Assuming both cost the same. Worst case guarantee is necessary in many cases. Easy example: A router that can handle an STM-1 of regular Internet traffic is worthless to us if it dies in the face of an STM-1 with minimum sized attack traffic. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
New Team Cymru IP2ASN whois server
Fellow networkers, Team Cymru is happy to announce the availability of a public whois server dedicated to mapping IP numbers to ASNs, located at whois.cymru.com. You can find the link to this tool at: http://www.cymru.com/BGP/whois.html This link has been added to our main BGP data page available at: http://www.cymru.com/BGP/index.html We have also extended the functionality of this daemon to support BULK IP submissions for those who wish to further optimize their queries with netcat. Following is a quick overview of how to use it: $ whois -h whois.cymru.com Where is replaced by the IP you'd like to map, like so: $ whois -h whois.cymru.com 4.2.2.1 ASN | IP | Name 3356 | 4.2.2.1 | LEVEL3 Level 3 Communications You can also include port information, and/or timestamps in your queries. Be sure to include quotes around your queries, or the daemon will interpret your request as multiple lines: $ whois -h whois.cymru.com "4.2.2.1 -0600 GMT" ASN | IP | Info | Name 3356 | 4.2.2.1 | -0600 GMT | LEVEL3 Level 3 Communications For instructions on how to submit BULK queries via netcat, simply issue the following command: $ whois -h whois.cymru.com help We hope you find this tool useful. Stay tuned for more features! If you have any comments or suggestions as to how we might improve this service, feel free to let us know! Thanks, Steve, for Team Cymru http://www.cymru.com -- Stephen Gill
Re: Any way to P-T-P Distribute the RBL lists?
At 07:08 AM 9/25/2003, Rich Braun wrote: But generating the blocklist requires real-time reporting back to a central server. Even if the server is decentralized, it will still require a relatively small handful of accessable IP addresses. I seem to recall a distributed server network, something called USENET, uses NNTP for sharing data with other servers in the network... Last I heard there were over 30,000 such servers netwide/worldwide, all sharing data with one or more neighbors, automagically sharing data that is input into one system to all systems in a relatively and reasonably short amount of time. I propose that a private spamrbl nntp server system be established. Only allow feeds from those you know, use PGP authentication for all feeds and all submissions. If there is a personally verifiable web of trust built around personally verified signed PGP keys, it should prevent spammers from infiltrating the system. Perhaps the only way you can get approved/added to the network is to be approved by your upstream or a peer, and so they are held accountable for letting you into the system. This system could house a number BLs, each as a "newsgroup", allowing each network to then utilize the BLs that they want to implement in their network at any given time. Some of the newsgroups could be open, anyone can add a listing, others would be moderated (e.g. Monkeys or Spamhaus) and only the moderator(s) could add or remove listings. It seems too easy. I must be overlooking something really stupid and obvious about why this won't work. jc
Re: Any way to P-T-P Distribute the RBL lists?
something not very far from the discussion on this thread was proposed last year by some researchers at columbia. for those of you who like reading academic papers: http://www1.cs.columbia.edu/~danr/publish/2002/Kero2002:SOS-camera.pdf -- ratul Aaron Dewell wrote: On Thu, 25 Sep 2003, Eric A. Hall wrote: > > I know you all have probably already thought of this, but > > can anyone think of a feasible way to run a RBL list that does not have > > a single point of failure? Or any attackable entry? > > Easy. Have the master server only be reachable by replication partners > through a VPN connection, and have dozens of secondaries advertising > through multiple anycast addresses. So why couldn't you follow this plan without the VPN and anycast? Have a couple of master servers totally unpublished (nobody except the secondaries know about it), then have dozens of secondaries that are the ones actually used (or AXFR'd off of). You can't attack all the secondaries at once if there are enough of them, and the master server is unknown (hopefully). You could certainly improve on that system with a VPN, but the service is reasonable without it. Make your secondaries be volunteers who sign an agreement to never tell anyone what your master IP addresses are. If they get out, shift the master files to a secondary, notify the other secondaries by secure channels, and you're back in business. Even better - Publish all the servers, nobody knows who the masters are of this list of N servers, and rotate it when needed or every so often. I'd be a secondary/rotating master in that setup. I'm sure you'd get a bunch of volunteers. Aaron
Re: AOL Proxy Servers not connecting via https - resolved
On Thu, 25 Sep 2003, Ron da Silva wrote: > > On Thu, Sep 25, 2003 at 06:11:23PM -0400, Brian Bruns wrote: > > > > This might be helpful to people setting up ACLs and the like: > > > > http://webmaster.info.aol.com/proxyinfo.html > > I think the point that Mike was making is that RFC1918 > space is 172.16.0.0/20 not a /8. At least two people have posted incorrectly about 172.16, wrt who has what and how big it is. Rekhter, et al Best Current Practice [Page 3] RFC 1918Address Allocation for Private Internets February 1996 3. Private Address Space The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets: 10.0.0.0- 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) AOL has NetRange: 172.128.0.0 - 172.191.255.255 CIDR: 172.128.0.0/10 NetRange: 172.192.0.0 - 172.211.255.255 CIDR: 172.192.0.0/12, 172.208.0.0/14 and apparently a bunch of other blocks. -- Jon Lewis [EMAIL PROTECTED]| I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Verisign Responds
Folks, bkc> lets try this again... why should a valid DNS protocol element bkc> be made illegal in some parts of the tree and not others? bkc> if its bad one place, why is it ok other places? There very much _is_ an operational issue here, but it needs to be characterized very carefully. To that end, the IAB note is nicely careful and, I think, exactly right in classifying a core "coordination" problem that comes with wildcarding. Standards are, after all, about coordinating details among independent participants. The problem with wildcarding a gTLD is not that the construct should be made illegal but that it requires a degree of coordination that was not attempted. In this regard, the sponsored TLDs are not a problem specifically because they are run in a more heterogeneous manner. The IAB note captures this quite with: In particular, we recommend that DNS wildcards should not be used in a zone unless the zone operator has a clear understanding of the risks, and that they should not be used without the informed consent of those entities which have been delegated below the zone. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA
Re: AOL Proxy Servers not connecting via https - resolved
Actually a /12. But the value of 172.16.0.0 0.15.255.255 has been burned into my head for some reason... ---snip--- Page 4 3 Private Address Space The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets: 10.0.0.0- 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) ---snip--- --- Ron da Silva <[EMAIL PROTECTED]> wrote: > > On Thu, Sep 25, 2003 at 06:11:23PM -0400, Brian Bruns wrote: > > > > This might be helpful to people setting up ACLs and the like: > > > > http://webmaster.info.aol.com/proxyinfo.html > > I think the point that Mike was making is that RFC1918 > space is 172.16.0.0/20 not a /8. > > -ron
Re: AOL Proxy Servers not connecting via https - resolved
On Thu, Sep 25, 2003 at 06:11:23PM -0400, Brian Bruns wrote: > > This might be helpful to people setting up ACLs and the like: > > http://webmaster.info.aol.com/proxyinfo.html I think the point that Mike was making is that RFC1918 space is 172.16.0.0/20 not a /8. -ron
Average case performance vs. Worst-case guarantee
Hi, I have this question to which I have not been able to get a conclusive answer (I have heard different things). When an ISP buys a router does it want a worst-case guarantee about the router's capabilities? Or will it buy a router which can give better performance in the average case (it may drop some packets if the traffic pattern changes suddenly)? Assuming both cost the same. Could you please give your opinion? Harsha.
Re: AOL Proxy Servers not connecting via https - resolved
This might be helpful to people setting up ACLs and the like: http://webmaster.info.aol.com/proxyinfo.html -- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.2mbit.com ICQ: 8077511 - Original Message - From: "mike harrison" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, September 25, 2003 5:10 PM Subject: Re: AOL Proxy Servers not connecting via https - resolved > > > A Clue Bat was gently swung by a friendly and clueful (semi-anonymous) > AOL NetOps guys who contacted me from my post on Nanog. Thanks Nanog, > and this sounds strange from me, but Thank's AOL. :) > > And yes, it should have been obvious on my part.. a router > was configured with a 172.0.0.0/8 netmask. > > > > ..there is what we call an RFC1918 issue. AOL was given > > some IPs in the 172.16.x.x range by ARIN. These are valid routable IPs, > > and we use them as IPs for the AOL user's machines (kinda like DHCP). The > > problem is that some people block all of 172.x.x.x thinking it's only for > > non-routable IPs when it's only half that range that is non-routable. > > (172.16.0.0/20 is the routable part). That appears to be the case with > > this one. We've asked ARIN for a different range, and they told us to go > > away, so we are stuck with this issue. If you can ask someone who does > > firewall and/or router ACLs in front of that website, they should be able > > to fix the issue. > > > >
Re: Proposed changes to the AUP.
> Thus spake Leo Bicknell ([EMAIL PROTECTED]) [25/09/03 17:19]: > I post this because 2 of the 7 offered in their message that they > were unwilling to support my proposal on the list because they felt > it might get them thrown off the list. That is an interesting > chilling effect I had not expected. that's ridiculous paranoia. what happens is black helicopters come and take them away and they are never seen again. perhaps we should not be guided by the fears of psychotics? randy
Re: Proposed changes to the AUP.
> --Fba/0zbH8Xs+Fj9o > Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw" > Content-Disposition: inline > > > --wac7ysb48OaltWcw > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > > Two recent e-mails made me take a new look at the Nanog AUP, and > I'd like to propose several changes to help clarify the policy. It would be great to add sending messages encoded in HTML is prohibited.
Re: Proposed changes to the AUP.
Thus spake Leo Bicknell ([EMAIL PROTECTED]) [25/09/03 17:19]: > Well, I've received 9 private responses to the e-mail. 7 indicate > support for my proposal, 2 were neutral comments. > > I post this because 2 of the 7 offered in their message that they > were unwilling to support my proposal on the list because they felt > it might get them thrown off the list. That is an interesting > chilling effect I had not expected. > > Please, if you think it's a good idea and aren't afraid to post > step up and voice your support to help those unwilling to do so. I'll voice a public support. And yes, I also received notice from Susan about my Freenet posting. What had me most confused was that I was contacted personally. I'm sure everyone else in the thread was /also/ contacted personally, but that meant that the thread continued on. It would be nice to have a public notice that the thread has wandered (or started) off-topic, and to continue conversation elsewhere.
Re: Increase in tcp traffic from spoofed source to bogon?
Is it all to 135 ? I drop lots of that at my border. Each time I traced it back to the customer, it was some infected machine that was not being natted for various reasons. e.g. Deny TCP 172.16.4.1:4616 192.100.103.4:135 We also see the odd ntp request. Is it bogon as in RFC 1918 or bogon as in not yet allocated / routed ? ---Mike At 05:26 PM 25/09/2003, Mark Segal wrote: While cleaning the narchi virus icmp traffic.. I noticed a lot of tcp traffic (it seems to be increasing) from spoofed address to bogon space? Any ideas on what virus or worm this is? Is it new? Regards, Mark -- Mark Segal Director, Network Planning FCI Broadband Tel: 905-284-4070 Fax: 416-987-4701 http://www.fcibroadband.com Futureway Communications Inc. is now FCI Broadband
Re: Any way to P-T-P Distribute the RBL lists?
Jay Kline wrote: The trick then will be to have as many different participants as possible, and to have each participant share who it thinks the other participants are (or explicitly are not). Then if you take out one node, the others are not prevented from functioning. Again, the problem is if you are the secondary or distribution point that is having it's turn at being DDoSed are you going to be happy with 100M of targetted crap being aimed at your ip space? Are you going to come back online as soon as the DDoSer moves to the next target? The problem here is the amount of DDoS traffic is significant for the upstreams to say "we're not going to carry this, fix it or we'll drop you" - except in the cases of nodes in various IX's - however there aren't many willing to put nodes in IX's (and certainly not for free). / Mat
Increase in tcp traffic from spoofed source to bogon?
While cleaning the narchi virus icmp traffic.. I noticed a lot of tcp traffic (it seems to be increasing) from spoofed address to bogon space? Any ideas on what virus or worm this is? Is it new? Regards, Mark -- Mark Segal Director, Network Planning FCI Broadband Tel: 905-284-4070 Fax: 416-987-4701 http://www.fcibroadband.com Futureway Communications Inc. is now FCI Broadband
Re: Proposed changes to the AUP.
Well, I've received 9 private responses to the e-mail. 7 indicate support for my proposal, 2 were neutral comments. I post this because 2 of the 7 offered in their message that they were unwilling to support my proposal on the list because they felt it might get them thrown off the list. That is an interesting chilling effect I had not expected. Please, if you think it's a good idea and aren't afraid to post step up and voice your support to help those unwilling to do so. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Any way to P-T-P Distribute the RBL lists?
Aaron Dewell wrote: On Thu, 25 Sep 2003, Eric A. Hall wrote: > > I know you all have probably already thought of this, but > > can anyone think of a feasible way to run a RBL list that does not have > > a single point of failure? Or any attackable entry? > > Easy. Have the master server only be reachable by replication partners > through a VPN connection, and have dozens of secondaries advertising > through multiple anycast addresses. So why couldn't you follow this plan without the VPN and anycast? Have a couple of master servers totally unpublished (nobody except the secondaries know about it), then have dozens of secondaries that are the ones actually used (or AXFR'd off of). You can't attack all the secondaries at once if there are enough of them, and the master server is unknown (hopefully). You could certainly improve on that system with a VPN, but the service is reasonable without it. Make your secondaries be volunteers who sign an agreement to never tell anyone what your master IP addresses are. If they get out, shift the master files to a secondary, notify the other secondaries by secure channels, and you're back in business. Even better - Publish all the servers, nobody knows who the masters are of this list of N servers, and rotate it when needed or every so often. I'd be a secondary/rotating master in that setup. I'm sure you'd get a bunch of volunteers. All well an good until the DDoSer systematically DDoSes each secondary in order as has happened with SPEWS and SORBS. Further, what's the point of having a DNSbl if the blocked parties cannot get to the website to: 1/ Find out why they are blocked. 2/ Get delisted when they have fixed the issue. When it comes to SPEWS - that isn't so much of an issue, with SORBS it is the main part of the system. / Mat
Re: AOL Proxy Servers not connecting via https - resolved
A Clue Bat was gently swung by a friendly and clueful (semi-anonymous) AOL NetOps guys who contacted me from my post on Nanog. Thanks Nanog, and this sounds strange from me, but Thank's AOL. :) And yes, it should have been obvious on my part.. a router was configured with a 172.0.0.0/8 netmask. > ..there is what we call an RFC1918 issue. AOL was given > some IPs in the 172.16.x.x range by ARIN. These are valid routable IPs, > and we use them as IPs for the AOL user's machines (kinda like DHCP). The > problem is that some people block all of 172.x.x.x thinking it's only for > non-routable IPs when it's only half that range that is non-routable. > (172.16.0.0/20 is the routable part). That appears to be the case with > this one. We've asked ARIN for a different range, and they told us to go > away, so we are stuck with this issue. If you can ask someone who does > firewall and/or router ACLs in front of that website, they should be able > to fix the issue.
Re: Any way to P-T-P Distribute the RBL lists?
On Thu, 25 Sep 2003, Jay Kline wrote: > How about publishing a list of servers, but use the PGP web of trust model to > allow updating of each other? That way there is no centralized source. If a > group of admins dont like the updates coming from a server, dont trust it any > longer. If you make this more like a social network, you dont have to have a > central authority. exactly. to be immune from ddos you MUST remove any centralized source. > The trick then will be to have as many different participants as possible, > and to have each participant share who it thinks the other participants are > (or explicitly are not). Then if you take out one node, the others are not > prevented from functioning. the problem is that automated crawlers could amass a list of nodes to attack. i shy away from automated discovery. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
Re: Any way to P-T-P Distribute the RBL lists?
On Thu, 25 Sep 2003, Eric A. Hall wrote: > on 9/25/2003 2:44 PM Aaron Dewell wrote: > > So why couldn't you follow this plan without the VPN and anycast? > Multiple anycast channels would make distributed attacks ineffective, > since each source would be attacking its closest target. script kiddies can easy amass zombie nets of several 10k's, widely distributed enough to kill an entire anycast system. also, the individual anycast targets likely wouldnt be very happy when they do get ddosed. this talk about architectures of static targets really has got to stop. start thinking outside the box, mmkay? -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
Re: Any way to P-T-P Distribute the RBL lists?
On Thu, 25 Sep 2003 13:44:59 -0600 (MDT) Aaron Dewell <[EMAIL PROTECTED]> wrote: >On Thu, 25 Sep 2003, Eric A. Hall wrote: > > > I know you all have probably already thought of this, but > > > can anyone think of a feasible way to run a RBL list that does not have > > > a single point of failure? Or any attackable entry? > > > > Easy. Have the master server only be reachable by replication partners > > through a VPN connection, and have dozens of secondaries advertising > > through multiple anycast addresses. > >So why couldn't you follow this plan without the VPN and anycast? Have a >couple of master servers totally unpublished (nobody except the secondaries >know about it), then have dozens of secondaries that are the ones actually >used (or AXFR'd off of). You can't attack all the secondaries at once if >there are enough of them, and the master server is unknown (hopefully). Its been said before, security through obscurity isnt security at all. There should be a way where every can know the ins and outs of a system, and still not compromise it. >Even better - Publish all the servers, nobody knows who the masters are of >this list of N servers, and rotate it when needed or every so often. How about publishing a list of servers, but use the PGP web of trust model to allow updating of each other? That way there is no centralized source. If a group of admins dont like the updates coming from a server, dont trust it any longer. If you make this more like a social network, you dont have to have a central authority. The trick then will be to have as many different participants as possible, and to have each participant share who it thinks the other participants are (or explicitly are not). Then if you take out one node, the others are not prevented from functioning. Jay
Re: Any way to P-T-P Distribute the RBL lists?
on 9/25/2003 2:44 PM Aaron Dewell wrote: > So why couldn't you follow this plan without the VPN and anycast? Multiple anycast channels would make distributed attacks ineffective, since each source would be attacking its closest target. VPNs can give you ~password protection for the master. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Any way to P-T-P Distribute the RBL lists?
On Thu, 25 Sep 2003, Eric A. Hall wrote: > > I know you all have probably already thought of this, but > > can anyone think of a feasible way to run a RBL list that does not have > > a single point of failure? Or any attackable entry? > > Easy. Have the master server only be reachable by replication partners > through a VPN connection, and have dozens of secondaries advertising > through multiple anycast addresses. So why couldn't you follow this plan without the VPN and anycast? Have a couple of master servers totally unpublished (nobody except the secondaries know about it), then have dozens of secondaries that are the ones actually used (or AXFR'd off of). You can't attack all the secondaries at once if there are enough of them, and the master server is unknown (hopefully). You could certainly improve on that system with a VPN, but the service is reasonable without it. Make your secondaries be volunteers who sign an agreement to never tell anyone what your master IP addresses are. If they get out, shift the master files to a secondary, notify the other secondaries by secure channels, and you're back in business. Even better - Publish all the servers, nobody knows who the masters are of this list of N servers, and rotate it when needed or every so often. I'd be a secondary/rotating master in that setup. I'm sure you'd get a bunch of volunteers. Aaron
Re: Any way to P-T-P Distribute the RBL lists?
On Wed, Sep 24, 2003 at 10:30:16PM -0400, Drew Weaver wrote: Hi, > I know you all have probably already thought of this, but can > anyone think of a feasible way to run a RBL list that does not have a single > point of failure? Or any attackable entry? > > Disregard this if im totally out of line, but it would seem to me that this > would be possible. Whatever you come up with, it practically always has a downside: spammers can get the whole list as well. Image an open-proxy-dnsbl being distributed via peer to peer or via distributed means as usenet. Spammers would love it as they no longer have to scan for themselves, same for open relays. For some form of dnsbls, such as the geographical ones, it might be useful to simply have everyone generate their own copy using the code the creators use. An option could be to setup large DNS servers on various IXP's like is being done for other nameservers so you 'distribute' the same nameserver on different geographical locations. -- Sabri Berisha "I route, therefore you are" "Wij doen niet aan default gateways" - anonymous engineer bij een DSL klant.
Re: Any way to P-T-P Distribute the RBL lists?
on 9/24/2003 9:30 PM Drew Weaver wrote: > I know you all have probably already thought of this, but > can anyone think of a feasible way to run a RBL list that does not have > a single point of failure? Or any attackable entry? Easy. Have the master server only be reachable by replication partners through a VPN connection, and have dozens of secondaries advertising through multiple anycast addresses. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: williams spamhaus blacklist
On 9/25/2003 at 3:04 PM, "Susan Harris" <[EMAIL PROTECTED]> wrote to me: > This is the third time I've contacted you concerning violations of the > NANOG list AUP. Your message below focuses on spam/blacklists, issues > that are not considered operational and are therefore off-topic for the > list. This is your last warning - if subsequent messages violate any > terms of the NANOG list, we'll need to remove your posting privileges from > the list. > Please refer to the AUP: > http://www.nanog.org/aup.html > Susan Harris, Ph.D. > Merit Network/Univ. of Mich. (above is a template, btw) oops - too late - been busy writing the next post that is SUPPOSEDLY off topic, and I hit 'send' before seeing this one. Now tell me: why are you not posting this notice to the list to kill the thread, if that is the desired effect? bye,Kai
Re: williams spamhaus blacklist
On 9/25/2003 at 2:19 PM, "Deepak Jain" <[EMAIL PROTECTED]> wrote: >> But it's ok when AboveNet does it?...or actually does much worse by >> secretly and arbitrarily blackholing various networks at will, while >> advertising connectivity to those networks to their BGP customers and >> peers? >> > So why keep connectivity to them? A contract term? Now that you know of the > policy and aren't very happy about it, why not change providers -- you > already have a few. :) > I think anyone who blackholes sites within their own network should take the > specifics with a community that clueful customers can use to route-around > them, but obviously its their network, and whoever is setting up the > blackholes can decide that for themselves. Just a suggestion. Travis Haymore, Director of Security at AboveNet, has reportedly (see Spam-L a couple weeks back) made telephoned threats to at least one system owner (digistar.com), threatening (and then following up on that threat) to null-route that particular system (/32) on all of AboveNet/MFNX's routers, for no other reason than a user of that system making unfavorable public statements about AboveNet in public forums - while not disputing the truth of such statements made; he just wanted "that user gone, or else". Unfortunately for Travis, that happened to be the backup outgoing MX for a mailing list of quite some importance to a few ISPs and RIRs: Hijacked-L. As far as my own case is concerned, presumably the same individual null-routed the machine this mail originates from (208.241.101.2), for reasons not explained and not justified with internal documentation whatsoever (that much I got from an AboveNet manager; causing removal of this IP from their BL, for lack of documentation, and the unnamed individual responsible for its entry (Travis was never mentioned by name to me by this AboveNet person, but everyone else who has reported similar experiences with AboveNet seems to be pointing back to him at this point) never contested it). Indeed, quite a bit of mail to [EMAIL PROTECTED] has been sent from this IP (we are talking of maybe a few hundred since Jan 2003, a fraction of the number of actual incidents observed) - and that appeared to be the one and only reason why this machine would appear on his/their radar at all. Legitimate, persistent and continuing complaints about illegal trespassing originating from AboveNet's (or their customer's) IP space into your servers apparently can get you transit-blackholed at AboveNet, rather than getting yourself blocked from accessing *AboveNet OWNED AND OPERATED* machines - while AboveNet, knowingly and willingly, does nothing to stop the illegal activity by itself. If null0-routing the complainant shields that complainant from the illegal activity (in order to make him shut up), I become quite suspicious that the remaining illegal activity against the other 99.999% of the Internet is not just being ignored, but endorsed and shielded from further discovery by the complainant. That's called "collusion", in my I-am-not-a-lawyer-way of expressing this. Add the secrecy on AboveNet's side and the unusual paths it takes to even partially uncover any of this, then tell me: would you rather be SBL-listed for everyone to see, or secretly null0'd at a transit point, with no public or privately accessible record, until you randomly find out about it, because some customer-used services (websites, email, etc.) have been failing randomly for a couple of weeks (blame the Internet!) ? > This way, blackholes designed to protect clue-light customers can be used > with little detriment to clueful customers (once the communities are used > and well-described/published). Funny as it is, none of the definitions found at http://www.above.net/antispam.html (section (3) and (8)) ever seem to apply to the cases that we are hearing and reading about here, making the interception and redirection of this traffic NOT AIMED AT AboveNET quite unlawful under federal wiretapping statutes - and all of this is happening with AboveNet managers being well-aware - less the details on the legalities, I am sure. And this one is for Deepak: how exactly would a single host (e.g.: any prefix longer than a /24) evade the giant traffic vacuum cleaner (AboveNet, busy cleansing the Internet of "unwanted by anyone" packets) when your route, as seem from most of the Internet, is a /10, rather than a /22, /23 or /24? And last but not least: Infrastructure failures as a result of operator behavior are on-topic, the last time I checked. bye,Kai
Re: williams spamhaus blacklist
[at the risk of getting whacked by Sue Harris, like: what does "operational" mean anyway when the flood of criminal activity that's been the subject of discussion here in recent days is frustrating massive amounts of ordinary customers/Internet users, who will turn away from the Internet in frustration altogether ; the impact on operators should be quite obvious] On 9/25/2003 at 11:58 AM, "netadm" <[EMAIL PROTECTED]> wrote: > This is exactly the problem with certain e-mail block lists (i.e. > www.spamhaus.org). A few zealots who control this particular block list > have made a decision based on inaccurate information. > Mr. Linford has listed (in his block list) 48 /24s allocated to Infolink > (yes we are a real ISP with real customers) for 2 customers we are > working to terminate. > In addition, as previously mentioned, Mr. Linford refuses to remove > listings once we notify him of the termination. And with good reason. > Given the above, it is imprudent for any network operator (North > American or Other) to use Mr. Linford's SBL to restrict the delivery of > e-mail. It is inadvisable for any network operator to even accept your BGP announcements like yours, inbound into their network: Anyone who is bleeding 32 /24's in addition to an enclosing /19 supernet (presumably out of incompetence, but maybe this is part of a strategy to circumvent less-skilled operators nullrouting the /19 at router level, and failing to notice that that doesn't work when there's longer prefixes) is worthy of being dropped for stealing too much of our router CPU/RAM. Anyone who (at least at one point in the past) replied to mail sent to [EMAIL PROTECTED] with a note that the complaint will be ignored and the only complaints that will be addressed (yeah right) are those sent in PLAIN OLD PAPER HARDCOPY, deserves no access to other networks whatsoever. Any ASN that announces the equivalent of only 51 /24's, yet manages to generate 106 AUP violations (mailing spamtraps, dead users, failing to yield to SMTP 550, etc., many of them continuous 'repeat action') in a four month period to 2 rather small MXs, and continues such illegal trespass after their 4 upstreams are informed (and have in turn informed you) of this continuously, deserves to be dropped until the end of time. Current AS 15083 upstreams: 2914 (Verio) 16631 (Cogentco) 19094 (Adelphia/telcove.com) My guess is that abuse@ people at (at least) Verio and Adelphia are tipping on their toes, waiting until the complaint count has reached the magic number high enough to term you with their management's support, so you can go find yourself some new upstreams - again. That won't change our stance of blocking you by ASN, IP space and known domain names - indefinitely. Given that there is 1000's of systems like ours, this makes the SBL listing seem like an insignificant problem for your so-called "ethucal bizniz". bye,Kai
Re: AOL Proxy Servers not connecting via https
On Thu, 25 Sep 2003, Brian Bruns wrote: > Last time I checked, SSL connections do not get proxied through the AOL > caching servers. > They go directly from the client. > 172.151.135.3 is not an AOL proxy server, it is an end user IP address that > a AOL user gets when they dial in. > cache-rf03.proxy.aol.com is an AOL proxy. Thanks, It seems when the connection swaps from a proxy/cache connection, that the AOL browser gets redirected to another AOL address first, and then goes out. There is a noticable delay (a second or two) from when the request gets sent, to when we see it on our network.. like an overloaded cache/proxy. Perhaps AOL is using some kind of "transparent" proxy.. or maybe it's the Dept of Homeland Security's mystery sniffer (just speculating in wild paranoid mode). Or maybe it's something on our network mangling packets.. But calls to AOL get me no-where..
Re: AOL Proxy Servers not connecting via https
Last time I checked, SSL connections do not get proxied through the AOL caching servers. They go directly from the client. 172.151.135.3 is not an AOL proxy server, it is an end user IP address that a AOL user gets when they dial in. cache-rf03.proxy.aol.com is an AOL proxy. -- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.2mbit.com ICQ: 8077511 - Original Message - From: "mike harrison" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, September 25, 2003 2:24 PM Subject: AOL Proxy Servers not connecting via https > > > I'm looking for a clueful person either inside of AOL's NetOps > or someone else that can help us. > > Problem; > > Using AOL Dial-Up, through AOL Browser or MSIE > users can connect to our web servers and our clients > web servers via normal http with no problem. > > If they connect to a secure site (https://) they > get 'page can not be displayed' and other errors. > We have this issue with Linux/Apache as well as > MSIE servers. > > Sniffing such connections, we get one of two scenerios: > > 1. A connection is opened from an AOL proxy server > (172.151.135.3 for example) yet no data is transmitted. > > 2. A connection is opened from an AOL proxy server. > what looks like a request is sent (580 bytes) > and some response is sent back (5k bytes) > Yet the clients browser never gets a website.. > The webserver logs an 'error 408' from the request, > Which is a request timeout. > > 2 test websites to try from AOL: > https://www.krystal.net MS > https://www.onrope1.com Linux/Apache > > > Clue Bat's welcome. Thank You --Mike-- > > >
RE: williams spamhaus blacklist
> But it's ok when AboveNet does it?...or actually does much worse by > secretly and arbitrarily blackholing various networks at will, while > advertising connectivity to those networks to their BGP customers and > peers? > So why keep connectivity to them? A contract term? Now that you know of the policy and aren't very happy about it, why not change providers -- you already have a few. :) I think anyone who blackholes sites within their own network should take the specifics with a community that clueful customers can use to route-around them, but obviously its their network, and whoever is setting up the blackholes can decide that for themselves. Just a suggestion. This way, blackholes designed to protect clue-light customers can be used with little detriment to clueful customers (once the communities are used and well-described/published). Just my idea. Deepak Jain AiNET
AOL Proxy Servers not connecting via https
I'm looking for a clueful person either inside of AOL's NetOps or someone else that can help us. Problem; Using AOL Dial-Up, through AOL Browser or MSIE users can connect to our web servers and our clients web servers via normal http with no problem. If they connect to a secure site (https://) they get 'page can not be displayed' and other errors. We have this issue with Linux/Apache as well as MSIE servers. Sniffing such connections, we get one of two scenerios: 1. A connection is opened from an AOL proxy server (172.151.135.3 for example) yet no data is transmitted. 2. A connection is opened from an AOL proxy server. what looks like a request is sent (580 bytes) and some response is sent back (5k bytes) Yet the clients browser never gets a website.. The webserver logs an 'error 408' from the request, Which is a request timeout. 2 test websites to try from AOL: https://www.krystal.net MS https://www.onrope1.com Linux/Apache Clue Bat's welcome. Thank You --Mike--
Experience with McLeodUSA
Title: Experience with McLeodUSA I am looking into a point-to-point DS3 from McLeodUSA in the Dallas/Ft. Worth area and was wondering what type of experience anyone on the list has had with them? Customer service, billing, response to issues, etc. Any information would be greatly appreciated! Thanks, Richard
Re: williams spamhaus blacklist
On Wed, 24 Sep 2003, Leo Bicknell wrote: > What you're missing in my argument is that it doesn't matter. I > have no idea who Eddy Marin is, nor do I care. Blocking wcg's > corporate mail servers is not the solution. Sure, it may get > someone's attention at wcg, but it may also harm a lot of "innocent" > communications, sales talking to clients, other wiltel customers > requesting support, heck, the secretary ordering lunch to be > delivered. But it's ok when AboveNet does it?...or actually does much worse by secretly and arbitrarily blackholing various networks at will, while advertising connectivity to those networks to their BGP customers and peers? This means anyone connected to AboveNet will be unable to reach those blackholed victims if the routes to those destinations propogated by AboveNet appear to be their "best route" to the affected networks. This breaks connectivity even though we have multiple other transit providers. This is much worse than a Spamhaus (or any other DNSBL) listing since anyone using such services does so by choice and can decide for themself what action to take, if any, for listed addresses. With AboveNet blackhole routing, our only option, once we're aware of the problem, is to make changes to our routing policy and force traffic away from AboveNet and onto one of our other transit providers. We only find out about such AboveNet blackhole routes when we open a ticket with AboveNet to ask why your network is broken when our customers complain of networks they can't reach when using our service (i.e. banks that can't reach their staff training web sites), but they can reach from other service providers, so they inform us that our network is broken. Who's attention is AboveNet trying to get? Anyone taking BGP routes from AboveNet, or worse yet, single homed to AboveNet, ought to be aware of this policy. At the very least, you should make sure whoever does your BGP is aware of it and knows how to reroute traffic when the "best route" doesn't actually work. You also might bring it up with your sales person when it's time to renew. The central image on www.above.net boasts of "Unconstrained Information Exchange". I wish that were true. -- Jon Lewis [EMAIL PROTECTED]| I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: What about joe-jobs?
>Speaking of joe-jobs, what's the "proper" proceedure > for >dealing with such? The company I work for is > currently >undergoing an admitedly minor joe-job. > (about 300 or so >bounces that I've seen since mid > last week or so.) > > Any suggestions for dealing with this? What domains are you seeing the joe-jobs from? We > see alot of joe jobbing attacks from the large webmail providers eg. yahoo.com, hotmail.com, aol.com, netscape.net, etc. A promising response that we've been following is Sender Permitted From http://spf.pobox.com . It's basically a reverse RBL. The owner of a domain identifies ip's that are allowed to send mail for that domain in a TXT DNS record. The rest are tagged with a wildcard deny or probably softdeny initially. If yahoo.com, hotmail.com etc alone just added the DNS records, we'd all be able to identify joe-jobbers of these domains. It won't help their own spam situation but it'd help our massive attacks of spoofed email. Spammers seem to use these big providers since blocking all of hotmail.com or yahoo.com is tough for other providers.
Re: VeriSign SMTP reject server updated
> Date: Thu, 25 Sep 2003 11:12:05 -0400 (EDT) > From: Gerald <[EMAIL PROTECTED]> [...snip...] > > Ugh...sucked in. Can we get back to network operation discussions. Someone > make a Verisign gripe/commiserate list. I'll sign up. [EMAIL PROTECTED] ...? Regards, Gregory Hicks > > G > > - How are ya? Never been better, ... Just once I'd like to be better. --- Gregory Hicks| Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3400 San Jose, CA 95134 | "The trouble with doing anything right the first time is that nobody appreciates how difficult it was." When a team of dedicated individuals makes a commitment to act as one... the sky's the limit. Just because "We've always done it that way" is not necessarily a good reason to continue to do so... Grace Hopper, Rear Admiral, United States Navy
Re: Any way to P-T-P Distribute the RBL lists?
On Thu, 25 Sep 2003, Rich Braun wrote: > > Drew Weaver <[EMAIL PROTECTED]> inquired: > >I know you all have probably already thought of this, but can > > anyone think of a feasible way to run a RBL list that does not have a single > > point of failure? Or any attackable entry? > > Fedex. "Never underestimate the bandwidth of a station wagon loaded with DLT > cartridges barreling along the highway at 70mph"... > > Seriously, as has already been pointed out, the distribution side of the > equation is the easy part. Server admins can use an out-of-band technique > like ordinary dialup to get access to the blocklist. But generating the > blocklist requires real-time reporting back to a central server. I respectfully disagree. What it requires is some mechanism to get updates back to "authorized" server(s), and those "authorized" servers need to determine what to do with the reports. This does not need to be real-time. Near-time would suffice IMO. The interesting issue with regards to this component is indeed not the transport mechanism, but rather dealing with the influx of reports, and mitigating DOS's through floods of bogus reports. This is where things like the "web-of-trust" concept comes in handy. Sorry, but this is definitely getting off the operational charter of NANOG, so I'll stop. :-) There are a few people that have expressed interest in exploring this further. If anyone is interested drop me a line privately. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell Asking the wrong questions is the leading cause of wrong answers \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
RE: Re[2]: williams spamhaus blacklist
>> Ehm, that was because you, infolink.com WERE the spam outfit, of >> course we block your 'entire network', it was an entire network of >> spammers with no real customers. You can pretend Infolink is an >> 'EyeEshPee' all you like Mr Leary but what we see is this, from your >> ROKSO record: >> This is exactly the problem with certain e-mail block lists (i.e. www.spamhaus.org). A few zealots who control this particular block list have made a decision based on inaccurate information. Mr. Linford has listed (in his block list) 48 /24s allocated to Infolink (yes we are a real ISP with real customers) for 2 customers we are working to terminate. In addition, as previously mentioned, Mr. Linford refuses to remove listings once we notify him of the termination. Given the above, it is imprudent for any network operator (North American or Other) to use Mr. Linford's SBL to restrict the delivery of e-mail. Dynamic block lists such as Spamcop will be much more effective at blocking spam, while allowing normal e-mail to flow as it should. Jon Ham/Infolink Network Administration Toll Free (USA) +1 877 293 2095 ext. 1422 Tel. +1 305 324 1616 ext. 1422 www.infolink.com
Re: Nothing like viruses with bugs in them (Swen)
On Fri, 19 Sep 2003, Mr. James W. Laferriere wrote: > > Hello All , > > Is there an example of a procmail filter for this bugger ? This might be a little late, but here is one that works 100% for me: # this is a virus. base64 encoded "ram cannot be run in DOS mo" :0 B: * cmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v /some/folder "/some/folder" can of course be /dev/null, in which case you can take out the trailing colon above since there is no need for locking. Grisha
Re: VeriSign SMTP reject server updated
On Thu, 25 Sep 2003, David Lesher wrote:
> The way to solve the Verislime problem is straightforward,
> but not simple.
>
> Make it unprofitable for them.
...can't resist hitting reply. First there is little to no way to make
this unprofitable for them since they already have people paying for the
opportunity to catch the eyes of these lost Internet travellers. Second,
it would have to be a negative cash flow to be nixed in a corporate
setting. ("unprofitable" does not necessarily convey: negative cash flow)
Ugh...sucked in. Can we get back to network operation discussions. Someone
make a Verisign gripe/commiserate list. I'll sign up.
G
- How are ya? Never been better, ... Just once I'd like to be better.
RE: Re[2]: williams spamhaus blacklist
From netadm, received 25/9/03, 9:02 -0400 (GMT): That describes the escalation procedure of SPEWS, but is not at all accurate for the SBL, we do not expand listings sideways into customer space or block whole ISPs [*]. Mr. Linford's Spamhaus has recently blocked our entire ISP because of 2 entities on our network we are working to terminate (it is a bit more complicated than simply pulling the plug). In addition, we have recently requested removal of listings once we have terminated the customer in question, but received no response. We can vouch for the fact that www.spamhaus.org blocks far more than just sources of UCE. In our case, it is our entire network. Ehm, that was because you, infolink.com WERE the spam outfit, of course we block your 'entire network', it was an entire network of spammers with no real customers. You can pretend Infolink is an 'EyeEshPee' all you like Mr Leary but what we see is this, from your ROKSO record: Prieur Leary's Infolink Communication Services, Inc. (64.251.0.0/19) initially got bandwidth from Yipes.com circa February 2002. Infolink (and Yipes) ignored tremendous numbers of spam reports for months on end. When E-xpedient.com bought that chunk of Yipes circa late June 2002, they continued spam hosting and were booted in a week or so. Next, Infolink headed for WCG.net, and commenced routing there during early July. It may have looked like a tasty morsel to Williams, but they soon realized it had a bitter aftertaste. It took until August 21 2002 before the mallet swung at WCG. Then UU.net took a whack at at it. By August 21, Infolink was already spamming via that route. That lasted until about August 28, and it was three strikes and they were in ROKSO. But other networks are still willing to experience the thrill of a flooded abuse queue, it seems, and these persistent spammers are still on the air. There was apparently a route via cw.net during August 28 and 29, but as of August 29 they seem to have transit via host.net, go-net.net, and go-intl.net, downstream of Verio.net. Among Infolink's notorious partners in spam, Infolink hosts Eddy Marin (OneRoute.net), John Ritzer, and Daniel Amato. http://www.spamhaus.org/rokso/search.lasso?evidencefile=1955 Spammers pretending to be ISPs don't qualify. -- Steve Linford The Spamhaus Project http://www.spamhaus.org
nanog@merit.edu
Steven Schecter said: > > Has anyone noticed excessively high latency between Global Crossing and > AT&T? From what I've gathered, the PNIs between Global Crossing and AT&T > are completely maxed out. I've seen the same, and was given the same reason on the GBLX->ATT peer in SFO. It was intermittent, happening on a daily basis, over a month ago. I've since prepended 7018 routes received through 3549 quasi-permanently. Grant -- Grant A. Kirkwood - grant(at)tnarg.org Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED
RE: Proposed changes to the AUP.
[EMAIL PROTECTED] is sending me virus infected emails. Wes Vaux, CCNA, CCDA Network Security Engineer, 9000 Regency Pkwy Ste 500 Cary, NC 27511 t 919.463.6782 f 919.463.1290 Global Knowledge Experts Teaching Experts http://www.globalknowledge.com -Original Message- From: Leo Bicknell [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 10:13 AM To: [EMAIL PROTECTED] Subject: Proposed changes to the AUP. Two recent e-mails made me take a new look at the Nanog AUP, and I'd like to propose several changes to help clarify the policy. Several recent discussions have descended into the weeds. I'll take my share of the blame for my participation. That said, one on-list event, and several off list events have raised some lingering questions about the Nanog AUP and how it is enforced. I believe that there are a couple of changes to the AUP that would help prevent these threads from happening, and those are the issues I want to raise. If you're not familiar, the AUP is at http://www.nanog.org/aup.thml. I suspect many of you have no idea how the Nanog AUP is enforced, so I will go into that first. Moments ago we saw a glimpse on the list. The first attachment to my message (it's not in the archive yet to give you a URL) entitled "srh-jrace" is a copy of an e-mail I believe Susan accidently copied to [EMAIL PROTECTED] If you look at the CC list you'll see the intended target was [EMAIL PROTECTED] To help show that assumption is probably correct, I attach three more messages, first, second, and third. These are three cases, in chronological order, where I have been given similar warnings for AUP violations. For full context, these three messages were part of the following threads: first - http://www.cctec.com/maillists/nanog/historical/0109/threads.html#01538 second - http://www.cctec.com/maillists/nanog/historical/0110/threads.html#00577 (Note, there are at least three other thread roots right under it as some follow ups didn't get attributed correctly.) third - http://www.merit.edu/mail.archives/nanog/threads.html#14454 To be clear, I'm not trying to "appeal my conviction" on any of these, the first thread clearly drifted way off topic, the second I clearly mention the law and politics. The third gives me a bit more trouble, as the reason I posted was to see if anyone could operationally use this new (admittedly legal) tool, but heck, it was about law so I'm ok with being wrong on that one. I show you these as I am unhappy about the method by which these were handled. So, what are my proposals? Simple: 1) Change item 6 on http://www.nanog.org/aup.html to read "prohibited" rather than "discouraged". Discouraged suggests to me general discussion about those topics is bad, but if it has operational significance or general interest on the list it may still be appropriate. However, it appears that there is no clear way to define what would or would not be appropriate, and that the enforcement is more in line with prohibited. Changing that one word should make it much more clear, and remove all doubt. Most likely item #3 should also be prohibited and not discouraged as well. 2) The current AUP states: ] Individuals who violate these guidelines will be contacted personally ] and asked to adhere to the guidelines. If an individual persists ] in violating the guidelines, the convener of NANOG, Merit Network, ] Inc., will take action to filter the offender's messages to the ] list. I have several problems with this: * There is no way for the nanog membership to review that the policy is being applied evenly and fairly. * Where there are ambiguities in the appropriateness of a topic there is no way to know that the moderators are using the same criteria the general membership would use. * It does nothing to educate other mailing list participants as to what is or is not appropriate. This method provides a gentle and constant reminder of the AUP that always provides new and relevant examples. * It does nothing to stop the thread. Several people have received these after others for the same thread -- I think we all have an implicit assumption that if it's allowed to continue by the moderators it must be ok to reply. To that end, I propose the following new method of handling things, which I believe is more in-line with what other mailing lists do: When inappropriate messages are sent to the list the convener will reply both to the list and to the poster pointing out that the topic is in violation of the AUP and should cease. Chronic offenders will be notified personally that their messages may be filtered or that they may be removed from the list as deemed
Proposed changes to the AUP.
Two recent e-mails made me take a new look at the Nanog AUP, and I'd like to propose several changes to help clarify the policy. Several recent discussions have descended into the weeds. I'll take my share of the blame for my participation. That said, one on-list event, and several off list events have raised some lingering questions about the Nanog AUP and how it is enforced. I believe that there are a couple of changes to the AUP that would help prevent these threads from happening, and those are the issues I want to raise. If you're not familiar, the AUP is at http://www.nanog.org/aup.thml. I suspect many of you have no idea how the Nanog AUP is enforced, so I will go into that first. Moments ago we saw a glimpse on the list. The first attachment to my message (it's not in the archive yet to give you a URL) entitled "srh-jrace" is a copy of an e-mail I believe Susan accidently copied to [EMAIL PROTECTED] If you look at the CC list you'll see the intended target was [EMAIL PROTECTED] To help show that assumption is probably correct, I attach three more messages, first, second, and third. These are three cases, in chronological order, where I have been given similar warnings for AUP violations. For full context, these three messages were part of the following threads: first - http://www.cctec.com/maillists/nanog/historical/0109/threads.html#01538 second - http://www.cctec.com/maillists/nanog/historical/0110/threads.html#00577 (Note, there are at least three other thread roots right under it as some follow ups didn't get attributed correctly.) third - http://www.merit.edu/mail.archives/nanog/threads.html#14454 To be clear, I'm not trying to "appeal my conviction" on any of these, the first thread clearly drifted way off topic, the second I clearly mention the law and politics. The third gives me a bit more trouble, as the reason I posted was to see if anyone could operationally use this new (admittedly legal) tool, but heck, it was about law so I'm ok with being wrong on that one. I show you these as I am unhappy about the method by which these were handled. So, what are my proposals? Simple: 1) Change item 6 on http://www.nanog.org/aup.html to read "prohibited" rather than "discouraged". Discouraged suggests to me general discussion about those topics is bad, but if it has operational significance or general interest on the list it may still be appropriate. However, it appears that there is no clear way to define what would or would not be appropriate, and that the enforcement is more in line with prohibited. Changing that one word should make it much more clear, and remove all doubt. Most likely item #3 should also be prohibited and not discouraged as well. 2) The current AUP states: ] Individuals who violate these guidelines will be contacted personally ] and asked to adhere to the guidelines. If an individual persists ] in violating the guidelines, the convener of NANOG, Merit Network, ] Inc., will take action to filter the offender's messages to the ] list. I have several problems with this: * There is no way for the nanog membership to review that the policy is being applied evenly and fairly. * Where there are ambiguities in the appropriateness of a topic there is no way to know that the moderators are using the same criteria the general membership would use. * It does nothing to educate other mailing list participants as to what is or is not appropriate. This method provides a gentle and constant reminder of the AUP that always provides new and relevant examples. * It does nothing to stop the thread. Several people have received these after others for the same thread -- I think we all have an implicit assumption that if it's allowed to continue by the moderators it must be ok to reply. To that end, I propose the following new method of handling things, which I believe is more in-line with what other mailing lists do: When inappropriate messages are sent to the list the convener will reply both to the list and to the poster pointing out that the topic is in violation of the AUP and should cease. Chronic offenders will be notified personally that their messages may be filtered or that they may be removed from the list as deemed appropriate by the conveners. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org From [EMAIL PROTECTED] Thu Sep 25 09:11:13 2003 Return-Path: <[EMAIL PROTECTED]> Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ussenterprise.ufp.org (8.12.9/8.12.9) with ESMTP id h8PDBC8h005650 for <[EMAIL PROTECTED]>; Thu, 25 Sep 2003 09:11:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BD132912AA; Thu, 25 Sep 2003 09:08:30 -0400
Re: Any way to P-T-P Distribute the RBL lists?
Drew Weaver <[EMAIL PROTECTED]> inquired: >I know you all have probably already thought of this, but can > anyone think of a feasible way to run a RBL list that does not have a single > point of failure? Or any attackable entry? Fedex. "Never underestimate the bandwidth of a station wagon loaded with DLT cartridges barreling along the highway at 70mph"... Seriously, as has already been pointed out, the distribution side of the equation is the easy part. Server admins can use an out-of-band technique like ordinary dialup to get access to the blocklist. But generating the blocklist requires real-time reporting back to a central server. Even if the server is decentralized, it will still require a relatively small handful of accessable IP addresses. An out of band layer-2 network could be created for that at the peering points, so as to prevent outside attack. Probably worth doing among major ISPs. Wouldn't scale to end users, of course. But end users could still subscribe to the blocklist through periodic updates. The other obvious thing that could be done would work pretty much like caller ID: create a set of SMTP enhancements that allow email recipients to accept mail from those who have provided traceable ID to the ISPs that participate, and who have agreed to acceptable-use policies that place strict limits on bulk email. Wait, hasn't that been done? The pre-1987 ARPAnet? Oh yeah, we've outgrown that... Public humiliation might also work. Bring back the stockades so we can place spammers out front of courthouses everywhere. Too bad society's outgrown that too... -rich
nanog@merit.edu
Steven Schecter wrote: Has anyone noticed excessively high latency between Global Crossing and AT&T? According to Global Crossing, the NYC peer is maxed during peak periods, and AT&T is refusing to increase capacity. No ETA at this time regarding a resolution to the problem, which is most certainly a business issue, not a technical one. -- Drew Linsalata The Gotham Bus Company, Inc. Colocation and Dedicated Access Solutions http://www.gothambus.com
Re: williams spamhaus blacklist
Dr. Race - this is the second time I have contacted you concerning a NANOG mailing list AUP violation. Please refer to the AUP: http://www.nanog.org/aup.html If you again violate any terms of the AUP, we'll need to withdraw your posting privileges from the list. Susan Harris, Ph.D. Merit Network/Univ. of Mich. On Thu, 25 Sep 2003, Dr. Jeffrey Race wrote: > > On Thu, 25 Sep 2003 08:29:42 +0100, Steve Linford wrote: > > >for the benefit of those providers on nanag who use our SBL system, > >rest assured we will be removing the escalation 'any minute now' as > >WCG are now in contact with us and I understand are pulling spammer > >plugs. > > Elegant understatement of basic principle that only hitting the > management scum over the head with a mallet will change their > behavior. Leo, are you listening? > > In my judgment rehashing this issue on NANOG is 1000% appropriate > because the people on this list are the ones who have to carry the > bad news to their masters. > > Jeffrey Race > >
RE: Re[2]: williams spamhaus blacklist
>> That describes the escalation procedure of SPEWS, but is not at all >> accurate for the SBL, we do not expand listings sideways into >> customer space or block whole ISPs [*]. >> Mr. Linford's Spamhaus has recently blocked our entire ISP because of 2 entities on our network we are working to terminate (it is a bit more complicated than simply pulling the plug). In addition, we have recently requested removal of listings once we have terminated the customer in question, but received no response. We can vouch for the fact that www.spamhaus.org blocks far more than just sources of UCE. In our case, it is our entire network. -Original Message- From: Steve Linford [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 8:22 AM To: Hank Nussbacher; [EMAIL PROTECTED] Subject: Re[2]: williams spamhaus blacklist At 12:50 +0200 (GMT) 25/9/03, Hank Nussbacher wrote: > AS3339 has a zero tolerance for spamming. With just one spam > complaint we block the IP in question. We have a downstream customer > that has many cybercafes in Africa that generate http and smtp spam > and we block each complaint within 48 hours. > > None the less, here is a recent email extract I received from > someone: > > "Hank, I am not a Spamhaus.org representative in any shape or form. > I do not claim to speak for Spamhaus.org in any capacity. The > University of xx is, however, a customer (i.e. as of this > morning, we block e-mails from IP addresses listed on Spamhaus SBL). > > I am just guessing what might happen if the problem is not sorted > out. > > I am sure you already know that the standard escalation procedure for > many blocklists is first to block the single offending IP address, > then the immediate smallest block that it is contained in according > to WHOIS, then the entire block of the ISP, and if that fails to stop > the spam, then the corporate MXes of the upstream ISP may be > blocklisted." That describes the escalation procedure of SPEWS, but is not at all accurate for the SBL, we do not expand listings sideways into customer space or block whole ISPs [*]. > Basically, we are being told if we don't drop the customer, our > corporate MXes will be blocked. I would not call this an "extreme > case", but it would appear that overzealous anti-spammers are perhaps > going a bit overboard. Luckily he claimed up-front to not be speaking for Spamhaus. I can sympathize with the level of frustration of someone being bombarded in spam, however we do not run escalations for single spammers (unless the problem is chronic, but even then we'd always contact the ISP and exhaust all other avenues). [*] Although we do not list whole U.S. or European ISPs, that's not strictly true for other areas of the net the "offshore" spammers have gravitated to. We are currently leaning on China heavily and are at this moment blocking large parts of Chinanet Shanghai (online.sh.cn) ADSL netblocks, as it's the worst of the China spam problems with 120 separate SBL listings all of US-based spammers (all the usual make-penis-fast crowd) hosted mainly on Shanghai ADSL lines. Spammers like Alan Ralsky these days pump everything out via SoBig-opened proxies with everything hosted in China, all run from Detroit using VPN. The Chinese are now understanding this but it's taken some time. That escalation should resolve itself 'any moment now' too as they say they're starting the process of tracking down and kicking off the hoard of pests they've acquired these last months. -- Steve Linford The Spamhaus Project http://www.spamhaus.org
Re: VeriSign SMTP reject server updated
Beating up the spokestech may feel good but is pointless. The way to solve the Verislime problem is straightforward, but not simple. Make it unprofitable for them. Maybe that is by political pressure [but I doubt it -- they have big lobbying muscle..] from the Hill. It may be by lawsuits. It may be by driving their costs up. It may be by hurting their other revenue lines, including registration. I donno. (Today, all I wish is that all this &^%^&*^ swen garbage was choking their pipes, not mine.) -- A host is a host from coast to [EMAIL PROTECTED] & no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
Re[2]: williams spamhaus blacklist
At 12:50 +0200 (GMT) 25/9/03, Hank Nussbacher wrote: AS3339 has a zero tolerance for spamming. With just one spam complaint we block the IP in question. We have a downstream customer that has many cybercafes in Africa that generate http and smtp spam and we block each complaint within 48 hours. None the less, here is a recent email extract I received from someone: "Hank, I am not a Spamhaus.org representative in any shape or form. I do not claim to speak for Spamhaus.org in any capacity. The University of xx is, however, a customer (i.e. as of this morning, we block e-mails from IP addresses listed on Spamhaus SBL). I am just guessing what might happen if the problem is not sorted out. I am sure you already know that the standard escalation procedure for many blocklists is first to block the single offending IP address, then the immediate smallest block that it is contained in according to WHOIS, then the entire block of the ISP, and if that fails to stop the spam, then the corporate MXes of the upstream ISP may be blocklisted." That describes the escalation procedure of SPEWS, but is not at all accurate for the SBL, we do not expand listings sideways into customer space or block whole ISPs [*]. Basically, we are being told if we don't drop the customer, our corporate MXes will be blocked. I would not call this an "extreme case", but it would appear that overzealous anti-spammers are perhaps going a bit overboard. Luckily he claimed up-front to not be speaking for Spamhaus. I can sympathize with the level of frustration of someone being bombarded in spam, however we do not run escalations for single spammers (unless the problem is chronic, but even then we'd always contact the ISP and exhaust all other avenues). [*] Although we do not list whole U.S. or European ISPs, that's not strictly true for other areas of the net the "offshore" spammers have gravitated to. We are currently leaning on China heavily and are at this moment blocking large parts of Chinanet Shanghai (online.sh.cn) ADSL netblocks, as it's the worst of the China spam problems with 120 separate SBL listings all of US-based spammers (all the usual make-penis-fast crowd) hosted mainly on Shanghai ADSL lines. Spammers like Alan Ralsky these days pump everything out via SoBig-opened proxies with everything hosted in China, all run from Detroit using VPN. The Chinese are now understanding this but it's taken some time. That escalation should resolve itself 'any moment now' too as they say they're starting the process of tracking down and kicking off the hoard of pests they've acquired these last months. -- Steve Linford The Spamhaus Project http://www.spamhaus.org
Re[3]: williams spamhaus blacklist
On Thu, 25 Sep 2003 12:50:58 +0200 Hank Nussbacher <[EMAIL PROTECTED]> wrote: > AS3339 has a zero tolerance for spamming. ... > None the less, here is a recent email extract I received from someone: ... > "Hank, I am not a Spamhaus.org representative in any shape or form. > I do not claim to speak for Spamhaus.org in any capacity. The > University of xx is, however, a customer (i.e. as of this > morning, we block e-mails from IP addresses listed on Spamhaus SBL). ... > Basically, we are being told if we don't drop the customer, our > corporate > MXes will be blocked. I would not call this an "extreme case", but it > would appear that overzealous anti-spammers are perhaps going a bit > overboard. i'd say that's more than a little bit of a reach. they admit right up front that they don't speak for spamhaus (steve linford can speak for spamhaus, and he's apparently reading this thread on nanog.) a spamhaus customer can hardly threaten a spamhaus listing, only spamhaus investigators can do that. what you're describing doesn't sound like a situation that would get you onto spamhaus. this spamhaus customer is talking through their hat. additionally, to the best of my knowledge, spamhaus listing and escalation procedures differ from the ones you described. richard -- Richard Welty [EMAIL PROTECTED] Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
Re[2]: williams spamhaus blacklist
At 07:42 PM 24-09-03 -0400, Richard Welty wrote: the blacklisting of ISP ranges is very rare, it only occurs perhaps once a year, in extreme cases. several years ago, the sbl listed sprint's coporate mail servers during a period when sprint was providing connectivity for many spamhausen. sprint responded by appointing a new head of abuse, and giving him the power to terminate spammers. sprint's corporate mail servers were delisted, and their network is now fairly clean. we don't jokingly call their service "sprintpink" any more. AS3339 has a zero tolerance for spamming. With just one spam complaint we block the IP in question. We have a downstream customer that has many cybercafes in Africa that generate http and smtp spam and we block each complaint within 48 hours. None the less, here is a recent email extract I received from someone: "Hank, I am not a Spamhaus.org representative in any shape or form. I do not claim to speak for Spamhaus.org in any capacity. The University of xx is, however, a customer (i.e. as of this morning, we block e-mails from IP addresses listed on Spamhaus SBL). I am just guessing what might happen if the problem is not sorted out. I am sure you already know that the standard escalation procedure for many blocklists is first to block the single offending IP address, then the immediate smallest block that it is contained in according to WHOIS, then the entire block of the ISP, and if that fails to stop the spam, then the corporate MXes of the upstream ISP may be blocklisted." Basically, we are being told if we don't drop the customer, our corporate MXes will be blocked. I would not call this an "extreme case", but it would appear that overzealous anti-spammers are perhaps going a bit overboard. Regards, Hank
Re: Verisign Responds
>And the usual US-centric view... >Which congress person does Demon Netherlands, T-dialin, Wanadoo >France, Tiscali etc. go to? In the Netherlands, Germany, France, Italy and other countries people generally know who to go to to raise an issue with their governments. In some cases there is a direct equivalent of "your" elected representative unless the country uses proportional voting. In all cases, the ISP can contact their favorite political party and ask for advice and support in raising a complaint to the U.S. government who indirectly regulate Verisign through the Department of Commerce involvement in ICANN and IANA. It is especially important for ISPs outside the U.S.A. to also issue press releases to go along with their petition for government action because the publicity from the press release will often accomplish more than the petition itself. The goal should be to get your country's government to officially protest the U.S. government's support for Verisign's action in destabilising the Internet. When the number of protests reaches critical mass and are widespread enough, then the Department of Commerce will be forced to act. The failure of the DOC to act before this point forms an indirect support of Verisign's action by the U.S. government. --Michael Dillon
Re: Verisign Responds
>> you are confused. and in any case this is off-topic. take it to namedroppers, >> but before you do, please read rfc's 1033, 1034, 1035, 2136, 2181, and 2317. >Can someone please tell me how a change to a critical component of the >Internet which has the capacity to cause harm is not an operational issue? He didn't say that. He said that there is a mailing list called "namedroppers" for discussion of DNS protocol changes and related DNS issues. And he also said that if you want to get very far with your proposal the list members would expect you to be familiar with the RFCs which document the existing DNS protocol. And even though he didn't say it, it is true that your proposal is not an operational issue. Now if somebody would actually code this new DNS protocol into a DNS server and a resolver (or some clients) then maybe it would become an operational issue. --Michael Dillon
Re: williams spamhaus blacklist
On Thu, 25 Sep 2003 08:29:42 +0100, Steve Linford wrote: >for the benefit of those providers on nanag who use our SBL system, >rest assured we will be removing the escalation 'any minute now' as >WCG are now in contact with us and I understand are pulling spammer >plugs. Elegant understatement of basic principle that only hitting the management scum over the head with a mallet will change their behavior. Leo, are you listening? In my judgment rehashing this issue on NANOG is 1000% appropriate because the people on this list are the ones who have to carry the bad news to their masters. Jeffrey Race
Re: Any way to P-T-P Distribute the RBL list
Distributing an RBL list is the easy part. There are a variety of methods in place that can provide sufficient reliability and are sufficiently anonymous or difficult to attack, such as Usenet and Freenet and Gnutella and probably Kazaa, and it's not too hard to develop efficient data formats for baseline and incremental update and detail records (easier for IPv4 blocking than IPv6 :-), and you can use PGP or other digital signatures to protect the integrity of the transmission. SMOP... There are some problems with broadcasting the list as opposed to doing transactional interaction - a list of "mis-configured open relays or proxies with updates" is not much different from the spamware spammers' products of list of new still-usable open relays. (It's a bit less useful, because they know that some people are blocking them, but they also know that lots of people aren't.) The other half of the communications process is harder - getting the information on spammers to the list maintainer without exposing the list maintainer to attack. A simple usenet group or IRC channel can be flooded, and email can be mailbombed, and the obvious way to do it is with bogus spam reports to reduce the integrity of the information. And some of it's an arms race, e.g. spammer submits a purported open relay to list-manager the list-manager's tester tests the "relay", and the "relay" captures the tester's IP address for DDOSing. There are spam-reporting reputation systems - Cloudmark and Vipul's Razor do some of that, if imperfectly, or simple subscriber-only systems can stay below the radar (even though they'll have some spammers subscribing...) and you could probably build one that was P2P for a bit more safety.
Re: williams spamhaus blacklist
(Apologies to nanog, I make a point of not discussing spam issues here, but I feel an uncontrollable urge to respond to this one as it concerns Spamhaus directly) At 20:01 -0400 (GMT) 24/9/03, Leo Bicknell wrote: In a message written on Wed, Sep 24, 2003 at 07:42:39PM -0400, Richard Welty wrote: there's nothing alleged about it. the Eddy Marin spam gang in Boca Raton is one of the nastiest bunches of vile spamming slime you will ever see. this is all extremely well documented. go see the spamhaus site for documentation, it's all there. What you're missing in my argument is that it doesn't matter. I have no idea who Eddy Marin is, nor do I care. Eddy Marin is The Spam King, not your average garden-variety spammer. You might not care who Marin is but we unfortunately have to. Blocking wcg's corporate mail servers is not the solution. It's not a nice solution but it's sometimes the only solution available (to us). It's not an easy decision and it's a very rare one for us, but when a provider hosts a major spam gang long-term and looks set to continue indefinitely, escalating the issue by listing the corporate mail relays focuses the escalation only on the provider himself and not on his customers. We at that moment in time deem the provider to be 'knowingly supplying a spam support service'. but it may also harm a lot of "innocent" communications, sales talking to clients, other wiltel customers requesting support, heck, the secretary ordering lunch to be delivered. The Internet is now brimming with people who are almost in tears each time they check their mail and sort through their spam to see if there's any mail in it. Well over 50% of all email on the Internet is now spam (most ISPs say 60%+ of their incoming mail). That a provider's CEO, sales staff, or the secretary ordering lunch are inconvenienced due to an escalation caused by them allowing known spammers to cause such problems for all the rest of the Internet, is not our prime concern. The arguments of whether it's right or wrong can go on indefinitely but until someone invents a better solution this is all we have. There are laws against spam. If you have evidence, sue in civil court, or get a DA to go for it in criminal court. That's a joke right? Osama and his followers [...] I see, perhaps I shouldn't have responded to this post afterall. But for the benefit of those providers on nanag who use our SBL system, rest assured we will be removing the escalation 'any minute now' as WCG are now in contact with us and I understand are pulling spammer plugs. Regards, -- Steve Linford The Spamhaus Project http://www.spamhaus.org
Re: what to do about joe-jobs?
On Wed, 24 Sep 2003 [EMAIL PROTECTED] wrote: > On Wed, 24 Sep 2003 13:10:43 CDT, Stephen L Johnson <[EMAIL PROTECTED]> said: > > Please forgive my ignorance, but what is a "joe-job"? > > http://searchsecurity.techtarget.com/gDefinition/0,294236,sid14_gci917469,00.html This is amusing because we hosted joes.com at that time (and still do) and the other day I heard the term and speculated as to whether it could have come from the attack on joes.com back then. The URL above is accurate. To correct a mistaken impression that the ensuing DOS attack was a result of the bounces, the bounces were easily handled. The email sent out was an example of effective social engineering designed to make the recipients mad enough to attack the perceived sender. Of the over a million angry recipients, some had the technical know how to lash out. Think of it as a smart weapon where the weapon used is borrowed minds engaged by use of a meme. Job jobbing is a layer 9 algorithm (the program is the message people read and what it causes them to do) that is made possible by the ability of a spammer to forge their identity as that of their intended victim. Mike. +- H U R R I C A N E - E L E C T R I C -+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | [EMAIL PROTECTED] http://www.he.net | +---+
