- Test - lists.nanog.org

Give Your Child "One of the Best Children's Videos""
by Zf1818WiI＠worktow1est.com 04 Jan '98

04 Jan '98

The holidays are upon us. If you're like a lot of people, you struggle to find gifts for your children that will entertain and amuse them at the same time. Well, here's a gift that will delight your child - A Is For Airplane! "A Is For Airplane" is the award-winning educational video that shows kids all the fun and teamwork involved in running an airline. "A Is For Airplane" gets viewers behind the scenes at the airport! Kids get to see: * The ticket counter! * Inside the baggage system! * On the ramp with the baggage loaders and fuelers! * In the catering kitchens! * Inside the control tower! * In the hangar with the mechanics! * At the boarding gate! * And even in the COCKPIT of a real Boeing 757! Parenting Magazine calls "A Is For Airplane" "One of the Best Videos of 1996!" It's also Approved by the Parent's Choice Foundation! Thousands of copies of "A Is For Airplane" have been sold for $14.95, but as an Internet Special this holiday season you can get "A Is For Airplane" for only $11.95 (plus shipping and handling.) ORDER TODAY FOR GUARANTEED HOLIDAY DELIVERY! You can order "A Is For Airplane" by calling our toll-free number - 800-250-4210. If you'd like more information, visit our Website at www.ppmm.com/jfp/jfp1297.htm or CLICK HERE! Thank you for your time... Johnson Family Productions Madison, WI

1 0

aggregation tool
by Jared Mauch 02 Jan '98

02 Jan '98

How many backbone NSP's would use a bgp aggreation tool that was setup similar to the route-views.oregon-ix.net or route-server.cerf.net that you would be able to do queries on to say "what might I not be aggregating correctly?" I'm working on such a tool that would be able to speak eBGP to a router (multihop or otherwise) and give this information. I've noticed a few providers that have /16's that announce each specific /24 or almost each one also, this would also make it possible to generate lists of folks that clog the routing table. I've sent e-mail to some of these folks today... Please direct responses directly to me if you're interested, or if you have something useful on this topic for *everyone* on nanog, include them also. - Jared -- ----------------- jared(a)puck.nether.net - Nether Network ------------------ CICNet/IAGNet/QUALnet/NetherNet - finger jared(a)puck.nether.net for pgp key

1 0

The Cidr Report
by Tony Bates 02 Jan '98

02 Jan '98

This is an auto-generated mail on Fri Jan 2 12:00:00 PST 1998 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 02Jan98 0) General Status Table History ------------- Date Prefixes 261297 47433 271297 47424 281297 47380 291297 47497 301297 47601 311297 47560 010198 47266 020198 47531 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 3075 Number of ASes announcing only one prefix: 1452 (758 cidr, 694 classful) Largest number of cidr routes: 521 announced by AS3561 Largest number of classful routes: 973 announced by AS701 1) Gains by aggregating at the origin AS level --- 02Jan98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 698 391 307 44.0% iSTAR Internet, Inc. AS4293 417 199 218 52.3% IMCI AS174 882 675 207 23.5% Performance Systems International AS816 571 399 172 30.1% UUNET Canada (ASN-UUNETCA-AS4) AS3602 457 300 157 34.4% Sprint Canada Inc. AS3749 190 54 136 71.6% TECNET AS701 973 878 95 9.8% Alternet AS839 123 31 92 74.8% North West Territories Regional N AS3751 119 46 73 61.3% SNET-AS AS5668 102 37 65 63.7% Century Telephone Inc. AS2048 153 88 65 42.5% LaNet AS3804 202 140 62 30.7% Bell Solutions AS1 869 808 61 7.0% BBNPLANET AS549 218 161 57 26.1% ONet Backbone AS271 111 56 55 49.5% BCnet Backbone AS7545 115 63 52 45.2% TPG Internet Pty Ltd AS3464 119 67 52 43.7% Alabama Research and Education Ne AS1239 580 528 52 9.0% SprintLink Backbone AS4763 126 75 51 40.5% Telstra New Zealand AS4747 114 64 50 43.9% Taiwan Telecommunication Network AS4648 190 140 50 26.3% NZIX 2 AS72 84 36 48 57.1% Schlumberger Information Network AS719 505 460 45 8.9% LANLINK autonomous system AS3561 936 894 42 4.5% MCI AS1221 256 215 41 16.0% AARNET-AS AS684 82 43 39 47.6% Manitoba Regional Network Backbon AS6181 60 21 39 65.0% FUSE-NET AS4740 330 291 39 11.8% ASN-OZEMAIL (Ozemail Pty Ltd) AS2711 96 57 39 40.6% SUNBELT-AS AS1691 164 125 39 23.8% BCTEL For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: FW: Seeking MAE-East Service for foreign ISPs.. (fwd)
by Mark Dezagottis 02 Jan '98

