- Test - lists.nanog.org

ASExplorer 1.0 Beta Announcement
by ipma-support＠merit.edu 01 Aug '97

01 Aug '97

The University of Michigan and Merit Network, Inc. are pleased to announce the 1.0 Beta release of ASExplorer. The new ASExplorer is the first of a series of visualization tools being developed by the Internet Performance Measurement and Analysis project (IPMA). Please see: http://www.merit.edu/ipma/asexplorer The new, light-weight ASExplorer Java client displays routing instability data received from one or more user-selected channels. We are currently providing channels for routing instability data collected at the AADS, MAE-East, MAE-West, PacBell, and PAIX exchange points. Some of the new features of ASExplorer include: * Who is AS1239? Well, just float your mouse cursor over AS1239, and we'll tell you! Dynamically updated Internic information tells you more than just an AS number -- try it and see. * Instability levels are monitored via graphs of BGP announcements and withdrawals, both updated in real-time. * Lists of currently flapping prefixes are hooked into the main ASExplorer window, and allow you to jump to an AS with a single click. * ASExplorer now lists all of the announced routes by an AS within the last time window (currently fixed at 75 minutes). * You can jump directly to an AS if you know its AS number. No more hunting through layers of HTML. * Can't figure out how the darn tool works? Use the on-line help! Also note that if you just want to look at the real-time graphs, you can view them at http://www.merit.edu/ipma/realtime/. The new version of ASExplorer relies on the Salamander Data Distribution infastructure to provide real-time updates to the client applets/application via a platform-independent webcasting technology. If you have any questions, comments, or any form of criticism, please feel free to send mail to ipma-support(a)merit.edu. P.S. If you have any problems running the ASExplorer software, please mail us the contents of your Java console and a brief description of your problem. The ASExplorer team will be more than willing to help you get the software up and running. - Jimmy vecna(a)eecs.umich.edu

1 0

Re: how to protect name servers against cache corruption
by Thomas H. Ptacek 01 Aug '97

01 Aug '97

> What, exactly, does Bind 8.1 do? BIND 8.1.1 does not appear to have an easy mechanism to match a query ID to the question-section details of an open query. Currently, BIND increments a counter, prints a debugging log line, and drops the packet; it does not invalidate the open query. > > Netcom's nameservers. They will no longer be able to resolve NETSOL.COM, > > since every query they open up will be immediately invalidated by a fake > > response. > Well, one could make observations about comparisons of IP source > addresses here... All of the attacks being discussed assume the attacker has the ability to inject completely forged packets onto the network. All of my suggestions are given under the assumption that this is a situation that we do not have a reasonable expectation of being able to prevent in IPv4. > I don't see that the problem you describe affects the people > _answering_. You'd have to nail _every_ _inquirer_. Ok, yes, hitting This is true. However, remember that this thread occurred in response to an attack by Eugene Kashpureff, who used a far more primitive attack and made national news by effectively disabling NSI's home page. I don't think the operation community wants to think about the implications of someone with both malice and BRAINS trying to utilize the same security problems. ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf(a)enteract.com] ---------------- "If you're so special, why aren't you dead?"

10 16

how to protect name servers against cache corruption
by Paul A Vixie 01 Aug '97

01 Aug '97

a BIND 4.9.6 or 8.1.1 server is immune. so, you could upgrade. to so do, see http://www.isc.org/isc/ which will lead you to ftp://ftp.isc.org/isc/. (the root name servers are all running modern software at this point.) alternic's corruption works by locating authoritative name servers via the "NS RR"'s published in various zones. if you run these as authoritative- only (recursion disabled) then they will never fetch any data from anywhere. (the root name servers are configured this way, for example.) the downside is that you can't list such nameservers in your "resolv.conf" files or PC equivilents (Control Panel\\Networking\\TCP IP Settings, or some such rot.) this means you need more name servers if you separate recursive from non- recursive.

18 49

Re: Root Nameserver problems?
by John J. Buxbaum 01 Aug '97

01 Aug '97

I have noticed some problems today aswell, but nothing significant yet. I had assumed that it was problems with our customers, since our DNS servers are up and the records are good. john AT&T CBB Maintenance DNS -----Original Message----- From: Eric D. Madison <madison(a)acsi.net> To: nanog(a)merit.edu <nanog(a)merit.edu> Subject: Root Nameserver problems? >Anyone else having problems with lookups this morning? Can't seem to >resolve a lot of domains today.. > >Eric > > >_______________________________________________________ > Eric D. Madison - Senior Network Engineer - > ACSI - Advanced Data Services - ATM/IP Backbone Group > 24 Hour NMC/NOC (800)291-7889 Email: noc(a)acsi.net > >

2 1

Root Nameserver problems?
by Eric D. Madison 01 Aug '97

01 Aug '97

