- Test - lists.nanog.org

The Cidr Report
by Tony Bates 20 Feb '98

20 Feb '98

This is an auto-generated mail on Fri Feb 20 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 20Feb98 0) General Status Table History ------------- Date Prefixes 050298 49484 140298 49400 150298 49226 160298 49509 170298 49589 180298 49307 190298 49418 200298 49181 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: 3244 Number of ASes announcing only one prefix: 1560 (801 cidr, 759 classful) Largest number of cidr routes: 441 announced by AS3561 Largest number of classful routes: 1074 announced by AS701 1) Gains by aggregating at the origin AS level --- 20Feb98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 707 435 272 38.5% iSTAR Internet, Inc. AS6235 525 261 264 50.3% Intermedia Communications, Inc. AS4293 434 210 224 51.6% IMCI AS816 585 420 165 28.2% UUNET Canada (ASN-UUNETCA-AS4) AS3602 458 305 153 33.4% Sprint Canada Inc. AS174 775 627 148 19.1% Performance Systems International AS3749 198 55 143 72.2% TECNET AS701 1074 950 124 11.5% Alternet AS3751 125 48 77 61.6% SNET-AS AS5668 109 37 72 66.1% Century Telephone Inc. AS3804 204 142 62 30.4% WORLDLINX AS1239 590 528 62 10.5% SprintLink Backbone AS3221 92 32 60 65.2% EENet Autonomous System AS271 112 56 56 50.0% BCNET-AS AS3464 121 66 55 45.5% Alabama Research and Education Ne AS72 84 36 48 57.1% Schlumberger Information Network AS1221 263 215 48 18.3% AARNET-AS AS549 205 158 47 22.9% ONET-AS AS4755 78 34 44 56.4% Videsh Sanchar Nigam Ltd. India AS2711 98 55 43 43.9% SUNBELT-AS AS7046 131 89 42 32.1% UUNET-CUSTOMER AS3561 883 842 41 4.6% MCI AS852 157 117 40 25.5% CANET-ASN AS684 86 46 40 46.5% MBNET-AS AS6335 63 23 40 63.5% NTRNET AS4740 348 308 40 11.5% ASN-OZEMAIL (Ozemail Pty Ltd) AS1 789 749 40 5.1% BBNPLANET AS6181 63 24 39 61.9% FUSE-NET AS3493 166 128 38 22.9% INTERLINK AS719 432 395 37 8.6% LANLINK autonomous system 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: Bellovin sez...
by Eric Sobocinski 20 Feb '98

20 Feb '98

They could, that is, unless everyone to whom the hacker attached was doing ingress BGP filtering for all peers/downstreams. I'm sure my Merit RA comrades would be glad to jump in with a plug that IRR and route servers could help facilitate this, as would the varied groups that are working on authenticating network allocations of incoming routes. But that of course was your point. :-) --eric <ducking in case he started a religious war> On Fri, 20 Feb 1998 at 09:29 PST, Michael Dillon <michael(a)memra.com> wrote: > > Here's a quote from this story > http://www.techweb.com/wire/story/TWB19980220S0001 > > Both Bellovin and his AT&T colleague Matt Blaze cited the vulnerability > of the Net's decentralized routing system, .... This routing > information has been accidentally corrupted several times, they said, > resulting in massive traffic flows being rerouted through single slow > machines or blocked altogether. > > They said a hacker could also cause this kind of corruption. > > -- > Michael Dillon - Internet & ISP Consulting > http://www.memra.com - E-mail: michael(a)memra.com

2 1

Bellovin sez...
by Michael Dillon 20 Feb '98

20 Feb '98

Here's a quote from this story http://www.techweb.com/wire/story/TWB19980220S0001 Both Bellovin and his AT&T colleague Matt Blaze cited the vulnerability of the Net's decentralized routing system, .... This routing information has been accidentally corrupted several times, they said, resulting in massive traffic flows being rerouted through single slow machines or blocked altogether. They said a hacker could also cause this kind of corruption. -- Michael Dillon - Internet & ISP Consulting http://www.memra.com - E-mail: michael(a)memra.com

2 1

Re: SMTP spoofing ?
by owen＠DeLong.SJ.CA.US 20 Feb '98

20 Feb '98

I believe some trickery with the NAT features in the AS5200 from Cisco might be a possibility. Owen > Are there any routers currently available that can do port 25 spoofing for > dialup users? That is, when the user attempts to connect to port 25 > anywhere, he in fact connects to port 25 on your own SMTP server instead. > > In case it's not obvious, it's for spam management. > > Regards, > John Levine, johnl(a)iecc.com, Primary Perpetrator of "The Internet for Dummies", > Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner > Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47 > >

