July 2001 - Test - lists.nanog.org

DoS tracking paper
by Paul Blasquez 18 Jul '01

18 Jul '01

Hello, About 3 weeks back a gentleman posted a link to a paper on tracking DoS attacks quickly, the details involved tagging the traffic with community 666. I have since had a Win98 (Please flame me for running Win98) crash, and lost my bookmark to that page. Could someone please: a) Re-post the link b) Tell me if and where there is a database of nanog posts so I may search them. Thank you in advance. -Paul _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 2

Apparent widespread Worldcom ATM failure
by George William Herbert 18 Jul '01

18 Jul '01

My home/consulting business ISP and my current work ISP's connectivity have been bit by what appears on first examination to be a Worldcom ATM failure starting about 2 hours ago (12:45 PST or so). It appears to be affecting stuff as widely spread as both west and east coast and connecting circuits. As I am not a direct customer I have no standing to ask them directly what went bang, so take this diagnosis with a grain of salt. -george william herbert gherbert(a)retro.com

1 0

Re: PPPOE, MTU, and boom.
by Alex Rubenstein 18 Jul '01

18 Jul '01

On Wed, 18 Jul 2001, Chris Wedgwood wrote: > On Wed, Jul 18, 2001 at 07:57:23AM +0100, Stephen J. Wilcox wrote: > > Could it be Path MTU/fragmentation issues on account of the low > MTU you have in combination with some ICMP issues where network > admins have some screwy setup? > > That's exactly what it is... a large (1500 byte probably) TCP datagram > with the DF bit set will be heading towards his edge device which are > PPPoE connected. Great domain, btw (f00f.org, brings back memories of division)... Anyway, a great stride was just made in my lab^H^H^Hbasement. First off, it appears a 'ip mtu 1492' on the Virtual-Template of the IOS Router aggregating the PPPOE session is not strictly enforced, especially with windows. Another words, I saw in the PPP debug that the MRU wasn't being negotiated. So, I found this really nifty utility, aptly named 'Mr. TCP': http://www.dslreports.com/front/drtcp.html It allows you to tinker with the Windows settings of TCP. I adjusted MTU to 1400, wham-o, all the sites I listed started working; including, what I didn't list before, the downloading of transactions via Quicken. Seems to be a fixall. -- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --

7 8

Correction: 209.177-222 Reverse DNS
by Larry Rosenman 18 Jul '01

18 Jul '01

CORRECTED SUBJECT... I just got off the phone with ARIN after discovering some incorrectly delegated in-addr.arpa zones. We (Internet America) have 209.196.64.0/18 and all of a sudden reverses weren't working. ARIN mistyped a transfer yesterday and got the 2nd Octet wrong. Verado, Inc (NET-VERADO-DC26) VERADO-DC26 209.177.128.0 - 209.222.143.255 Verado, Inc (NET-VERADO-DC27) VERADO-DC27 209.177.160.0 - 209.222.191.255 Internet America, Inc. (NET-IA-CR-2) IA-CR-2 209.196.64.0 - 209.196.127.255 They have corrected the database, and the next zone load should fix it. I thought others in the NANOG community might want to know. Larry Rosenman Sr. Network Engineer Internet America, Inc. 350 N. St. Paul, Suite 3000 Dallas, TX 75201 214-861-2571

1 0

209.196.177-222 reverse DNS
by Larry Rosenman 18 Jul '01

18 Jul '01

I just got off the phone with ARIN after discovering some incorrectly delegated in-addr.arpa zones. We (Internet America) have 209.196.64.0/18 and all of a sudden reverses weren't working. ARIN mistyped a transfer yesterday and got the 2nd Octet wrong. Verado, Inc (NET-VERADO-DC26) VERADO-DC26 209.177.128.0 - 209.222.143.255 Verado, Inc (NET-VERADO-DC27) VERADO-DC27 209.177.160.0 - 209.222.191.255 Internet America, Inc. (NET-IA-CR-2) IA-CR-2 209.196.64.0 - 209.196.127.255 They have corrected the database, and the next zone load should fix it. I thought others in the NANOG community might want to know. Larry Rosenman Sr. Network Engineer Internet America, Inc. 350 N. St. Paul, Suite 3000 Dallas, TX 75201 214-861-2571

