- Test - lists.nanog.org

Re: Affects of the balkanization of mail blacklisting
by Paul Vixie 13 Aug '01

13 Aug '01

> If one wants to make MAPS-like functionality a part of the Internet, at > large, then that's where one might go. Clarify your thoughts, write them > into a proposal and bring it to either the IETF, the ASO, or both. This will never happen. There can never be an AUP involved in the allocation of addresses. Even the simple matter of "is this address block being used for virtual web hosting and if so have all alternatives been explored?" was a huge political headache. Questions like "do other people actually want to receive the traffic you want to send them?" would be utterly unanswerable (and for that matter, unaskable) at the ICANN/ASO/IETF level.

1 0

RE: Affects of the balkanization of mail blacklisting
by Roeland Meyer 13 Aug '01

13 Aug '01

APNIC, ARIN, and RIPE are now *the* members of the Address Supporting Organization (ASO) of the ICANN. Just as, IETF is now a part of the Protocol Supporting Organization (PSO). This could turn into a globally over-arching problem. MAPs has a large user base that is international in scope. It also appears to be cross-domain (addresses AND names). However, it would appear to be a largely ASO issue, since it directly effects IP address block policies (YMMV). If one wants to make MAPS-like functionality a part of the Internet, at large, then that's where one might go. Clarify your thoughts, write them into a proposal and bring it to either the IETF, the ASO, or both. Understand that much of the process is still being defined and there is a serious lack of participation from those that should participate. But, it may still be your best approach. I work in the ICANN/DNSO and have no serious connections in the ICANN/ASO and only slight contact in the ICANN/PSO. > From: miquels(a)cistron-office.nl [mailto:miquels@cistron-office.nl] > Sent: Monday, August 13, 2001 2:37 AM > > In article <1100507318.997532919(a)[192.168.0.2]>, > Margie <margie(a)mail-abuse.org> wrote: > >MAPS as a corporation must have revenue to operate. > > Has MAPS ever talked to organisations like RIPE and ARIN? > Most providers > are a paying member of those anyway. MAPS might or could be > an organisation > just as important for the continuity of the internet as those ones. > If you could persuade them to work together and let them offer MAPS to > their members and pay the bill ..

1 0

AS2548... Do you care?
by John Fraizer 13 Aug '01

13 Aug '01

