December 2002 - Test - lists.nanog.org

power at 55 S. Market in SJ
by Scott Granados 11 Dec '02

11 Dec '02

I just received a note from our facilities guy. I'm in 35 South and they informed us that PGNE will be shutting power down for our building and Market Post Tower <55 S. Market> from 8:00 a.m. until at least 6:00 P.M. Sunday dec 15 to reroute power and do manhole work. Hopefully everyone involved will received more detailed notification and notice but it seemed important to mention here. Scott

1 0

RE: Operational Issues with 69.0.0.0/8 - or, does the Army read NANOG posts?
by Todd A. Blank 11 Dec '02

11 Dec '02

Yes, but can you help us get it fixed, since you know about their inner workings? This is continually using valuable resources of ours and the others out there that have been kind enough to help. New sites are hitting the "inaccessible" list every day. I try to post only sites like this one, or ones that seem to have a common thread between them - i.e. they use the same transit... This is why we posted to NANOG for help - in the hopes that someone somewhere in the community is either involved or knows people involved with these networks. Todd -----Original Message----- From: Brad Knowles [mailto:brad.knowles@skynet.be] Sent: Wednesday, December 11, 2002 5:11 AM To: Todd A. Blank Subject: Re: Operational Issues with 69.0.0.0/8 - or, does the Army read NANOG posts? At 8:05 PM -0500 on 2002/12/10, you wrote: > Another site that is filtering 69.0.0.0/8: > > www.army.mil > > If anybody has any way to reach anyone responsible for this, or if the > people who run this site are reading this, > > PLEASE STOP THE MADNESS! The US military is well-known for firewalling all non-US IP addresses around the world. This makes it kind of hard for people in NATO (served by Belgacom Skynet, and issued IP space from them) to contact people in the US military. This is one of those standard "Oops" situations that periodically crops up whenever they get some new 16 year-old firewall operator that doesn't understand why the moron before him had a non-US IP address in the "allowed" list, and promptly decides to remove it without checking with anyone. Doing martian filtering for 69/8 is nothing compared to the kind of stupidity we see from them on a regular basis. I say this as a former DISA.MIL Technical POC, so I have seen the kind of stupid stuff they do, first-hand and from the inside. -- Brad Knowles, <brad.knowles(a)skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

1 0

RE: Spam. Again.. -- and blocking net blocks? -- and ddos..
by Mark Segal 11 Dec '02

11 Dec '02

Apparently not everyone understood my joke on ddos, as per some emails and a voice mail from level 3.. :) I apologize if it wasn't clear... Usually a smiley denotes joking or sarcasm.. But anyway... IT WAS A JOKE!!!! Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570 > -----Original Message----- > From: Jason Lixfeld [mailto:jlixfeld@andromedas.com] > Sent: December 11, 2002 8:51 AM > To: Neil J. McRae > Cc: Sabri Berisha; Stephen Sprunk; nanog(a)nanog.org > Subject: Re: Spam. Again.. -- and blocking net blocks? > > > > Sorry for top posting, but I'm late for work... > > -- > > Agreed. I believe that society dictates that the > accumulation of personal wealth is one of the most important > factors to most people who have the means to generate it in > abundance. Any avenue to make a buck will supersede any > legislation or "Please don't do that because it's not > (nice|safe|legal|honest|<your_word_of_the_day_here>)". > > Until spam is no longer synonymous with generating revenue or > growing personal wealth, it's here to stay. Until drugs are > legal, or dealers are killed if caught, the fact that dealers > know pushing that crap on the streets is harmful, it doesn't > matter. The need, or desire to have more money than the next > guy is more important to someone than the other people who > exist outside their little box. Different circumstances, but > the same thing at the end of the day, I think. > > > It won't fix the problem. The world needs to change to stop driving > > the possible gains from sending spam. Its an eduction/social issue. > > -- > -JaL > > "AFAIK, You think I'm a BOFH for continually bashing you over > the head with a clue-by-four. OTOH, if you would just RTFM > every once in a > while, my life would suck *much* less." > >

2 1

Spam. Again.. -- and blocking net blocks?
by Mark Segal 11 Dec '02

11 Dec '02