1 0

Re: Smurfing
by Alex P. Rudnev 19 Feb '98

19 Feb '98

To summarise all answers I'h got to my question: - there is RFC recommendations about implementation for this filtering; - CISCO have such filtering in their new forwarding scheme; - there is (already) experimental IOS images supported such filtering; - for now, this filtering is not possible (in CISCO) at the access servers, but at the core routers only. This means something like _CISCO know about this problem and work around it, but there is technical problems in implementing this for the low-end routers_ - this is as I understood all answers (not only from CISCO). Thanks to all who have answered. Aleksei. On Thu, 19 Feb 1998, Tatsuya Kawasaki wrote: > Date: Thu, 19 Feb 1998 09:08:53 +0900 (JST) > From: Tatsuya Kawasaki <tatsuya(a)giganet.net> > To: "Alex P. Rudnev" <alex(a)Relcom.EU.net> > Subject: Re: Smurfing > > thnx for the info and correcting what I said. > > tatsuya > > > > > $B$+$o$5$-(B > > > = = = = = = > $BEEOC(B 03-3239-0607 fax 03-3239-2609 > business network telecom > http://www.giganet.net > > On Wed, 18 Feb 1998, Alex P. Rudnev wrote: > > > CISCO can filter by any SRC address. The only question I am asking every > > time is _would CISCO can do it by default and by direct routing tables?_. > > THis means something like: > > > > interface xxx > > ip src-filtering selfpaths > > > > and that means _packet from interface xxx should be received ONLY if SRC > > address should be routed to the same interface_ (if you have > > 193.124.25.0/24 network statically routed to your interface, and address > > 194.58.1.1/30 on this interface, you can only send packets with the SRC > > addresses 193.124.25.0/24 and 194.58.1.1/30. > > > > And it's important to understand _IT SHOULD BE DEFAULT BEHAVIOUR ON THE > > ACCESS SERVERS_ (may be controlled by some extra comman), so that any > > (even dumb) network administrators could use this property withouth extra > > configuration. > > > > ------------------- > > > > > > > > > > On Wed, 18 Feb 1998, Tatsuya Kawasaki wrote: > > > > > Date: Wed, 18 Feb 1998 10:36:32 +0900 (JST) > > > From: Tatsuya Kawasaki <tatsuya(a)giganet.net> > > > To: nanog(a)merit.edu > > > Cc: Paul Ferguson <pferguso(a)cisco.com> > > > Subject: Re: Smurfing > > > > > > paul, > > > it sounds a good idea but is it possible? > > > I don't think cisco can filter by wrong SRC address bases. > > > ^^^^^ > > > you still can use still use any ip on the same segment. > > > (Big deal, huh? :-) ) > > > Furthermore, it will cause some problem for Mobile IP stuff, > > > if I remember correctly. > > > > > > regards, > > > > > > tatsuya > > > > > > > > > On Tue, 17 Feb 1998, Bradley Reynolds wrote: > > > > > > > > See RFC2267. > > > > > > > > > > - paul > > > > > > > > > > > > > > > > Good news. > > > > > > > > > > > > One more question (just is there is someone from the CISCO) - what's > > > > > > about source-address filtering at default for the access servers/routers? > > > > > > Note all this problems (SMURF, DENIAL-ATTACK, DNS-FRAUDING, etc etc) can > > > > > > be 100% blocked if ISP would not allow it's customers to send IP packets > > > > > > with the wrong SRC address. If not, they (hackers) should found new, new > > > > > > and new tricks to fraud any IP network. > > > > > > > > > > > > > > > You can apply the RPF idiom from multicast to block unicast > > > > flooding. This would instantly solve the problem, though I am > > > > not sure what overhead the path evaluation would incur. > > > > > > > > BR > > > > > > > > brad(a)iagnet.net > > > > > > > > > > > > > > > > > > Aleksei Roudnev, Network Operations Center, Relcom, Moscow > > (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) > > (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax) > > > > > > Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

1 0

Re: SMTP spoofing ?
by sully＠mail.usinternet.com 19 Feb '98

19 Feb '98

Yes, NAT on cisco's. Tim Sullivan Network Hobbyist At 11:52 AM 2/19/98 -0500, you wrote: >Are there any routers currently available that can do port 25 spoofing for >dialup users? That is, when the user attempts to connect to port 25 >anywhere, he in fact connects to port 25 on your own SMTP server instead. > >In case it's not obvious, it's for spam management. > >Regards, >John Levine, johnl(a)iecc.com, Primary Perpetrator of "The Internet for Dummies", >Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner >Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47 > > ------------------------------------------------------------------ Tim Sullivan Senior Technical Administrator/Support/Network Consultant http://www.usinternet.com US Internet Corp - Full Service Internet Provider "Get your Net's Worth" (tm) (612) 222-4638 ------------------------------------------------------------------