1 0

Re: PPPOE, MTU, and boom.
by Scott Silzer 18 Jul '01

18 Jul '01

I have found 4 ways to get around the problem: 1) A somewhat effective fix is to have your users use a cache/proxy server. 2) Have your users lock there MTU to 1492 not 1500. 3) Some CPE routers will force 1492 MTU sessions. 4) Try to explain that ICMP is not just pings rate limit it don't drop it. Cisco's writeup on the problem: http://www.cisco.com/warp/public/794/router_mtu.html At 7:53 +0100 7/18/01, Simon Lockhart wrote: > >I have confirmed that when I block all ICMP to/from a website, we cannot >>browse that site -- which is somewhat obivious. The question is, how, as >>an internet community as a whole, do we fix this? >> >>Seems to me that most people using PPPOE would have a problem here. Or, am >>I alone? >> >>My testing has been limited to Win2k, but I've heard similar reports on >>WinME, 98, etc. > >We've come across this too, and spent quite a while diagnosing. The >problem exists wherever there's an MTU reduction, and is caused by a >combination of ICMP filtering (breaks PMTUD), and Microsoft's attempt at >PMTUD (they just set the DF bit on all packets and expect to get an ICMP >reply back if the packet is too large). > >Simon >-- >Simon Lockhart | Tel: +44 (0)1737 839676 >Internet Engineering Manager | Fax: +44 (0)1737 839516 >BBC Internet Services | Email: Simon.Lockhart(a)bbc.co.uk >Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/ -- Scott A Silzer

1 0

PPPOE, MTU, and boom.
by Alex Rubenstein 18 Jul '01

18 Jul '01

(this is not intending to be a PPPOE holy war, so, please read on). Over the last few days, I've be pfutzing with getting PPPOE working (it's really our only choice, as Verizon only offers a 1483 service). We're using Cisco 7200's and 4700's to aggregate them on our side, from DS3 and OC3 ATM circuits. We're using VPDN in 12.1T, with PPPOE. The PPP and AAA and all that seem to work fine, however, we're having a browsing issue. I've checked every setting I can think of, including MTU (which is obvious and set to 1492), IP Header Compression (which when turned off fixed 99% of the problems), but there is still a few websites that we cannot get to, no matter what. I have confirmed that when I block all ICMP to/from a website, we cannot browse that site -- which is somewhat obivious. The question is, how, as an internet community as a whole, do we fix this? Some significant sites are like this -- the bill-checking portion of www.americanexpress.com, www.intuit.com, www.visa.com, some portions of www.chase.com, etc. Seems to me that most people using PPPOE would have a problem here. Or, am I alone? My testing has been limited to Win2k, but I've heard similar reports on WinME, 98, etc. -- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --

3 2

Utilization of the redundant ring in SONET
by srihari varada 17 Jul '01

17 Jul '01

Hello: I would like to know how typical it is to have the redundant ring in SONET used for the transport of data while still providing protection switching features. Also, could any one give me insight into a few vendors that does it. I would appreciate, if some one could provide input on the above. Regards, Srihari Varada

3 2

When will 128M not be enough?
by Christopher A. Woodfield 17 Jul '01

17 Jul '01

Is there any research out there that tries to estimate how long it will be before BGP routers with 128M of RAM start to choke on the routing table? I know there are a lot of factors - the number of BGP peers, how much "other stuff" the router is doing, etc. - I'm really looking for a ballpark estimate, if one exists. I'm trying to convince someone NOT to use a Cisco 2650 for BGP multihoming, and my argument will, IMO, be a bit more effective if I can say "you'll need to replace it within X months/years"... -C --------------------------- Christopher A. Woodfield rekoil(a)semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B

14 20