08/07/01 Internet Routing Problems Reserved AS Numbers ------------------- AS64620 at Mae-West from Digex (AS2548) ASPATH=2548 64620 20246 20246 IGP 08/08/01 Internet Routing Problems Reserved AS Numbers ------------------- AS64620 at Mae-West from Digex (AS2548) ASPATH=2548 64620 20246 20246 IGP 08/09/01 Internet Routing Problems Reserved AS Numbers ------------------- AS64620 at Mae-West from Digex (AS2548) ASPATH=2548 64620 20246 20246 IGP 08/10/01 Internet Routing Problems Reserved AS Numbers ------------------- AS64620 at Mae-West from Digex (AS2548) ASPATH=2548 64620 20246 20246 IGP And it's still there right now: (results from nitrous.digex.net) BGP routing table entry for 199.253.174.0/24, version 31188140 Paths: (3 available, best #3) Advertised to peer-groups: rr-pop maeeast-atm 64620 20246 20246 209.116.242.118 (metric 215601) from 165.117.1.53 (165.117.2.30) Origin IGP, metric 0, localpref 110, valid, internal Community: 2548:999 3706:130 Originator: 165.117.2.30, Cluster list: 165.117.1.53 64620 20246 20246 209.116.242.118 (metric 215601) from 165.117.1.228 (165.117.2.30) Origin IGP, metric 0, localpref 110, valid, internal Community: 2548:999 3706:130 Originator: 165.117.2.30, Cluster list: 165.117.1.228 64620 20246 20246 216.1.71.34 (metric 105501) from 165.117.1.77 (165.117.1.77) Origin IGP, metric 0, localpref 110, valid, internal, best Community: 2548:999 3706:132 BGP routing table entry for 199.253.174.0/24, version 35137771 Paths: (3 available, best #3) Advertised to peer-groups: pen-nap1 Advertised to non peer-group peers: 192.157.69.9 192.157.69.10 192.157.69.22 192.157.69.63 64620 20246 20246 209.116.242.118 (metric 210201) from 165.117.1.53 (165.117.2.30) Origin IGP, metric 0, localpref 110, valid, internal Community: 2548:999 3706:130 Originator: 165.117.2.30, Cluster list: 165.117.1.53 64620 20246 20246 209.116.242.118 (metric 210201) from 165.117.1.228 (165.117.2.30) Origin IGP, metric 0, localpref 110, valid, internal Community: 2548:999 3706:130 Originator: 165.117.2.30, Cluster list: 165.117.1.228 64620 20246 20246 216.1.71.34 (metric 100101) from 165.117.1.77 (165.117.1.77) Origin IGP, metric 0, localpref 110, valid, internal, best Community: 2548:999 3706:132 BGP routing table entry for 199.253.174.0/24, version 32354441 Paths: (3 available, best #3) Advertised to peer-groups: rr-pop maewest Advertised to non peer-group peers: 198.32.136.1 198.32.136.2 198.32.136.11 198.32.136.31 198.32.136.129 64620 20246 20246 209.116.242.118 (metric 450701) from 165.117.1.53 (165.117.2.30) Origin IGP, metric 0, localpref 110, valid, internal Community: 2548:999 3706:130 Originator: 165.117.2.30, Cluster list: 165.117.1.53 64620 20246 20246 209.116.242.118 (metric 450701) from 165.117.1.228 (165.117.2.30) Origin IGP, metric 0, localpref 110, valid, internal Community: 2548:999 3706:130 Originator: 165.117.2.30, Cluster list: 165.117.1.228 64620 20246 20246 216.1.71.34 (metric 340601) from 165.117.1.77 (165.117.1.77) Origin IGP, metric 0, localpref 110, valid, internal, best Community: 2548:999 3706:132 BGP routing table entry for 199.253.174.0/24, version 8526987 Paths: (3 available, best #3) Advertised to peer-groups: rr-pop decnap1 Advertised to non peer-group peers: 165.117.68.178 207.88.240.73 209.133.31.53 64620 20246 20246 209.116.242.118 (metric 350401) from 165.117.1.53 (165.117.2.30) Origin IGP, metric 0, localpref 110, valid, internal Community: 2548:999 3706:130 Originator: 165.117.2.30, Cluster list: 165.117.1.53 64620 20246 20246 209.116.242.118 (metric 350401) from 165.117.1.228 (165.117.2.30) Origin IGP, metric 0, localpref 110, valid, internal Community: 2548:999 3706:130 Originator: 165.117.2.30, Cluster list: 165.117.1.228 64620 20246 20246 216.1.71.34 (metric 240301) from 165.117.1.77 (165.117.1.77) Origin IGP, metric 0, localpref 110, valid, internal, best Community: 2548:999 3706:132 --- John Fraizer EnterZone, Inc

5 5

RE: Code Red 2 cleanup; reporting..
by Roeland Meyer 12 Aug '01

12 Aug '01

> From: David Lesher [mailto:wb8foz@nrk.com] > Sent: Sunday, August 12, 2001 5:46 AM > > Unnamed Administration sources reported that mike harrison said: > > > Turns out that because they had not installed IIS, they did > not patch the > > system.... > > > > Then when they installed Citrix, it installed IIS. > > > > After looking around, it seems a LOT of 'other' software > > installs IIS when no-one is looking. > > Like Front Page ;-? > > Isn't it nice that M$ is so helpful? I think that the point's been well-made now. Win2Kpro hosts need to run the patches, regardless of whether or not anyone *thinks* that host is running IIS and regardless of any nit-picky arguments against the need. NetAdmins should quit whining and do their jobs. I still LOVE this sig-line.... > -- > A host is a host from coast to coast.................wb8foz(a)nrk.com > & 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 dead....................................20915-1433 >

2 1

Re: Code Red 2 cleanup; reporting..
by Steven M. Bellovin 12 Aug '01

12 Aug '01

In message <Pine.LNX.4.10.10108100034440.14898-100000(a)home.highertech.net>, mik e harrison writes: > >> Spent nearly two days convincing someone who was managing a server that he >> was beating up machines all over the company. It finally took someone at > >Tonight, 20 minutes after openning up port 80 >on a firewall to a server supposedly only running >the latest CITRIX on Port 80 (why 80? Don't ask me?) >and the high paid out of town consultants swearing they >had applied the appropriate patches and were safe, >they are now broadcasting out the latest CodeRed style worm. > >I got some nice sniffit captures from my Linux firewall >though.. this morning will be interesting. I wonder >how they like their crow served. > > > > I've seen a report that the patch is not fully effective -- see http://archives.neohapsis.com/archives/incidents/2001-08/0218.html. That was on incidents.org last night, but it's gone this morning, so maybe that claim isn't accurate. --Steve Bellovin, http://www.research.att.com/~smb

3 2

RFC warz?
by Roeland Meyer 12 Aug '01

12 Aug '01

> From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] > Sent: Sunday, August 12, 2001 12:31 AM > On the other hand, we've had RFC1918 filtering wars recently - I don't > recall flame-fests about martian AS numbers lately ;) ... and there are RFC920 and RFC1591 warz. Frankly, it's *all* tiresome! Some of us need to get-a-life(tm).

