- Test - lists.nanog.org

Re: Evil PGP sigs thread must die. was Re: Stop it with putting your e-mail body in my MUA OT
by Andy Dills 15 Jul '02

15 Jul '02

On Wed, 10 Jul 2002, Jordyn A. Buchanan wrote: > On 7/10/02 3:01 PM, "Andy Dills" <andy(a)xecu.net> wrote: > > > > Ah, and that's where the arrogance comment came from. You assume that the > > members of nanog care. I'm not trying to call you an arrogant person, and > > I recognize that you're not being blatantly arrogant, it's more of a > > passive assumption. The passive assumption is that your words are > > important enough that somebody might want to verify them. So, does EVERY > > email need to be pgp signed? > > If you don't reliably sign your e-mails, it becomes very easy for someone to > send a spoofed message without a signature and have people believe it is > authentic. If you do reliably sign your e-mails, then others may realize > that something is awry when an unsigned message is sent out. Even if the > signatures are rarely checked, consistency of signing is a useful function > by creating an expectation of trusted communications. Uhm, one HUGE problem with that. If people judge authenticity based on the simple fact that a message is signed, that's just as useless. Why wouldn't the spoofed email be signed with somebody else's key, to make it past all those people who merely check to see if it's signed? The _only_ way to verify authenticity is to check the signature. By signing every single email sent, you endanger yourself by allowing your recipients to judge the authenticity of your emails simply by the existence of a pgp signature. Therefore, you should only sign emails that contain information important enough that verification is necessary, otherwise nobody will check. Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access

4 3

DNS was Re: Internet Vulnerabilities
by Simon Waters 15 Jul '02

15 Jul '02

> From: Paul Vixie <vixie(a)vix.com> > > mike(a)sentex.net (Mike Tancsa) writes: > > > ... Still, I think the softest targets are the root name > servers. I was > > glad to hear at the Toronto NANOG meeting that this was > being looked into > > from a routing perspective. Not sure what is being done > from a DoS > > perspective. I think the gtld-servers.net are the target for a globally disruptive and prolonged DDoS. Servers doing reverse lookup might also be targets in more specialised attacks, as their disruption would be continent wide rather than merely country wide (like most forward look ups). Paul obviously has the experience to tell me if I'm crazy, but I would guess the "." zone probably isn't that large in absolute terms, so large ISPs (NANOG members ?) could arrange for their recursive servers to act as private secondaries of ".", thus eliminating the dependence on the root servers entirely for a large chunks of the Internet user base. To set up such a backup plan during a DDoS against the root name servers might be challenging, but it isn't impossible, it would also stop large ISPs DNS servers forwarding daft queries onto the root DNS servers, thus lowering the load on the root-servers when they need it most! So whilst the root servers make the obvious target they are also in some ways a relatively easy target to move, or expand in number. I think private secondaries are a better bet than new root servers, as that would require trusting less experienced admins with all of the Internet's DNS, rather than just ISP users trusting their ISP (which they do implicitly already). I think the kinds of zones being handled by the gtld-servers would be harder to relocate, if only due to size, although the average NANOG reader probably has rather more bandwidth available than I do, they may not have the right kind of spare capacity on their DNS servers to secondary ".com" at short notice. > Now that we've seen enough years of experience from > Genuity.orig, UltraDNS, > Nominum, AS112, and {F,K}.root-servers.net, we're seriously > talking about using > anycast for the root server system. We have even more experience at zone transfers with DNS, and it doesn't require complicating anything lower than layer 7, which has an appeal to me, and I suspect most ISPs who probably have enough trouble keeping BGP in order. All I think root server protection requires is someone with access to the relevant zone to make it available through other channels to large ISPs. There is no technical reason why key DNS infrastructure providers could not implement such a scheme on their own recursive DNS servers now, and it would offer to reduce load on both their own, and the root DNS servers and networks. Other DNS admins could change their caching servers to forward to their ISPs name servers - and whilst forwarding might be frowned on by the DNS community, the hierarchical caching model is typically faster than the current approach, and more scalable, if potentially less secure (poisoning of a tier in the hierarchy is bad news - theoretically we lose some redundancy, although forward-first might address that, and some current DNS server implementations do not support this model as well as they could - undoubtably such a scheme would lead to more small disruptions but presumably avoid the "one big one" being discussed). The single limiting factor on implementing such an approach would be DNS know-how, as whilst it is probably a two line change for most DNS servers to forward to their ISPs DNS server (or zone transfer "."), many sites probably lack the inhouse skills to make that change at short notice. In practical terms I'd be more worried about smaller attacks against specific CC domains, I could imagine some people seeing disruption of "il" as a more potent (and perhaps less globally unpopular) political statement, than disrupting the whole Internet. Similarly an attack on a commercial subdomain in a specific country could be used to make a political statement, but might have significant economic consequences for some companies. Attacking 3 or 4 servers is far easier than attacking 13 geographically diverse, well networked, and well protected servers. Similarly I think many CC domains, and country based SLD are far more "hackable" than many people realised due to the extensive use of out of bailiwick data, as described by DJB. At some point the script kiddies will realise they can "own" a country or two instead of one website, by hacking one DNS server, and the less well secured DNS servers will all go in a week or two.