1 0

Internic WHOIS down?
by chris＠unix.org 19 Feb '98

19 Feb '98

The whois database has been up and down (mainly down when I've tried to use it) for about two days now .. anyone know why/when it'll be fixed? -- Chris Portman ================================================= chris(a)unix.org Senior Systems Operations and Security PSI Canada Ltd (Formerly ISTAR) (613) 788-7767 Ottawa, ON, CA

3 2

[non-op] Philippines language, culture stuff
by miguel a.l. paraz 18 Feb '98

18 Feb '98

In case you didn't know, practically everyone in Manila (down to the bus driver) can speak basic English. ISP personnel will speak very good English, except for the usual context/grammar changes. Thank you America for 1900-1946, but if you would like to help the APRICOT host country somehow and have a debt of gratitude, see <http://www.newprint.com/balangiga/balabann>, this is important to me. Thanks. ---m

1 0

[non-op] APRICOT, Manila web cam and other helpful info
by miguel a.l. paraz 18 Feb '98

18 Feb '98

Hi, If you really must *see* your colleague in Manila, we have a Color Connectix here hooked up to a Linux box. I'm currently setting it up at http://www.ph.apricot.net. I'm using the non-realtime cqcam for Red Hat/X and can do about a max of 5 pics per minute (currently driving it at 1/minute). Sorry, no sound cards available. If you want real videoconf, be prepared to pay a princely sum (US$2/minute) for ISDN Manila-US, or, help me configure something that runs on Win95/Linux/FreeBSD. For DIYers, get in touch with me to reserve some bandwidth (manually) on this line: ~ 300-500 copper circuit meters Shangri-La------------PLDT PHiX------Intelsat---------Teleglobe Hotel Manila 2 * 2 Mb/s 4 Mb/s Lands at Vancouver, BC <10 ms >600ms Transit: Sprint/MCI/UU/? | | 512 Kb/s, around 1 km away, <20ms | IPHIL.NET (AS4743, but static at the moment) mostly 203.176.0.0/18 | | 3 MB/s aggregate MCI PLDT == Philippine Long Distance Telephone PHiX == Yup, the telcos run the IXs here too I'm doing some tests here with persistent HTTP/1.1 (probably with Justin Newton if he comes by) and how it gives us a perceived 2x - 3x speedup (will see if we could roll the numbers later) I'm talking on this in a while (as well as a new way to look at the whole caching business, unless someone douses cold water on me. Basically you want your 1000 customers to have a 20 MB cache each rather than you maintain a 20 GB cache...) If you want the whole thing with pictures, we could work up something (ask your colleague to feed the IPhil Comms network engineering and consulting groups, any pizza appreciated) You can also check with me on the location of any particular person and his state of connectivity, if I know him... APRICOT won't make the reg database public, obviously. ISP connections are around US$1/hour (I can arrange one for you) but they usually need a ~US$30 non-refundable fee if it's more than 5/10 hours. GRIC/IPass have good local partners too. Cheers, ---m -- IPhil Communications Technology Group http://www.iphil.net +63-2-750-2288

1 0

Re: Smurfing
by Kelly J. Cooper 18 Feb '98

18 Feb '98

On Feb 13, 2:52pm, Randy Bush wrote: > Subject: Re: Smurfing *> o All router administrators on the immediately reachable *> Internet needs to turn off directed broadcasts on their router *> interfaces. It's conceivable that "a significant portion of *> all" would do as well, but the magnitude of this problem *> boggles the mind. First of all, we'd need to distribute the *> appropriate amount of clue to all the corners of the net where *> this needs to happen. Maybe, just maybe, we'll get there *> sometime (I'm an optimist!). * *why should this not have become the default mode for all vendor diustributed *router code? * *randy >-- End of excerpt from Randy Bush Perhaps because RFC 1812, "Requirements for IP Version 4 Routers" (which I believe is still current) needs to be updated/made obsolete? Excerpted from section 5.3.5: A router MAY have an option to disable receiving network-prefix- directed broadcasts on an interface and MUST have an option to disable forwarding network-prefix-directed broadcasts. These options MUST default to permit receiving and forwarding network-prefix- directed broadcasts. Or perhaps because the folks on this list haven't made it clear enough to their vendors that the default should be "off" <hint>. Kelly J.

7 9