FW: BigRed.com - cache poisoning for com/net/org domains (SOLVED)
by Mike Batchelor 17 Jul '01

17 Jul '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have determined how my Windows 2000 DNS cache got poisoned, resulting in non-existent domains resolving instead to the bigred.com website. There are two registered hosts, NS1.REFRACT.COM (66.34.52.240) and NS2.REFRACT.COM (66.34.52.241) that are authoritative for some 543 domains under the generic TLDs. The list of domains is in the attached text file, for those who are interested (thanks to Joseph McDonald <joe(a)vpop.net> for grepping his copies of the gTLD zone files at my request). The addresses given are the ones in the glue from the gTLD servers. REFRACT.COM is registered through OpenSRS with NS[1-4].MYDOMAIN.COM as nameservers. Mydomain.com's servers give different addresses for NS[12].REFRACT.COM, 65.194.192.211 and 65.194.192.212, respectively. In practice, modern DNS software ignores the glue from the delegated-to nameservers, preferring to cache the glue from the parents, in this case, the gTLD servers. But even so, nameservers are in fact running on the addresses given in the REFRACT.COM zone by the Mydomain.com servers, and they behave the same way as described here. A DNS cache, following delegations from the roots, and the gTLD servers, for one of these domains, will encounter bogus glue in the responses to _iterative_ queries made to one of these poison servers. The bogus glue assigns false address records to [a-m].gtld-servers.net, assigning 66.34.52.224 to all of them. Depending on the state of the already-cached records for the gTLD server addresses, a naive DNS cache, such as Windows 2000 DNS server in its default setup, or very old BIND servers prior to ~4.9.1, may become poisoned by caching this bogus data. When that happens, future queries for gTLD domains will be directed to the server at 66.34.52.224. This bogus gTLD server at 66.34.52.224 is the one that responds to any _iterative_ query with the IP address of the bigred.com search engine website. It's rather simple to get a client of a vulnerable cache to make a query for one of the domains registered with the REFRACT.COM nameservers. HTML spam will do the trick. I emphasize _iterative_ query, because all these servers - all four NS[12].REFRACT.COM servers and 66.34.52.224 - are lame for any domain when given a recursive query. They simply give a referral back to the roots, with correct glue. A poor schmuck (like me) who is trying to track down the source of his Win2K cache poison, would encounter the bogus gTLD glue in his cache's answers, and would naturally query the server at the bogus address to see what is going on. But the common query tools perform recursive queries unless told otherwise. Caches use iterative queries to resolve domains for their clients. That these poison servers respond with bogus glue only to iterative queries is slightly clever, and provides a little cover while DNS caches continue to be poisoned. It confused me for a while in any case! I couldn't have done it better myself, even if I were Eugene Kashpureff. For Windows 2000 DNS, the solution is to click on the "Advanced" tab on the Properties screen of the DNS server control panel, and check the box labelled "Secure cache against pollution". Duh. Why this is not on by default ... ah why bother: it's Microsoft, just be glad it's there, for gods' sakes. Once your Win2K cache is a little less naive, you can flush the cache in the same control panel, and your DNS resolution should return to normal. No more bigred.com when you'd expect a "Cannot find server or DNS Error" page, no more replies to ping from hosts that don't exist, etc. Older BIND software simply must be replaced with a modern version that has some kind of poison protection. D. J. Bernstein's dnscache was never vulnerable, since it always tosses out-of-zone glue. I hope this proves useful to someone. I searched all over many search engines, and found a handful of references to the problem in various (sometimes funny) contexts, but no solution or explanation. Hopefully this message will be archived and easily found on Google, and the next poor schmuck that tries to solve this problem will find this post and save himself a few days' hair-pulling. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQA/AwUBO1TfGUksS4VV8BvHEQIJXQCgoGXUsOBZ+PjgPbbwdMe39Pj/3hMAoK8p NJB5lesgwY1HyBnl4PUsuvYK =geCR -----END PGP SIGNATURE-----

1 0