4 3

Re: QoS/CoS in the real world?
by Art Houle 15 Jul '02

15 Jul '02

On Mon, 15 Jul 2002, Peter John Hill wrote: > --On Sunday, July 14, 2002 9:26 PM -0400 Art Houle > <houle(a)zeppo.acns.fsu.edu> wrote: > > On Sun, 14 Jul 2002, Marshall Eubanks wrote: > > >> On Sun, 14 Jul 2002 21:13:13 -0400 (EDT) > >> Art Houle <houle(a)zeppo.acns.fsu.edu> wrote: > >> Or, to put it another way, how are the packets marked ? And why not just > >> drop them then and there, instead of later ? > > > If we are not using our WAN connections to capacity, then p2p traffic can > > expand and fill the pipe, but if business packets are filling the pipes, > > then the p2p stuff is throttled back. This makes 100% use of an expensive > > resource. > > So, you are doing straight tcp port filtering. Are there any clients that > use dynamic ports? Things will get trickier for you. Other than Packetteer, > are there any other products that can look into the data of a packet at any > usable rate to do filtering/marking? > We look at ports mostly to mark the packets, but we are also using cisco 'pdlm' to discover the p2p stuff. We are not doing port filtering to drop packets, WFQ is doing the drop function. policy-map cbwfq2ISPonPVC class class-default random-detect dscp-based random-detect dscp 0 5 10 8 random-detect dscp 8 15 22 16 random-detect dscp 16 20 30 32 random-detect dscp 24 30 45 64 random-detect dscp 48 40 60 128 random-detect dscp 56 50 75 256 fair-queue fair-queue queue-limit 24 queue-limit 72 vc-class atm Sprint-ISP ubr 45000 encapsulation aal5snap interface ATM0/0/0.1 point-to-point pvc 0/106 class-vc Sprint-ISP service-policy out cbwfq2ISPonPVC >sho policy-map interface Class Random Tail Minimum Maximum Mark Output drop drop threshold threshold probability packets 0 6960177 19227320 5 10 1/8 962935241 8 245 16 15 22 1/16 47165439 16 0 0 20 30 1/32 2754705 24 0 0 30 45 1/64 18453509 48 0 0 40 60 1/128 62112 56 0 0 50 75 1/256 119861 fair-queue: per-flow queue limit 24 queue-limit 72 Art Houle e-mail: houle(a)acns.fsu.edu. Academic Computing & Network Services Voice: 850-644-2591 Florida State University FAX: 850-644-8722

1 0

RE: No one behind the wheel at WorldCom
by Frank Scalzo 15 Jul '02

15 Jul '02

