July 2002 - Test - lists.nanog.org

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

15 Jul '02

The problem with doing that is you do not get fine grained control. You can only say only send me 50k routes, and things not from other peers. The really nifty part about prefix-limiting your peers is when they deaggregate toward you, you drop all your bgp sessions to them at once, completely depeering. You still cannot prevent announcement of weird routes like 63/8. Do not be fooled into believing that just because a network is big they know what they are doing. Some of the 63/8 announcements I have seen came by way of sprint. Let's step back and think about this on a security front, anyone with access to a tier 1 ISPs router can dos anyone in the internet, just by throwing in a null route for the block that is more specific then the one they have advertised. Granted not easily done, but just the same I like to be the only one who can break my network. Unfortunately Majdi is correct, we do not have sufficient functionality in today's routing software to fix the problem. Oh well I guess it has worked for this long. -----Original Message----- From: Stephen J. Wilcox [mailto:steve@opaltelecom.co.uk] Sent: Monday, July 15, 2002 8:39 AM To: Majdi S. Abbas Cc: Frank Scalzo; nanog(a)merit.edu Subject: Re: No one behind the wheel at WorldCom There are different types of filter tho and I'd suggest they are suitable in different circumstances. eg small peer < 100 prefixes - build prefix filter list, as path list middle peer - either depending on requirement (eg cust, peer) large peer > 1000 prefixes - as path filter plus max prefix I'm not implementing the above so the numbers and suggestions are a little arbitrary but I'm making the point that you can filter smaller peers who are less experienced and more likely to give an error and for larger peers you have to be less granular but can still impose failsafes without increasing CPU. Steve On Mon, 15 Jul 2002, Majdi S. Abbas wrote: > > On Mon, Jul 15, 2002 at 01:58:44AM -0400, Frank Scalzo wrote: > > 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. > > [CC: list trimmed] > > Actually, I think you'll find that bad data is only a small part > of the problem; even with good data, there isn't enough support from > various router vendors to make it worthwhile; it's effectively impossible > to prefix filter a large peer due to router software restrictions. We > need support for very large (256k+ to be safe) prefix filters, and the > routing process performance to actually handle a prefix list this large, > and not just one list, but many. > > IRR support for automagically building these prefix lists would > be a real plus too. Building and then pushing out filters on another > machine can be quite time consuming, especially for a large network. > > > I think the way to get IRR into the real world production realm, is > > to really drive home the issue w/IPV6. > > This still doesn't solve the scaling issue. This is no different > than running your own RR, which many ISPs already do -- and they still > have to exempt many of their peers. Typically, RR derived prefix filtering > is something reserved for only their transit customers. > > If it were that easy, everyone (well, some people) would be > doing it. > > --msa >

2 1

ATT
by Bryan Heitman 15 Jul '02

15 Jul '02

Anyone seeing any problems with ATT in LAX? I have ATT colo in Mesa, AZ with some routing problems... Best regards, Bryan Heitman Interland, Inc.

2 2

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: > Your facts are correct, but you're missing one so your conclusion is wrong. > > You need to verify the signature in order to be able to rely on it. > However, if one usually does not consistently sign their messages, then it > becomes entirely plausible that a spoofed message lacks a signature not > because the forger does not have the capability to generate the signature, > but simply because the sender simply neglected to attach a signature (yet > again). In this case, unsigned data is accorded roughly the same level of > authenticity as signed data. Yes, but once again you must consider content, given that most mail clients don't automatically verify signatures. Most of us will have to make a judgement call as to whether or not to bother to check the signature. The higher the degree of "importance" of the content, the more likely I am to check the signature, and the more likely I am to take verification steps if not signed. If the content is not "important", I won't bother checking the signature. Lest anybody confuse my argument, I think PGP signatures are a good thing. I just don't think people need to sign everything they send. And I'm talking about posts to Nanog here, not private communication. In private communication, it's reasonable to sign most everything sent with official business purpose. If the majority of mail clients automatically verified pgp signatures, I would be totally in favor of signing every single email. But the simple fact is that not only do most mail clients not support that, many mail clients can't even display the signed text inline! Surely a compromise is needed for now. Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access

6 5

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