September 1997 - Test - lists.nanog.org

SpamShield
by Deepak Jain 12 Sep '97

12 Sep '97

I didn't see anything about this in the archives, but as far as implementing a reasonably friendly anti-spam policy (http://www.abest.com/~kai/spamshield.html) without forbidding relaying entirely, is there a consensus opinion? Thanks, Deepak

2 1

Re: not rewriting next-hop, pointing default, ...
by dlr＠bungi.com 12 Sep '97

12 Sep '97

[In the message entitled "Re: not rewriting next-hop, pointing default, ..." on Sep 11, 15:23, Randy Bush writes:] > >> no neighbor 192.41.177.73 > > they should not care if you peer with them or not, they can have > > the upstream provider to give them your routes, then: > > ! > > set nexthop 192.41.177.121 > > Yes, folk seem to be doing this kind of thing, as shocking and disgusting as > it seems. Hey, at least they know how to configure routers, now. Give them points for that, at least :-) above.net$ traceroute -g 192.41.177.98 www.mci.net traceroute to www.mci.net (204.70.133.140): 1-30 hops, 78 byte packets 1 gate-96.sjc.above.net (207.126.96.161) 2.16 ms 3.92 ms 2.53 ms 2 mae-west-T3-2.above.net (207.126.96.238) 4.85 ms mae-west-T3-1.above.net ( 207.126.96.245) 4.77 ms mae-west-T3-2.above.net (207.126.96.238) 3.32 ms 3 mae-east-oc3.above.net (207.126.96.66) 74.0 ms 78.1 ms 122 ms 4 mae-east-01.ix.ai.net (192.41.177.98) 81.0 ms !S * 87.9 ms !S -- Dave Rand dlr(a)bungi.com http://www.bungi.com

2 1

Re: not rewriting next-hop, pointing default, ...
by rja＠corp.home.net 12 Sep '97

12 Sep '97

On Sep 11 15:54, Randy Bush wrote: } Subject: Re: not rewriting next-hop, pointing default, ... > LSR is actually a significant security issue. So, while I do > understand and am sympathetic to the operational debugging > issues that LSR addresses, I think that requiring a peer to > enable LSR more than 2 hops inside their network from the > outside world is unreasonable. % So, you're comfortable with asking for LSR at the IX and a hop behind? "Comfortable" isn't the word I'd choose. Ideally, I'd filter out LSR entirely [1], but there are real operational issues. Letting LSR in two hops lets outsiders trying to debug (e.g. some routing problem) at least perform first-level fault-isolation so they know whose NOC to call for further debugging assistance. So I view the 2-hop notion as an attempt at "reasonable compromise". > In a world where SSH were available in cisco routers and/or > IPsec were more widely deployed, I might have different views. % K5 does not give you sufficient warm fuzzies? No, I'm afraid that Kerberos 5 doesn't give me sufficient warm fuzzies. I don't care to be very detailed on a public list such as NANOG. I will note that aside from my non-public concerns, Kerberos-5 is expensive to deploy and maintain. Kerberos can also adversely impact network availability if it isn't installed in exactly the right way (surprisingly few folks seem to do it right). Ran rja(a)home.net [1] DISCLAIMERS: - I'm not a security expert, so my opinion probably doesn't mean very much in the grand scheme of things. - I am NOT with @Home's Security Group, which is ably managed by Mike StJohns, who is a Security Expert. So don't blame them for my comments. - I don't make policy for @Home, so my opinions are just mine not my employer's. - I haven't had enough coffee yet today. :-)

2 1

Re: too many routes
by Sean Donelan 12 Sep '97

12 Sep '97