See now we are back to the catch 22 that is IRR. No one will use it because the data isnt there, and no one will put the data into it because no one uses it. I think the way to get IRR into the real world production realm, is to really drive home the issue w/IPV6. -----Original Message----- From: Richard A Steenbergen [mailto:ras@e-gerbil.net] Sent: Sat 7/13/2002 10:20 PM To: Frank Scalzo Cc: Stephen Stuart; nanog(a)merit.edu; Paul Schultz Subject: Re: No one behind the wheel at WorldCom On Sat, Jul 13, 2002 at 09:21:16PM -0400, Frank Scalzo wrote: > > The underlying problem, is that there are no good widely deployed > solutions for controlling what the large backbones inject into the > routing table at peering points. A large tier 1 deaggregates towards > another bad things happen. It would be nice if there was a supportable > way to only allow one isp to advertise appropriate routes to another. > The IRR stuff is a neat idea but I dont think many ISPs trust it enough > to use it to build ACLs. If everyone maintained current IRR entries, it would work just fine. The real problem is there are still a lot of networks who's idea of filtering their customers is a prefix-limit or a filter you have to call or email in manually. The only people who actually maintain accurate IRR entries (other than the occational net kook) are those whose transit depends on it. Trying to convert an existing customer base to IRR is a nightmarish task, some of these large established providers will probably NEVER do it unless there is some actual motivation. Supposidly Level 3 requires IRR filtering on their peers, but do they actually try to enforce this? I know they do an excellent job maintaining their own IRR entries, but I'm certain they peer with people who don't have a current db. Probably not, since the vast majority of their current peers don't meet their current peering requirements. :) -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

4 3

The Adelphia update
by blitz 15 Jul '02

15 Jul '02

> >US prosecutors set to indict Adelphia family-paper >Last Updated: July 15, 2002 12:23 AM ET >WASHINGTON, July 14 (Reuters) - Federal prosecutors looking into >questionable corporate dealings at bankrupt Adelphia Communications Corp. ><http://www.reuters.com/quote.jhtml?ticker=ADELQ.PK&qtype=sym&qcat=news>ADELQ.PK >are set to bring charges against the Rigas family, USA Today reported on >Monday. > >Prosecutors have prepared an indictment against Adelphia founder John >Rigas and his three sons and are planning to file it as early as this >week, the newspaper reported, citing sources close to the investigation. > >The criminal charges were expected to be filed in tandem with a civil >lawsuit by the U.S. Securities and Exchange Commission, the newspaper >said, adding that both the Justice Department and the SEC declined comment. > >Adelphia is the target of a Securities and Exchange Commission accounting >probe and two federal grand jury investigations into multibillion-dollar >off-balance sheet loans to the Rigas family, which founded the No. 6 U.S. >cable television operator. > >Coudersport, Pennsylvania-based Adelphia filed for Chapter 11 bankruptcy >protection in June, following months of disclosures of off-balance-sheet, >company-backed loans to the family, as well as missed interest payments, >overstated earnings and criminal and regulatory probes into its accounting >practices. > >

1 0

Re: Readiness for IPV6
by Niels Bakker 14 Jul '02

14 Jul '02

> Niels Bakker wrote: >> It would also be nice if operators with end users started offering >> native multicast. Although the AMS-IX multicast initiative started >> off with lots of enthusiasm, two years later it seems to have died >> almost completely. * pete(a)he.iki.fi (Petri Helenius) [Tue 09 Jul 2002, 15:27 CEST]: > Most multicast projects go this way. The reason usually being one or more of; > A) ISP's want to charge extra for multicast > B) No content is being served over multicast > C) Firewalls do not pass multicast (usually non-issue on home users) Indeed. I'm personally most amazed that B) companies like shoutcast.com (who must be spending fortunes on bandwidth for all their streams) aren't pushing multicast more. Cheers, -- Niels.

17 27

Re: The Cidr Report - web site inaccessible ?
by Gregory Hicks 14 Jul '02

14 Jul '02

> Date: Sun, 14 Jul 2002 21:36:01 +0300 (IDT) > From: Rafi Sadowsky <rafi-nanog(a)meron.openu.ac.il> > > Is it just me ? Internet-wide. I sent a note to Philip Smith re this very item. The wesite IS down. > Date: Sun, 14 Jul 2002 08:56:34 +1000 > From: Philip Smith <pfs(a)cisco.com> > > Gregory, > > Yes, the website is down at the moment due to a failure on the server - > I'm told it will be back in the next few days... Sorry about this. > We'd no obvious way of telling everyone without spamming the whole > mailing list... > > (If it isn't back by the next report, I'll have to do that..) > > best wishes! > > philip > -- At 00:07 13/07/2002 -0700, Gregory Hicks wrote: >Um-m-m-m... I tried to get to your report... But failed with this >error for each URL (listed below) shown in the CIDR report. [...snip...] Unquote Regards, Gregory Hicks > [...snip remainder of both messages...] --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3479 San Jose, CA 95134 | Internet: ghicks(a)cadence.com Never attribute to malice that which is adequately explained by ignorance or stupidity. Asking the wrong questions is the leading cause of wrong answers "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton You can have it done good, fast, or cheap -- pick any two.