Before the flame begins.. I'm not sure when this started.. Background: We have a downstream ISP, who hosts a website of questionable material. This customer (of our customer) used a third party to spam on their behalf.. Which is a violation of our AUP. (In fact we null0 the /32 in question). Problem: For some reason, spews has decided to now block one of our /19.. Ie no mail server in the /19 can send mail. Questions: 1) How do we smack some sense into spews? 2) Does anyone else see a HUGE problem with listing a /19 because there is one /32 of a spam advertised website? When did this start happening? Regards, Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570

17 19

RE: Spam. Again.. -- and blocking net blocks?
by Lee, Hansel 10 Dec '02

10 Dec '02

Quick Comment as a NANOG lurker and SPEWS lurker (news.admin.net-abuse.email). I'm not defending SPEWS, don't speak for SPEWS but will describe what I understand happens: SPEWS initially lists offending IP address blocks from non-repentant SPAM sources. If the upstream ISP does nothing about it, that block tends to expand to neighboring blocks to gain the attention of the ISP. High level concept: Block the SPAMMER - ISP Does nothing Block the SPAMMER's Neighboring Blocks (Collateral Damage) - Motivates neighbors to find new Upstream/Isp - Motivates neighbors to complain to upstream/ISP - Gains the attention of the Upstream/ISP Expand the Block - Ditto Block the ISP as a whole The SPEWS concept prevents an ISP from allowing spammers on some blocks while trying to service legitimate customers on others. For an ISP - it is either all or none over time, you support spammers and are blocked as a whole (to include innocent customers). If you do end up mistakenly on SPEWS or take care of your spamming customers - you can appeal to them at news.admin.net-abuse.email, get flamed pretty bad, and eventually fall off the list. I do personally like the idea of holding the ISP as a whole accountable over time. An ISP can stay off spews, I've never had a block listed - though when I'm in a decision making position, I've never tolerated a spammer. Hansel -----Original Message----- From: Michael.Dillon(a)radianz.com [mailto:Michael.Dillon@radianz.com] Sent: Tuesday, December 10, 2002 08:36 To: MSegal(a)FUTUREWAY.CA Cc: nanog(a)nanog.org; owner-nanog(a)merit.edu Subject: Re: Spam. Again.. -- and blocking net blocks? > Problem: > For some reason, spews has decided to now block one of our /19.. Ie no mail > server in the /19 can send mail. > Questions: > 1) How do we smack some sense into spews? Make it easy for them to identify the fact that your downstream ISP customer has allocated that /32 to a separate organisation. This is what referral whois was supposed to do but it never happened because development of the tools fizzled out. If SPEWS could plug guilty IP addresses into an automated tool and come up with an accurate identification of which neighboring IP addresses were tainted and which were not, then they wouldn't use such crude techniques. Imagine a tool which queries the IANA root LDAP server for an IP address. The IANA server refers them to ARIN's LDAP server because this comes from a /8 that was allocated to ARIN. Now ARIN's server identifies that this address is in your /19 so it refers SPEWS to your own LDAP server. Your server identifies your customer ISP as the owner of the block, or if your customer has been keeping the records up to date with a simple LDAP client, your server would identify that the guilty party is indeed only on one IP address. Of course, this won't stop SPEWS from blacklisting you. But it enables SPEWS to quickly identify the organization (your customer ISP) that has a business relationship with the offender so that SPEWS is more likely to focus their attentions on these two parties. > 2) Does anyone else see a HUGE problem with listing a /19 because there is > one /32 of a spam advertised website? When did this start happening? It's a free country, you can't stop people like the SPEWS group from expressing their opinions. As long as people are satisfied with crude tools for mapping IP address to owner, this kind of thing will continue to happen. --Michael Dillon

5 4

RE: Spam. Again.. -- and blocking net blocks?
by Scott Silzer 10 Dec '02

10 Dec '02

That is exactly what was done to to Futureway a third party spammed for a site hosted by a downstream ISP and the result was there entire network begging blacklisted by SPEWS. At 15:41 -0800 12/10/2002, David Schwartz wrote: >On Tue, 10 Dec 2002 15:45:29 -0500, Scott Silzer wrote: > >>I could understand if an ISP was allowing spam from a portion of >>there network. But in this case the only thing that the ISP did is >>host a website, the SPAM was sent from from a third party's network. >>The ISP did terminate the customer but in the meantime the entire >>NSP's network has been blacklisted, for a rouge webhosting account >>does sound a bit harsh. > > A spam blocking service that worked that way would be >useless. Anyone could >get any site they didn't like blacklisted simply by spamvertising it. Anyone >who uses a spam blocking list that works that way is DoSing themselves. > > DS -- Scott A Silzer