1 0

RE: Affects of the balkanization of mail blacklisting
by Roeland Meyer 11 Aug '01

11 Aug '01

> From: Margie Arbon [mailto:margie@mail-abuse.org] > Sent: Saturday, August 11, 2001 11:42 AM > Subscribers are obligated contractually to maintain current > zone files. Yes, but does MAPS have the resources to enforce the contract?

3 2

SP's & network security issues
by Christian Kuhtz 11 Aug '01

11 Aug '01

Hey there, so, you want to be a good citizen and stewart of the inet. DDoS and security after security attack happens, it won't ever stop. You try to do the best you can to effectively respond to it. You try to inform you customers. You try to educate them. Yet, you realize that you're not doing enough... What do the rest of you SPs actually do to combat this threat? How do you keep the hype, fear, panic and dispair of your management team (all the way to the CEO) in check? And that of your customers? Some of it is sometimes warranted.. but, got any ideas for crowd control? In our case, we have several hundred thousands of DSL customers today, and the million plus subscriber mark is on the engineering horizon. The problem of security threats & resulting incidents is going to get considerably worse before it gets better. And that's for at least two reasons.. the ramp up of broadband and presumably the declining sophistication of the subscriber population as a result of the greater market penetration. Sure, you can try to teach your subscribers to protect themselves. But this is really not the answer. How many unsophisticated subscribers are going to be able to do this in an effective and timely manner? What do you do in response? How do you effectively scale the massive support effort need for collaborative marketing of personal firewalls and the potential for false positives and negatives? Any ideas on the legal exposure of security services? Like, in the current case, several providers have resorted to blocking port 80 to their non-DIA subscriber base. Is this really scalable? Obviously not for every threat. You can't effectively keep this up with the myriad of threats. Or can you? Is it realistic to be able to maintain your own NIDS patterns with the help of your own staff and public resources? Are options like security service providers the only workable option? Do they work at all? How effective are they? IDS will obviously only work against known threats.. how do you create an effective early warning system? How do you provide effective vaccination against an unknown threat? How do you respond to potentially massive infections of your subscriber base? Potential zombie manifestations in the 100k's are easily possible. They really do make Code Red's impact to date seem more like a case of a mild flu than any serious infection. So, you do have a responsibility to your customers to protect them. To what extent is this realistic, though? Doesn't this also bear the risk of false security or even potential legal liabilities? How do you manage this risk? You do have also a responsibility to "protect" the rest of the world from zombie gatherings among your subscribers. Same questions apply. So, I think it's clear that something needs to be done, but coming up with a definitive plan of attack is everything but trivial. This obviously doesn't just apply to DSL, it applies to Cable and whatever other broadband networks are out there or will evolve... We want to be a good stewart and citizen of the inet, yet, these questions are tough to answer in any satisfactory way it seems. (Yes, I've taken some of these questions to various security forums from time to time, but none of them seem to represent a significant number of SPs; suggestions are very welcome). I'm sure this isn't a comprehensive list.. but, perhaps, it'll get a useful conversation going. Hey, I can hope, right? Cheers, Chris -- Christian Kuhtz <ck(a)arch.bellsouth.net> -wk, <ck(a)gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only."

5 7

RE: Code Red 2 cleanup; reporting..
by Roeland Meyer 11 Aug '01

11 Aug '01