02 Jan '98

Winfred: CAIS hosts many customers like this. Most are from other countries. However, we also have some from other regions of the United States. I will be glad to work with you on this ( I'm the Engineer that supports the Sales Staff at CAIS). Please send an email to markd(a)cais.net detailing what exactly you would like to do. We have POPs at MAE East, MAE West, Chicago, New York and the Palo Alto IX (DIX, Palo Alto CA). Our NOC is staffed 24 hours a day 7 days a week, References are available from customers who have this service already. Be sure to stop in if you are in the States! Regards, Mark Dezagottis --------------------------------- CAIS Internet 6861 Elm Street McLean, VA 22101 USA markd(a)cais.com Voice 703-448-4470 x 417 Fax 703-790-8805 http://www.cais.com > ---------- Forwarded message ---------- > Date: Thu, 25 Dec 1997 14:45:59 +0100 (CET) > From: Winfried Haug <haug(a)seicom.net> > To: nanog(a)merit.edu > Subject: Seeking MAE-East Service for foreign ISPs.. > > Hello... > > we are going to establish a mae-east link from germany. Since it is a little > bit difficult due to the physical difference to do router-baby-sitting etc :-) > we are looking for companies offering this service: > > -setup a cisco box at mae-east > -help to recover a lost or crashed router within a certain period (2-4 hrs). > > Could anyone give us some tips who is offering such a service. In order > to prevent ADs on this list, you could also mail me (haug(a)seicom.net) > if you dont prefer to answer on this list > > Thx. > > Winfried Haug > > --- > Winfried Haug | SEICOM.DE & SCHWABEN.DE | Tel. +49 7121 9770- 0 > Laiblinsplatz 12 | Internet+ISDN access & consulting | Fax. +49 7121 9770-19 > 72793 Pfullingen | Access in STGT + RT + TUE + BB + LB | Rack +49 7127 989-X > haug(a)schwaben.net| 150*ISDN (64kb/X.75) / 100 * K56flex | Rack +49 711 9675-X > haug(a)seicom.net |SAP-OSS * FTP * TELNET * NETNEWS * IRC | Rack +49 7121 709-X > * 10 MBit DE-CIX * 2 MBit INXS * 3 MBit ecrc/ebone * 2 Mbit Belwue * 2 Mbit WIN --

1 0

Re: Whoa; the 3 network?
by rja＠corp.home.net 01 Jan '98

01 Jan '98

On Dec 23 11:53, Randall Pigott wrote: % The Princeton address is the same as the old RCA company division % that did DARPA and ARPA gov't contracting, so that address space % once belonged to RCA "in the beginning". False statement and faulty logic. GE merely changed the address for the GE folks handling their network address to be the office in Princeton. Net 3 has always been GE address space, even before GE repurchased RCA during the 80s. In fact, for many years the Net 3 entry at the SRI NIC pointed to a GE Simulation facility in Florida because someone there was the address allocation stuckee for all of GE. % I have personal experience in a past life doing military DARPA work % with RCA, nearly twenty years ago, long before they formed RCA Astro % and built communications satellites. This address space was given % to RCA for DARPA work *only* way back then or earlier. RCA might have been given address space back then, but it wasn't Net 3. In the early 80s, when RCA was not owned by GE, GE had already been alloated Net 3 by the SRI NIC. I was a GE employee at the time and involved in renumbering some internal networks into Net 3 at the time. % I did a casual sequential-countup scripted "ping -a" on a small slice % of 3.0.0.0, and found almost no working domains within this address % space. [stuff deleted here] >-- End of excerpt from Randall Pigott Ping turns out to be a remarkably ineffective tool at measuring the utilisation of addresses or accessibility of hosts. Many a host that I've managed was not visible via ping, but was in fact directly on The Internet and reachable via telnet/rlogin/ftp _only from authorised hosts_ which were also on the Internet. Connection attempts from unauthorised hosts were silently dropped. No point in making it easy on the bad guys. This was done within some parts of GE at least as far back as the mid 1980s. It helped to have a 4.2 BSD source license. :-) Ran rja(a)home.net PS: Apologies for posting content onto the NANOG list...

3 2

RE: Deciding whose network block is whose?
by Dave Van Allen 01 Jan '98

01 Jan '98

Sean, FASTNET filters on prefix and mask, AS and "authority", that being a combination of the whois database and the radb. If the customer wants to announce a new prefix, they must first have the radb matching the announcement and the IP allocation has to be assigned to them by a verifiable means, such as the NIC/ARIN. I we originate the route, we will ensure that the databases are up to date. All new BGP peers are also password authenticated, and we are converting current peers to that as well. Global tables from our peering and customer DS3 connections are passed through a ACL that checks for illegal routes, host routes and reserved numbers. We had an instance where a customer of ours notice that someone else was announcing a more specific from their /18. It wasn't easy nor fun to make this stop. It required many panic calls and a lot of aggravation. It's just too easy to do, both intentionally and by mistake. And then there is the potential of BGP DoS attacks to further complicate things. Maybe each BGP update for a route might pass some sort of identity flag in the pre-amble that provides a trace of how the route arrived, and perhaps something like the serial number of the originating router. Then someone more cleaver than I can come up with a way to use that extra information to more quickly trace and disable bad or invalid announcements, or use that information in some fashion to authenticate the Good Guy from the Bad Guy. It ain't the ol' Internet no more. Best regards, David Van Allen - FASTNET(tm) / You Tools Corporation dave(a)fast.net (888)321-FAST(3278) http://www.fast.net FASTNET - Business and Personal Internet Solutions At 09:17 AM 12/29/97 -0600, Sean Donelan wrote: >When some random person decides to announce a subnet, what do providers >accept as proof the person has authority to announce that subnet to the >global Internet? Or the other side, when some random person calls up >complaining that someone else is announcing a subnet without authorization >what do providers accept as proof that the announcement is invalid? > >For example, lets say a difficult to reach ISP on the other side of the >planet decided to announce a subnet DRA had assigned for use by one of our >customers. Would major providers take my word a Hong Kong provider was >wrong? Would major providers accept the registration information in WHOIS >and/or IRR the network block had been delegated to me, and to no one else. >Would major providers accept a statement from the APNIC that the HK ISP >had never been delegated any part of the network block? What do you do >when a major provider's front-line customer service personnel don't >understand the problem, but says since the other person is a customer >they have to believe them? Of course, the major provider can't get a >hold of the customer either. > >Do providers normally just let customers announce any network, and only >review things after receiving complaints. If so, how do such providers >expect people to complain when one of their customers is causing problems. >How many days, weeks, months is considered normal to reach a competent >person at a major ISP that has the authority to block such a bogus >announcement by one of their customers? Since some (one) major provider >has a policy of not giving trouble ticket numbers when a non-customer >calls, how much ruckus must be caused to get their management's attention? > >This can cause partial network outages lasting weeks in some cases. I >hate the idea of needing to resort to things like filing formal criminal >complaints because of the dumb management policy at a major provider, but >it has been required in some other industries these providers operate >in. Slamming is a prohibited practice for long distance carriers, and >the customer can more or less easily get their phone number switched back >to their original provider. How does a customer do the same thing when >their IP network block gets slammed by another provider, or a customer >of another provider? > >There seem to be major problems with several of the widely referred to >network registration databases. I see Telstra (AS1221) is once again, >Dec 29, 1997, announcing 3.156.20.0/24. While its possible that General >Electric has an office in Australia, it seems an odd announcement. Other >than Sprint's global default for 0/1 (and then SPRINT has the nerve to >complain when people point default at them) there is no information in >the IRR about valid origin ASNs for Net 3/8. Although Mr. Bono spoke >up about some of GE's activities, other than James C. Shearer, who would >have authority over subnets from network 3/8? And what to do when the >listed contact has left, or worse is a generic position name (e.g. >hostmaster@ or noc@). > >Even going by company names isn't enough, because some companies have >very similar names, are merged, unmerged, sliced and diced. For example, >the various companies have "Data Research" in their name, but have >nothing to do with DRA. Nor is the DRA in the UK isn't affliated with >the DRA in the USA. > >Network blocks delegated to non-ISPs were fairly easy, because it is >uncommon to see subdelegations. But if you look at net 12/8 (AT&T), >customer subnets are appearing in announcements from other providers. >How do you decide when network blocks can be delegated, or not? In >net 12/8 case, the WHOIS database lists some delegations, but the IRR >shows different ones. > >But with CIDR it is even complicated figuring out what type of delegation >was done for subnets. Take the case of 205.164.62.0 which is from a >network block delegated to MCS. The history of this block is a bit odd. >It appears the block 205.164.0.0/16 was first delegated on March 15, 1995 >to NET99. On March 29, 1995 205.164.0.0/18 was delegated to MCS. At >some point later the delegation for 205.164.0.0/16 was deleted, and AGIS >was delegated 205.164.64.0/18 and 205.164.128.0/17. Something funny >happened to the database, because now MCS's registration date is >March 29, 2019 (a Y2000 problem?). MCS registered a portion of their >CIDR block in the IRR(MCI), 205.164.0.0/19. Goodnet registered an >IRR(RADB) entry for 205.164.0.0/18. AGIS and PSI have overlapping >registrations in the IRR(RADB) for 205.164.0.0/16. And, of course, >there is the Sprint global default route in the IRR(RADB) for 192/2. >Karl complained about AGIS announcing 205.164.62.0/24, but not about >205.164.13.0/24 which is also being announced by AGIS. > >How do you tell the difference between a customer trying to move a >delegated network address when switching providers, and someone whose >announcement would cause problems. > >The problem of bogus routing has been getting worse. Is it going to >take a disaster to get the attention of various provider's management? >-- >Sean Donelan, Data Research Associates, Inc, St. Louis, MO > Affiliation given for identification not representation > ************************************************************** Justin W. Newton voice: +1-650-482-2840 Senior Network Architect fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net Legislative and Policy Director, ISP/C http://www.ispc.org "The People You Know. The People You Trust." **************************************************************

1 0

Looking for unidirectional simplex satlink
by Hank Nussbacher 31 Dec '97

31 Dec '97

Can anyone point me at satellite providers who provide Internet unidirectional (simplex) satellite transmissions at E1 speed (unshared, non-broadcast), other than Interpacket, that cover the Middle East area? Thanks, Hank

3 2

Here we go again...
by Jay R. Ashworth 31 Dec '97

31 Dec '97

I guess whois is broken again, at least partially... I was hunting the HylaFax home page, and went off to whois(1) 'tpc.int'... who aren't listed. There isn't something I should know, is there? Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592

7 7

Re: route ingress
by Tony Li 31 Dec '97

31 Dec '97

> The only real solution is strong cryptographical authentication of > the ownership of routing prefixes. For some reason i do not see > any serious work in that direction being done. Actually, it is being done. It's not ready for implementation yet. Tony

1 0

re: route ingress [summary 2]
by Paul A Vixie 31 Dec '97

31 Dec '97

One thing I've heard several times now is "yes, I share an unrestricted IGP with some set of customers and so my net could be victimized by this trash, but we filter on egress to our BGP peers so we could not be a conduit." This is new and useful information for me -- it may mean that only a multinational network could get one of these prefixes into enough end systems to matter, and MOST (hint, hint, nudge, nudge) multinationals are doing static ingress. This problem may be solvable with small deltas in only a few bad spots. (You know who you are, we'll talk in Alburqurque.) The other thing I've learned from this escapade is that when folks think they can talk on NANOG without anyone flaming them by name afterward, some folks talk who normally don't. This may say something bad about the way we treat each other -- not everybody whose participation I value has thick enough skin to put up with my manners, much less those of some folks here I could name. ------- Forwarded Messages I am not replying to provide any sage input. I have none. I'm pretty new to BGP in general. I'm replying mainly to say thanks for directing a discussion that, to me, is fascinating, and from which I hope to learn a great deal. [ well, i'm not a real routing guy but i'm glad to help illuminate a topic. --vix ] I'm one of those newbies who is having to come up to speed in a hurry. I began contracting with XYZZY on a somewhat unrelated network upgrade project. Basically, for the time being, I've inherited the future of the network. I've done lots of IP networking, just not on this high a level, until now. I'm lurking. It's a tough crowd out there on NANOG. :-) My goal is to make/keep XYZZY a responsible networking outfit while learning enough to keep myself employed. :-) I won't take anymore of your time. I have included below a belated response to your earlier query. >My conclusions so are are: (1) most people know the importance of and the >procedure for strict controls over end-system routes they inject, even if >not everybody does it; I think so. We announce static routes only for those CIDR blocks allocated to us. >(2) degree of enforcement of (1) is probably going to be a term of most >peering agreements by this time next year; OK, I promise to bring it up when we next agree to a peering arrangement >(3) enough folks are enough opposed to the RADB that intermediate-system >route control probably won't come that way; I'm a newbie. I'm still working on understanding all the inner workings of RADB. I know what it does, but not how it works. [ so far it has run aground on the old prescriptive/descriptive debate, and some significant large providers have not joined the party. needless to say, it won't solve THIS problem until EVERYBODY uses it. --vix ] I believe the following three responses re true of our network as well > Subquestion 1: if the spammer is your customer. While the route would propogate to my ibgp network in some cases, it would not be announced to the internet. I would be spammed, but my peers would not hear the announcements. [my net] filters its announcements to peers at the AS and IP address level. Only known-valid addresses of our customers are propogated to our peers. > subquestion 2: if the spammer is a customer of one of your BGP peers. I would accept it in all cases. > subquestion 3: if the spamemr is a customer of a distant BGP-connected AS. I would accept it it all cases. ------- Message 2 1. Currently, we filter what is advertised to our upstream providers so it would not get advertised to the Internet at large, but it would be propagated through our IBGP mesh and to our BGP peers/customers. So, I guess this is a "mostly" no. [ this is sometimes called "unintended transit" and it's a large enough problem that it's probably worth solving for operational reasons even apart from the security issues. you should filter on egress to your BGP neighbors no matter what. you should filter on ingress where possible, and use static ingress with any single homed customer. --vix ] 2. We do not filter inbound announcements from BGPpeers/customers/upstreams, so yes. We do plan to generate filters from IRR for the smaller ones in the near future (once they keep their information up to date), but it seems infeasible to do so for upstreams such as MCI, UUNet, etc. given the size of the resulting filters. [ yes, i worry about the large ones too, but way down below i'll waffle. using the IRR wherever possible makes sense unless you have high BGP wizardry on your staff in which case you'd want all the knobs to yourself. --vix ] 3. Yes, and I don't see a practical way to do it given current technology. When you talk about fixing the problems by changing BGP, I am curious what design you would propose to fix this. As I see it, the only practical way to validate advertised routes automatically is using digital signatures of address delegations, and validating the chain of delegations back to a root (configurable in the router). [ yes, that's my thinking, and it's also what i've heard from the security folks. --vix ] One problem with this is that the bandwidth required to exchange routing information will increase dramatically, as well as the memory required to store the routing information (since a peer will have to be able to pass on the certificate of a received route object). Do you see another solution to the problem? [ here's the promised waffle. routers have been getting bigger, and despite the lamentations of the "i want a routing table i can count on one hand" crowd, they are going to keep getting bigger. if IOS were still scalable, cisco would be selling MasPar-like RP's with a gigabyte of ram (expandable). then we have bgp itself, which is a delta protocol based on reliable TCP for its statekeeping, so other than at startup or during heavy route flap, the bandwidth consumed by BGP is microscopic compared to, say, DNS or SMTP. (note, i'm not comparing it to HTTP, next to which anything is microscopic.) finally, security engineering is all about tradeoffs. some balance will be found between the size of the keys and signatures, the complexity of the algorythms, and the economic realities of the market. i see a big overlap. --vix ] ------- Message 3 subquestion 1: if the spammer is your customer. They couldn't inject the route unless they registered with us first and that process should disallow it if it's unregistered. Using the IP address wouldn't get caught yet, we are waiting for Cengiz to add ingress filtering to RtConfig so we can build the filters out of the policy info stored at RADB. subquestion 2: if the spammer is a customer of one of your BGP peers. We only check that the route is tagged with an AS path that we are expecting to see from the peer so if they get it past the peer then we will believe it. subquestion 3: if the spamemr is a customer of a distant BGP-connected AS. We lose here since we believe what we get from our provider. ------- Message 4 > routing core allow it? subquestion 1: if the spammer is your customer. no. customers are considered dangerous when armed with BGP. they are AS and prefix fitlered. > subquestion 2: if the spammer is a customer of one of your BGP peers. Only if they're ASpath is valid by RA registries. We are not [yet! in my copious spare time we will be!] prefix filtering on peers. > subquestion 3: if the spamemr is a customer of a distant BGP-connected AS. n/a, if I read the question right. ------- Message 5 > routing core allow it? Yup, mostly. :( > subquestion 1: if the spammer is your customer. "No", but then we don't have any BGP customers either. We're in the process of creating a BGP service for those customers that want it. I'll be collecting this thread from NANOG as part of the argument to make sure we "do it right" and get the resources to make sure the answer to this question will remain "no". Of course, if the customer was multihomed we might still learn the route via the method in subquestion 3 because it would be a false assumption to apply the same filters to what we learn via their other upstreams as to what they announce to us. (Hmm. but we could make it a true assumption by writing the contract carefully... "tell us all routes you expect to originate in your AS even if you don't plan to announce them to us because we will filter you on our other borders too" ;) [ this is pretty common. no potential customer is going to choose a different provider based on this restriction -- or if they do, you're better off. --vix ] > subquestion 2: if the spammer is a customer of one of your BGP peers. "yes, unless RFC1918 addresses". I'm hoping to overbudget for the above so that we can change this to a "no" as well. That would probably rely on IRR data, which is also open to fakery, but the filter reloads wouldn't be realtime so it should still block 5 minute announcements. > subquestion 3: if the spamemr is a customer of a distant BGP-connected AS. "yes, unless RFC1918 addresses". I notice that some of our "big" transit providers trust whatever some of the other "big" backbone carriers feed to them. It's interesting to see networks belonging to peering LANs at various IXPs show up from time to time. I'm not sure that this can be easily fixed. Maybe the solution is similar to the IP filtering one, in that it only works when everyone filters at all the 'little' BGP sessions so that we can then 'trust' what our backbones feed us. > i've sent reply-to to myself. i will summarize responses back to the list. Thanks for making me think. Do you realise that you accidentally posted something of operational content and interest to NANOG ? [ i didn't mean to. it was the only audience i could think of for my question. i don't think i'm part of a trend of any kind, though. --vix ] ------- Message 6 > up before now. I guess spamming was the first natural application for it. If we required all mail relayers to have valid in-addr.arpa DNS, this would be a non-issue. Unfortunately, when I used sendmail rules to enforce that, too many valid (but clueless) sites were prevented from passing mail into FDT, and I had to back down. [ the in-addr.arpa tree was never really populated at all the way it is now until uunet.uu.net, then the net's largest ftp server in the days before the web or even gopher, started requiring forward/reverse matches for all inbound anonftp connections. i think the progress we collectively made then is about all we can expect for the remainder of the experiment. --vix ] > (5) to the extent that abusers of unallocated space are spammers, the MAPS > RBL is the only short term hope i have of controlling this. How impractical would it be to put all unallocated space in the RBL?? [ i did that today, but it's somewhat hopeless since i'm advertising /8's and the address thieves only need to offer something longer. it's time to hack on gated some and get it to automatically warn me when a more-specific comes in and occludes a particularly-tagged static. --vix ] It's hard to believe spam providers have stooped to this level...but assuming they have, I suppose the next step would be temporary theft of address space, though that would probably generate a lot more heat for them. The run of the mill small ISP or business on the net might not even notice a 5 minute interruption of routing, and would certainly lack the ability to track down those responsible. [ indeed. while this has been done from time to time it was always with the intent of doing harm to the network's owner, not just to steal their identity for various purposes. next april 1 we should see some demon- strations of this concept in hopefully friendly ways. --vix ] ------- Message 7 ***SEE the end re 7777:x communities for your BGP announcments*** >routing core allow it? In to us from the world? YES Out from us? We ingress filter most but not quite all customer traffic, so NO >subquestion 1: if the spammer is your customer. regular customer, NO (see above), BGP speaking customer (i provide transit for) YES - they are FEW and trusted. I may be using terms differently... I am using "BGP peer" as a peering point NO TRANSIT either way connection. >subquestion 2: if the spammer is a customer of one of your BGP peers. I'd use his routes internally, but would not propagate them. >subquestion 3: if the spamemr is a customer of a distant BGP-connected AS. We would pass it all like any other traffic. BUT, I was delighted to see you have now decided to blackhole them but have a problem perhaps you can help with! We are subscribed to your BGP blackhole system but are not currently using it internally because we had objections from downstream ISPs that hate spam but also are leary of censorship. I need to work out a scheme where I can selectively apply the blackholing routes for the rest of my customers, probably right into my 2501 at each of their sites! [ i think you should just use the DNS access method in that case. --vix ] However I would LOVE to immediately use the ones you send for unassigned blocks - all the /8s you listed in other email. PLEASE decide on a community or whatever to tag them with so I and others can selectively use this subset of the blackhole system, and skip the others for now. And, while you are at it, perhaps there are some other subtle subdivisions that also could benefit from having their own community. I assume the most logical community conventions would be 7777:x and x would be on a published list of special tags. Some thought might be made to more complex situations where a route might have multiple communities and could be tested for appropriately if it were known that that possibility existed. [ the gated version i'm using doesn't support communities at all. when it does, i will do what you said. --vix ] Also on your /8 announcements, won't the tighter masks of spammer 5 minute announcements override your /8 or am I missing something? [ yes. but i felt that the symbolic gesture was better than nothing. actually i think the IANA ought to be advertising real routes for these, blackholed of course, just to keep somebody else from camping on "by accident" as happens every year or two. --vix ] ------- End of Forwarded Messages

1 0