2 1

Re: Operational Issues with 69.0.0.0/8 - or, does the Army read NANOG posts?
by Todd A. Blank 10 Dec '02

10 Dec '02

Another site that is filtering 69.0.0.0/8: www.army.mil If anybody has any way to reach anyone responsible for this, or if the people who run this site are reading this, PLEASE STOP THE MADNESS! Sincerely, Todd A. Blank 614.207.5853

1 0

Re: Operational Issues with 69.0.0.0/8...
by Michael.Dillon＠radianz.com 10 Dec '02

10 Dec '02

> > Sean Donelan, May 14 1998 (three employers ago, so this should not be > > taken as representing the official position any of my past, present or > > future employers) > Yakhov, Elise, Mark, and Bill - 1994 as part of the RA > project, bringers of the RAdb. This gets to the heart of the matter. It is now 8 years later and RADB is not catching on. But during the same time period some other UMich people worked on a more general purpose directory service called LDAP and that one is catching on. LDAP technology can be made to do the job that we need done and instead of having to create tools from scratch we can leverage a lot of commercial tools to deal with the core functions. --Michael Dillon

7 10

Re: FW: /8s and filtering
by Harsha Narayan 10 Dec '02

10 Dec '02

Hello, Now I am confused because I have got two sets of contradicting answers. Some say that anyone can multihome, some say that you need to be of a certain minimum size to multihome. May I know what is the right answer? I agree that allowing anyone to multihome would increase the size of the routing table. So does this mean that someone has to be of a certain size to multihome? Harsha. On Tue, 10 Dec 2002, David Schwartz wrote: > > > On Tue, 10 Dec 2002 12:36:39 -0600 (CST), Forrest wrote: > > >Maybe I'm missing something, but what good would it do for someone to > >multihome if only their own providers accept their route, but nobody else > >does? I realize that their block should be still announced with their > >ISP's larger aggregate, but what good does this do if your ISP goes down > >and can't announce the large aggregate. > > Smaller multihomers elect to multihome for a variety of reasons. Those > reasons typically include latency reduction and toleration of POP failures, > router failures, and line failures. They're not looking to stay online is > Sprint or MCI disappears entirely. > > If you multihomed to 2 providers in this manner and made a table of all your > downtime and its causes, loss of the larger aggregate would the tiniest > fraction of your downtime, which is already a tiny fraction of the time. > > We don't put parachutes on commuter jets. The failures where > these would be helpful are but the tineiest fraction of the failures that > occur. And any significant failure at all of such a redundant system is > rare. > > >If you're a smaller organization, perhaps you'll only have a /23 from your > >upstream provider. With the filtering that seems to be in place, it seems > >like the only way you can truly multihome with a /23 is if it happens to > >be in the old Class C space. Or is this wrong? > > You're just biasing the question with the choice of words you use ... > "truly" multihome. > > >What seems to be needed is perhaps a /8 set aside by the RIR specifically > >to allocate to small organizations that wish to multihome that people > >would accept /24 and shorter from. > > Not only would this increase the size of the global routing table, but this > would actually decrease reliability for most basement multihomers. Basement > multihomers tend to flap their routes more often than their upstreams. By not > being inside a larger aggregate, these flaps are likely to result in more > significant pockets of unreachability than they would be otherwise. > > DS > >

4 9

Re: FW: FW: /8s and filtering
by Forrest 10 Dec '02

10 Dec '02

> Now, however, that ARIN is discussing proposals such as 2002-5, 2002-6 and > 2002-7 (with 2002-5 & 2002-6 most likely being passed within few months) > ARIN maybe put in position of assigning smaller then /20 blocks and that > is why I suggested on ARIN ppml mailing list that current micro-allocation > wording about assiging small blocks from specifically designated larger > blocks be made a separate policy that would apply to all small allocations & > asignments being made directly by ARIN. If you think its a good idea to > make this a policy, please do send your feedback to ARIN or bring it up > on ppml mailing list and then ARIN can work on this futher to make it a > policy. > Proposal 2002-7 is exactly what is needed in my opinion. I wish I'd seen it before I posted here earlier, since it basically identifies every problem I mentioned. http://www.arin.net/policy/2002_7.html Forrest

3 2