[HTML formatting removed] I should have been more clear [comments about nit-picky bit-heads, removed]. Win2K Active Directory clients run some parts of IIS, in order to support Active Directory. Even if, you never installed IIS explicitly. Especially, there is some serious LDAP/IIS integration here. Note the option to share a directory on the web, how do you think that happens? Also note that, users very often don't understand the difference between SMB file sharing and Web Sharing and Win2K goes to great lengths to obfuscate those two anyway. Win2K is a major re-write of the Domain Controller and its clients. Expect large bugs, roaches the size of small dogs. MSFT [lack of] design QA is well known. If you've never built large software systems, you'd not know that you can integration-test the hell out of one [large software system] and still never catch design flaws because it all meets specification. It is the specifications that are wrong. The exploit that CodeRed uses is a classic example. The only thing that works there is remorseless/ruthless high-level architectural peer review. MSFT doesn't do those. They replace that process with a bazillion integration testers. -----Original Message----- From: Tim Devries [mailto:Tim.Devries@Q9.com] Sent: Friday, August 10, 2001 8:23 AM To: 'Roeland Meyer'; 'up(a)3.am'; nanog(a)merit.edu Subject: RE: Code Red 2 cleanup; reporting.. -----Original Message----- From: Roeland Meyer [mailto:rmeyer@mhsc.com] Sent: Friday, August 10, 2001 11:22 AM To: 'up(a)3.am'; nanog(a)merit.edu Subject: RE: Code Red 2 cleanup; reporting.. > From: up(a)3.am [mailto:up@3.am] > Sent: Friday, August 10, 2001 8:09 AM > > On Fri, 10 Aug 2001, Roeland Meyer wrote: > > > Win2K boxen are ALWAYS running IIS. It doesn't matter > whether you have Pro > > or Server. ALL Win2K systems need to run the patch. MSFT > chose to integrate > > much of the IIS stuff into DLLs with other system critical > stuff. As a > > result, IIS can't be completely removed without killing off > other critical > > functions. Yes, what they proved in court is even more true > with Win2K than > > with Win98 (Duh! MSFT didn't lie, but they didn't tell the > whole truth > > either). WinXP is even more in that direction, from all reports. > > I admit to knowing very little about Win2k, but on the only box I've > installed Win2k on, it doesn't *appear* to be running: > > Port State Protocol Service > 135 open tcp loc-srv > 139 filtered tcp netbios-ssn > 445 open tcp microsoft-ds > 1025 open tcp list > > ...unless it runs on one of those 3 other open ports? This was Win2k > Client, not server, BTW...perhaps you mean every Win2k Server? Win2k proffesional can run IIS. Goto add remove programs -->add/remove windows components ---> IIS. You probably did not select the component on the install. So I guess that means that not every w2k box is vulnerable. Tim

3 2

The Cidr Report
by CIDR Report 11 Aug '01

11 Aug '01

This is an auto-generated mail on Fri Aug 10 23:00:00 PDT 2001 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. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. 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 GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 10Aug01 0) General Status Table History ------------- Date Prefixes 030801 102236 040801 102194 050801 102268 060801 102340 070801 102456 080801 102930 090801 103092 100801 102845 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 82.105.0.0/16 from AS3269 *** Bogus 82.105.128.0/17 from AS3269 AS Summary ---------- Number of ASes in routing system: 11345 Number of ASes announcing only one prefix: 6735 (3850 cidr, 2885 classful) Largest number of cidr routes: 862 announced by AS701 Largest number of classful routes: 1396 announced by AS701 1) Gains by aggregating at the origin AS level --- 10Aug01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1251 962 289 23.1% Telstra Pty Ltd AS701 1396 1186 210 15.0% UUNET Technologies, Inc. AS2551 748 601 147 19.7% ICG NetAhead, Inc AS4151 288 164 124 43.1% USDA AS4293 391 279 112 28.6% Cable & Wireless USA AS4755 257 147 110 42.8% Videsh Sanchar Nigam Ltd. Autonom AS6595 163 57 106 65.0% DoD Education Activity Network As AS577 294 188 106 36.1% Bell Advanced Communications Inc. AS6429 203 102 101 49.8% AT&T Chile Internet S.A. AS13999 108 12 96 88.9% Mega Cable S.A. de C.V. AS705 233 141 92 39.5% UUNET Technologies, Inc. AS7018 735 646 89 12.1% AT&T AS16473 151 65 86 57.0% Bell South AS7046 325 253 72 22.2% UUNET Technologies, Inc. AS724 222 156 66 29.7% DLA Systems Automation Center AS6471 122 60 62 50.8% ENTEL CHILE S.A. AS12302 93 32 61 65.6% MobiFon S.A. AS4200 126 66 60 47.6% Apex Global Information Services, AS1239 455 396 59 13.0% Sprint AS3464 149 91 58 38.9% Alabama SuperComputer Network AS16758 63 6 57 90.5% IKON Office Solutions AS703 301 246 55 18.3% UUNET Technologies, Inc. AS3908 325 270 55 16.9% Supernet, Inc. AS1 547 492 55 10.1% BBN Planet AS226 147 94 53 36.1% Los Nettos AS6413 65 13 52 80.0% Southern Online Systems, Inc. AS4323 242 190 52 21.5% Time Warner Communications, Inc. AS17561 113 62 51 45.1% Internet service provision to Wes AS852 214 164 50 23.4% Telus Advanced Communications AS9842 54 5 49 90.7% Lotte Data Communication Company 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