Anyone else having problems with lookups this morning? Can't seem to resolve a lot of domains today.. Eric _______________________________________________________ Eric D. Madison - Senior Network Engineer - ACSI - Advanced Data Services - ATM/IP Backbone Group 24 Hour NMC/NOC (800)291-7889 Email: noc(a)acsi.net

1 0

MAE-East
by Brian Merritt 01 Aug '97

01 Aug '97

I'm sure all of you noticed that MAE-East has ate it a few times in the last hour or so. Did any of you have any luck getting an explanation as to what's going on? Connections to the gigaswitches, the shared fddi concentrators, and the ethernet switches all went down... Power? If not, what would cause such a massive disturbance? Besides an airplane crashing into it.... -Brian

3 3

RE: disabling directed broadcasts
by jan.novak＠aliatel.cz 01 Aug '97

01 Aug '97

I also have (past) experience with a network running MS/NetBIOS cruft through routers with forwarding of directed broadcasts DISABLED. It worked fine. If there is some corner case I've missed that requires forwarding of directed broadcast packets, it would be useful for that specific case to be enumerated _in detail, in public_. Ran rja(a)home.net We ran MS Windows over routed network in seven localities without any type of broadcast enabled. All what is needed for user transparent operation is to setup WINS.

1 0

Re: disabling directed broadcasts
by rja＠corp.home.net 31 Jul '97

31 Jul '97

On Jul 30 21:16, Edward Henigin wrote: } Subject: disabling forwarding of directed broadcasts % this does work as you'd expect (it prevents the cisco % from framing an IP broadcast packet into an ethernet broadcast % frame) BUT unfortunately it can break Windows networking, as well % as BOOTP/DHCP, depending on how you're set up. BOOTP/DHCP does NOT need directed broadcast forwarding enabled to work properly. The "helper-address" function and the DHCP RELAY code take care of BOOTP/DHCP traffic. Implementations of BOOTP/DHCP don't require enabling forwarding of directed broadcast packets. I've verified this experimentally in a previous life. I also have (past) experience with a network running MS/NetBIOS cruft through routers with forwarding of directed broadcasts DISABLED. It worked fine. If there is some corner case I've missed that requires forwarding of directed broadcast packets, it would be useful for that specific case to be enumerated _in detail, in public_. Ran rja(a)home.net

2 1

Re: thats stupid
by Paul G. Donner 31 Jul '97

31 Jul '97

Does this, among a million other things I've seen on this list lately, belong on this list? At 05:49 PM 7/29/97 +0000, Pam Evon wrote: >dear nasa.com,my name is glen.i like tecnology type things.i like to >go to nasa.gov to see the new pathfinder pictures.but its a bit >confusing to see the differince between nasa.com and >nasa.gov.kix.country 92.9 told people to go to nasa.gov to see the >pathfinder pictures and not to go to nasa.com because they have >pictures of women having sex and naked women.yours truly glen. > > > > > >ps. e-mail me at pevon(a)cyberstreet.com >thank you > >

1 0

[FYI] Broadcasts at NAPs
by Lyndon Levesley 31 Jul '97

31 Jul '97

This ICMP discussion reminded me that we've been logging broadcasts for a while at ME to see what percentage of traffic they represented and what it was (the wrong way round to track back thru ICMP DoS attacks). If anyone's interested, the results are : 192.41.177.255 (254376 matches) 255.255.255.255 (1694830 matches) any other dest. (1047899270 matches) which is 0.18% of the total accounted for by broadcasts. Bad, of course, but not as bad as I thought. I guess the bigger the provider the smaller percentage of total (that 1billion is total input on our FDDI since I applied the list, rather than total packets on the LAN) I'm assuming that a billion packets is enough to be a representative sample. A bit of a breakdown from the logs : Split of broadcasts is ICMP 12% UDP 88% (actually, there were 5 packets for protocol 9 (private IGP?) but that's neither here nor there) Port breakdown (based on a smaller sample to save resources) ICMP ---- I won't name names (I'll contact people later on probably) but 99.2% of the ICMP traffic comes from one provider (two routers) and is directed at 255.255.255.255. That should be fairly easy to stop. Is there any good reason for a router to ping the broadcast address of a NAP ? UDP --- PORT: 53 PACKETS: 5 PORT: 67 PACKETS: 5364 PORT: 123 PACKETS: 9950 PORT: 161 PACKETS: 12 PORT: 513 PACKETS: 6635 PORT: 520 PACKETS: 19486 PORT: 5841 PACKETS: 4344 -------------------------------- 45796 53 = DNS (badly configured cisco, but temporary so that's OK) 67 = BOOTPS (!) (probably misconfigured cisco again ;) 123 = NTP (ditto!) 161 = SNMP (?? - god knows why this would happen) 513 = who? 520 = routed ( oh dear) 5841 = ??? (is this CDP?) The upshot would seem to be that even with loads of misconfigured/ clueless stuff going on, random traffic is so insignificant that it wouldn't affect the performance of the NAP infrastructure. Cheers, Lyndon -- Penis Envy is a total Phallusy.

2 2