>What triggered the filter was the observation that in >the blocks freshly allocated by all three registries were >very poorly aggregated. More annoyingly, those allocated >to Sprint's principal peers (most notably Internet MCI) >demonstrated the worst aggregation; in one case a /14 was >announced almost exclusively as prefixes no shorter than >19 bits. What's interesting is Sprint's filters have encouraged InternetMCI's customers to clean things up more than Sprintlink's customers. As an experiment, I removed my filters last night. In general my filters are more generous than any Mr. Doran used, mostly blocking 'mistakes' like /32 prefixes. What I found was the four top providers appearing in the previous filtered paths in order were, total of 1074 filtered routes 227 Sprint 225 UUNET 97 AARNET 92 MCI Sprint has taken over the number 1 spot, and MCI dropped to number 4, from the point of view of my BGP routers. Although MCI still seems to be well represented amoung the very, very long (>/30) prefixes. But this may simply be due to someone else filtering out extremely long prefixes before they reach my BGP routers. So you should view these as lower bounds. Things may be worse. What was even more interesting was number of routes accounted for by >/24's in 192-210 space and >/16's in 128-191 space was more than any of the CIDRizing suggestions in Tony Bates weekly CIDR report. Some people seem to view CIDR as an opportunity to subdivide their traditional 'Class B' networks. I would classify most of these announcements as 'mistakes' because they usually also announce the supernet, and have the same path. Here were some of the extreme examples. 168.248.0.0/30 3561 i 168.249.0.0/30 3561 i 198.203.196.144/32 3561 i 203.38.0.144/30 3561 1221 ? 203.38.0.148/30 3561 1221 ? 207.65.182.111/32 3561 i -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

RE: Randy Bush et al
by Vincent J. Bono 12 Sep '97

12 Sep '97

Well. After getting back from a trip I find, what? That Mr. Bush has a bug up his ass. Bottom line: - We do default route. Into a Sprint T3 that we pay for. :-) - We do not pass no-next-hop-self routes - Check around, if someone was as bright as they think they are it would be obvious. - We only peered with Verio in the first place becuase someone other than Randy contacted us - We formerly sent a lot of traffic to Verio because it's customers love porn, and we have several rather large web farms downstream. The number listed in whois is bad, sorry, it happens. But the number on our web site is not. When there is a problem and we are involved, I say so. There was no problem here and we won't miss Verio peering one bit. Vinny vbono(a)comstor.com 888-624-8700 NOC 702-802-0222 ext 3148 voice BTW: Below is the "snotty" message that was sent to our NOC and it's reply. Who was snottier than who? ------- Forwarded Message Follows ------- Date: Thu, 11 Sep 1997 02:34:58 -0400 From: Matt Luebke <mluebke(a)mclean.mai.net> To: Randy Bush <randy(a)verio.net> Cc: noc(a)verio.net, noc(a)mai.net Subject: Re: you have been depeered Randy Bush wrote: > your peering at mae-east is very unacceptable. the phone number in whois is > answered by a modem. so you have been de-peered with 2914. > > randy Our peering at mae-east is very acceptable to us. However we find that Verio brings nothing to our table. Thank you and Goodbye. Matt

2 1

Re: too many routes
by Sean M. Doran 12 Sep '97

12 Sep '97