2 1

no-export problem resolved
by Stephen Stuart 14 Jul '02

14 Jul '02

The problem I had with one of my upstreams' handling of no-export has been resolved. They were, you'll be happy to hear, full of desire to do the right thing (and had apparently been doing it until the syntax for doing so changed out from under them, so clearly you can't turn your back on those router vendors) and the ticket was closed. So, yes, my assertion that no-export support was not built-in was wrong. Mea culpa. Stephen

1 1

The Cidr Report
by CIDR Report 14 Jul '02

14 Jul '02

This is an auto-generated mail on Fri Jul 12 23:00:00 PDT 2002 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 amount 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 12Jul02 0) General Status Table History ------------- Date Prefixes 050702 110820 060702 111129 070702 111069 080702 111088 090702 111212 100702 111153 110702 111369 120702 111339 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: 13208 Number of ASes announcing only one prefix: 8040 (4516 cidr, 3524 classful) Largest number of cidr routes: 615 announced by AS3908 Largest number of classful routes: 1230 announced by AS701 1) Gains by aggregating at the origin AS level --- 12Jul02 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1089 840 249 22.9% Telstra Pty Ltd AS701 1230 982 248 20.2% UUNET Technologies, Inc. AS17557 304 107 197 64.8% Pakistan Telecom AS6595 221 54 167 75.6% DoD Education Activity Network As AS852 549 407 142 25.9% Telus Advanced Communications AS7018 794 668 126 15.9% AT&T AS16473 195 77 118 60.5% Bell South AS7303 167 72 95 56.9% Telecom Argentina Stet-France Tel AS4151 235 140 95 40.4% USDA AS19632 99 5 94 94.9% Metropolis Intercom S.A. AS1239 519 425 94 18.1% Sprint AS12302 118 30 88 74.6% MobiFon S.A. AS16814 105 20 85 81.0% NSS, S.A. AS7046 315 231 84 26.7% UUNET Technologies, Inc. AS2048 181 103 78 43.1% State of Louisiana AS2149 367 294 73 19.9% Performance Systems, Inc. AS577 262 190 72 27.5% Bell Advanced Communications Inc. AS724 231 163 68 29.4% DLA Systems Automation Center AS4323 402 334 68 16.9% Time Warner Communications, Inc. AS3464 163 102 61 37.4% Alabama SuperComputer Network AS19834 64 4 60 93.8% NetForce, Inc. AS10620 84 24 60 71.4% TVCABLE BOGOTA AS1 444 386 58 13.1% GENUITY AS16758 63 6 57 90.5% IKON Office Solutions AS3908 296 240 56 18.9% Supernet, Inc. AS209 310 254 56 18.1% Qwest AS9498 83 28 55 66.3% BHARTI BT INTERNET LTD. AS9051 81 29 52 64.2% INCONET Autonomous System AS6535 65 16 49 75.4% Chilesat Servicios Empresariales AS703 271 225 46 17.0% UUNET Technologies, Inc. Total 54793 42301 12492 22.8% 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

2 1

Re: QoS/CoS in the real world?
by JC Dill 14 Jul '02

14 Jul '02

On 04:46 PM 7/13/02, Stephen J. Wilcox wrote: >I conclude either the people doing this are successful and keep their secret >safe or the world is yet to sell largescale QoS across IP. There's a world of difference between "sell" and "actually provide". IMHO, QoS is sold by many networks, but not actually provided (at the router). What IS provided is a system to give the QoS paying Customer credit if they A) notice they didn't get the quality of service their contract specified, and B) they request a credit. jc

3 2