"Kent W. England" <kwe(a)geo.net> writes: > But you didn't actually do it then. Ok, true. > And the reason they started noticing it later was because > only then did you actually implement the filters, without > further notice, instead of much earlier. The surprise was > due to the fact that you did it without further notice > and not the fact that you did it. Hey, people should take notes when I rant. However you're right and as I said a long time ago it probably would have been helpful to try to coordinate things a little better. On the other hand, the unilateral action completely eliminated any argument that there was collusion between Sprint, MCI and the rest, which maybe was a good thing at the time. That people still yell about this is sort-of funny. Do you think people would be screaming less about allocation policies if I had been doing a count-down between the final warning and the actual implementation? (That's an actual question with obvious future operational impact rather than a rhetorical point. Really.) Sean.

1 0

spam and CIDR blocks
by Jeremiah Kristal 11 Sep '97

11 Sep '97

I know everyone is tired of IP address issues, and even more tired of spam, but I think this has some operational content. I'm sure that a good number of network operators have set up null0 routes for some of the more annoying spam sites, and I'm pretty sure that many people are sending whole /24s and maybe even larger blocks to null0 because of lack of response by the spam sites. What is going to happen when the spammers find that they are unable to reach 30% of their mailing list because of null0 routes? The spam sites just renumber into another network. Eventually the spam sites, or their upstream provider, will have to request more addresses from Arin, and this is where we might be able to gain another tool to fight spam. All address allocation requests have to be justified, I think that we can use this to prevent additional allocations to spam sites. The reasoning is that spam sites are not using their previously allocated space efficiently, and have poisoned their existing blocks enough so that even if they were to give them back to Arin, Arin would be in a very perilous legal position if they were to re-allocate these block. Basically, once an address is associated with spam, it is not going to be globally reachable until all null0 routes for it are removed. I'm open to any and all comments, suggestions, corrections, or flames on this. Jeremiah

3 3

Re: too many routes
by Sean M. Doran 11 Sep '97

11 Sep '97

Sanjay Dani <sanjay(a)professionals.com> writes: > There are backbone providers and there are providers of specialized > ISP or hosting or security etc. services that need independent* IP > address space and do not have to waste resources on building a private > "backbone". NAT. Sean. (read an old message by Paul Vixie prior to some NANOG that wasn't worth going to really where I think he might have said pretty much the same things he wrote) P.S.: > I had thought predicting consolidation in the Internet services > market was an exclusive realm of only the clueless "market research" > firms. Even they seem to be wisening up. "Internet services" is a rather broad term. I think the "consolidation is coming" crowd is looking more at transport. People watching UUWHO recently might see some justification for the "consolidation is coming" predictions. On the other hand there are models which are attractive beyond the "we run a backbone and dialup and web hosting and this and that and this and that and what else is on your checklist, oh yah, we do that too or are buying up a company that does it already" as such a model tends to scale poorly vs. the number of working brain cells in any given organization needed to offer reliable and coherent service over time.

4 4

NAT (was Re: too many routes)
by Sanjay Dani 11 Sep '97

11 Sep '97

>From smd(a)clock.org Thu Sep 11 13:13 PDT 1997 >"Jay R. Ashworth" <jra(a)scfn.thpl.lib.fl.us> writes: >> Perhaps I misunderstood Sanjay, Sean, but I believe his concern was >> that the addresses _not be the property of an upstream (ie: backbone) >> provider_ to provide flexibility of connection choice. > >Welcome to the new Internet, which is being built. > >Two of the fundamental concepts that are important: > > -- IP addresses are not forever > -- IP addresses are not end-to-end Jay paraphrased my concerns correctly. NAT does not give any incentives to an independently addressed provider (that does not own global physical infrastructure) to switch to using "multiple outward-facing addresses [from upstream providers' address space]". Hey, if I were a dreamer, I wouldn't count on those clueless, bandwidth stealing, soon-to-be squashed or consolidated, small providers, to help me bring through my vision ;-) No disrespect meant. I do enjoy reading and learning from the long, well written articles of the experienced folks out there. However, a small provider (one that believes they engineer better Internet throughput for clients' web servers than some of the big boys), would rather watch the bottomline. Sanjay.

1 0

Re: too many routes
by Peter Lothberg 11 Sep '97

11 Sep '97

Alan writes; > There is another router vendor who has OC-12 router interfaces ... > There is a choice in the market today for OC12 router interfaces. > -alan Let's try to define the terminolog; oc3 3*sts-1 (=3*ds3) oc3c 3*sts-1 concatenated (vc4, or one container 1920 bytes) oc12 12*sts-1 (=12*ds3) oc12c 12*sts-1 concatenated (can carry a STM-4, 7680 bytes) Most (all?) data equipment uses ocXXc chanels, so I asume that is what we are talking about. ATM OC12c-celltax = 'oc9' worth of IP traffic (467M) POS OC12c-frametax = 'oc11' worth of IP traffic ((580M) This is before we look at system performance, routers understand IP, Switches does not. -Peter

1 0