February 2003 - Test - lists.nanog.org

Web Caches..
by Mark Segal 25 Feb '03

25 Feb '03

I'm wondering if anybody has had RECENT experience with web caches. If so, what is your favourites? why? Two stipulations: 1) I want one that doesn't require a department to maintain a list of uncachable objects. 2) It must support wccp. Off list replies are welcomed. Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570

1 0

IP Management tool for service providers
by Daniel Abbey 25 Feb '03

25 Feb '03

I am looking for an IP management which has flexible management capabilities. I need it for managing my customers IP assignments, and keeping stock of my IP pool. Do you have any suggestions?

6 5

Symantec detected Slammer worm "hours" before
by Sean Donelan 25 Feb '03

25 Feb '03

Wow, Symantec is making an amazing claim. They were able to detect the slammer worm "hours" before. Did anyone receive early alerts from Symantec about the SQL slammer worm hours earlier? Academics have estimated the worm spread world-wide, and reached its maximum scanning rate in less than 10 minutes. I assume Symantec has some data to back up their claim. http://enterprisesecurity.symantec.com/content.cfm?articleid=1985&EID=0 "For example, the DeepSight Threat Management System discovered the Slammer worm hours before it began rapidly propagating. Symantec's DeepSight Threat Management System then delivered timely alerts and procedures, enabling administrators to protect against the attack before their environment was compromised."

17 20

Cogent
by David Reale 24 Feb '03

24 Feb '03

Has any one else noticed Cogent's loss of UUnet routes. It appears that they may have lost UUnet early Friday. David

2 1

RE: Homeland Security Alert System
by St. Clair, James 24 Feb '03

24 Feb '03

..Once again, reason to pursue getting involved with the Telecomm ISAC. Jim -----Original Message----- From: Sean Donelan [mailto:sean@donelan.com] Sent: Saturday, February 22, 2003 6:47 PM To: nanog(a)merit.edu Subject: Re: Homeland Security Alert System I'm certain the government folks working to protect us 24x7 are doing everything they can, but the fact of the matter is the public alert systems in the US suck. Some just suck less. http://www.nj.com/news/gloucester/index.ssf?/base/news-0/104590500555170.xml "Butts said he often finds out about things like the change in the national threat level on CNN hours before the Communications Center receives a teletype about it." Butts is the Gloucester County Emergency Response Coordinator including the county 9-1-1 communications center. ISPs and other communication providers should be prepared to share information directly and quickly with each other. If you wait to hear from government officials to decide what sanitized information to share, it will be hours later. If ever.

2 1

scripts to map IP to AS?
by William Allen Simpson 24 Feb '03

24 Feb '03

Anybody have a pointer to scripts to map IP to AS? There are still 10K-20K hosts spewing M$SQL slammer/sapphire packets, and I'd like to start blocking routing to those irresponsible AS's that haven't blocked their miscreant customers. http://isc.sans.org/port_details.html?port=1434 -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

21 32

Re: 223.255.255.0/24 (fwd)
by Sean Donelan 24 Feb '03

24 Feb '03

RFC3330 issued in September 2002 does indicate that this address block is subject to future allocations. But I think people were expecting something from the IAB/IETF before IANA actually allocated previous special use reserved address blocks. My understanding was RFC3330 was written by IANA and published by IANA to document existing practices, not to change previous practices. Eventually we'll use it. The simpliest solution is for IANA to inform APNIC that it was an oversight. The 223.255.255.0/24 network block within the 223/8 CIDR block assigned to APNIC is still IANA-RESERVED per RFC3330 and previous practice; and not allocated for APNIC's use at this time. Its probably easier for APNIC to flag the 223.255.255.0/24 network within the CIDR block 223/8 as IANA-RESERVED in the APNIC database just like ARIN does with the other IANA-RESERVED blocks in ARIN's database; rather than do the ugly CIDR block breaking of 223.0.0.0-223.255.254.255 and 223.255.255.0-223-255.255.255. But that is a decision for APNIC. On Mon, 24 Feb 2003, Geoff Huston wrote: > My interpretation of this is that the IETF, by publishing an RFC with an > "IANA Considerations" section can nominate that an address block > declared allocatable under certain criteria, or they can "reserve" the prefix. > > "reserving" in my mind constrains IANA from undertaking any activity > on this block, and this is the state until the IETF elects to produce > a successor document with an IANA Considerations section that nominates > some other status to the block. > > "Reserved" blocks in my opinion cannot be passed to RIRs, or anyone > else - the IANA cannot do anything with the block other than register its > reserved status, and this can only be undone by an action of the IETF. > > Hence, my reading of the IANA registry: > http://www.iana.org/assignments/ipv4-address-space > is that this is a flawed implementation of the instructions in RFC 3330, > and that > the 233.255.255.0/24 should be listed IDENTICALLY to 128.0.0.0/16 > > i.e. its status is actually: > 223.255.255/25 IANA - Reserved - RFC 3330 > > if the IANA is to consistently act upon RFC 3330 (as indeed it should) > > Perhaps the IETF folk on this message should review the RFC and the IANA > registry and see if they agree with this interpretation, and make their > conclusion > as to the accuracy of the registry as it is currently published: > > ("223/8 Feb 03 APNIC (whois.apnic.net)") > > My view is that this block as properly "Reserved", and that the "subject to > allocation" > is an addendum that indicates a forward intention of the IETF, but not a > capability > for any IANA action. > > As my only humble suggestion, perhaps the best thing right now is for the > APNIC folk > to refrain from any assignment actions regarding this prefix until the IETF > folk and the > IANA sort out this inconsistency in the interpretation of RFC 3330. > > Geoff > > > > >Date: Mon, 24 Feb 2003 00:32:47 -0500 (EST) > >From: Sean Donelan <> > >To: > >Cc: > >Subject: Re: 223.255.255.0/24 > > > >On Sun, 23 Feb 2003 bmanning(a)karoshi.com wrote: > > > why would an APNIC/AP region specific issue need to be discussed > > > on the NANOG list and not the RIPE/AFNOG/et.al. regional ops lists? > > > This is a prefix delegated to the APregion and so they should be > > > the ones who set the policies for the prefixes they are responsible > > > for. I appreciate their willingness to share the outcome of their > > > deliberations, but why NAites have any special say in AP policies > > > is a bit beyond me. > > > >The question is really whether IANA properly implemented the relevant > >RFC's by delagating a block containing a reserved special use address to a > >registry without maintaining the previous reservations on those addresses. > > > >Its not up to APNIC how to handle the reserved special use addresses, just > >like the other special use addresses in ARIN's space are really outside > >of ARIN's scope. ARIN can't re-assign special use addresses in "its" > >space for other purposes. Nor should APNIC or RIPE or LANIC or any other > >registry which is assigned a /8 block containing special use addresses. > > > >Its not APNIC bashing. If the ARIN board got to gether and decided to > >assign 128.0.0.0/16 I think folks would be raising questions about ARIN. > > > >IANA should have properly excluded the IANA reserved special use block > >from the delegation to APNIC, just like the other reserved special use > >blocks are reserved from ARIN's use. > > > >

1 0

ot/wan simulation devices
by Tomas Daniska 24 Feb '03

24 Feb '03

hello, is anyone willing to share their experience with adtran atlas 550 simulation boxes? please reply off-list, i'll summarise thanks -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first.

1 0

Re: untied (fwd)
by Christopher L. Morrow 24 Feb '03

24 Feb '03

fwd per request... (I'm not sure how to contact united, though I'd guess PNAP/InterNap might know, since I see the fictional www.united.com through there) ---------- Forwarded message ---------- Date: Mon, 24 Feb 2003 14:36:00 +0900 From: Randy Bush <randy(a)psg.com> To: Christopher L. Morrow <chris(a)UU.NET> Subject: Re: untied bingo!! so, please post to nanog and if you know how to get to untied, ... > So, looks like: > > dig www.united.com > > returns: > > dig www.united.com > > ; <<>> DiG 8.1 <<>> www.united.com > ;; res options: init recurs defnam dnsrch > ;; got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > ;; QUERY SECTION: > ;; www.united.com, type = A, class = IN > > ;; ANSWER SECTION: > www.united.com. 5S IN A 64.95.89.8 > > ;; Total query time: 32 msec > ;; FROM: sharpie.argfrp.us.uu.net to SERVER: default -- 153.39.56.91 > ;; WHEN: Mon Feb 24 05:22:35 2003 > ;; MSG SIZE sent: 32 rcvd: 48 > > then: > > dig www.united.com > > ; <<>> DiG 8.1 <<>> www.united.com > ;; res options: init recurs defnam dnsrch > ;; got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 13 > ;; QUERY SECTION: > ;; www.united.com, type = A, class = IN > > ;; ANSWER SECTION: > www.united.com. 4S IN A 64.95.89.8 > > ;; AUTHORITY SECTION: > COM. 1d20h32m39s IN NS A.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS G.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS H.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS C.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS I.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS B.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS D.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS L.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS F.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS J.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS K.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS E.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS M.GTLD-SERVERS.NET. > > ;; ADDITIONAL SECTION: > A.GTLD-SERVERS.NET. 4d20h43m26s IN A 192.5.6.30 > G.GTLD-SERVERS.NET. 21h40m30s IN A 192.42.93.30 > H.GTLD-SERVERS.NET. 21h40m30s IN A 192.54.112.30 > C.GTLD-SERVERS.NET. 21h40m30s IN A 192.26.92.30 > I.GTLD-SERVERS.NET. 21h40m30s IN A 192.43.172.30 > B.GTLD-SERVERS.NET. 21h11m25s IN A 192.33.14.30 > D.GTLD-SERVERS.NET. 21h31m38s IN A 192.31.80.30 > L.GTLD-SERVERS.NET. 5h52m10s IN A 192.41.162.30 > F.GTLD-SERVERS.NET. 21h40m30s IN A 192.35.51.30 > J.GTLD-SERVERS.NET. 7h42m59s IN A 192.48.79.30 > K.GTLD-SERVERS.NET. 7h43m IN A 192.52.178.30 > E.GTLD-SERVERS.NET. 10h26m34s IN A 192.12.94.30 > M.GTLD-SERVERS.NET. 23h34m11s IN A 192.55.83.30 > > ;; Total query time: 10 msec > ;; FROM: sharpie.argfrp.us.uu.net to SERVER: default -- 153.39.56.91 > ;; WHEN: Mon Feb 24 05:22:36 2003 > ;; MSG SIZE sent: 32 rcvd: 483 > > > and that repeats over and over and over... HOWEVER, > > dig NS united.com > > ; <<>> DiG 8.1 <<>> NS united.com > ;; res options: init recurs defnam dnsrch > ;; got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 > ;; QUERY SECTION: > ;; united.com, type = NS, class = IN > > ;; ANSWER SECTION: > united.com. 23h59m52s IN NS dns01.uls-prod.com. > united.com. 23h59m52s IN NS dns02.uls-prod.com. > > ;; ADDITIONAL SECTION: > dns01.uls-prod.com. 1d11h2m40s IN A 64.95.89.200 > dns02.uls-prod.com. 1d11h2m40s IN A 64.95.88.200 > > ;; Total query time: 1 msec > ;; FROM: sharpie.argfrp.us.uu.net to SERVER: default -- 153.39.56.91 > ;; WHEN: Mon Feb 24 05:22:51 2003 > ;; MSG SIZE sent: 28 rcvd: 112 > > and then querying from one of them direct gets: > > timeouts for: 64.95.89.200 and 64.95.88.200 > > So, their DNS is busted it seems :( bummer for them. (or was this not what > you were seeing?) > > > > --Chris > (chris(a)uu.net) > ####################################################### > ## UUNET Technologies, Inc. ## > ## Manager ## > ## Customer Router Security Engineering Team ## > ## (W)703-886-3823 (C)703-338-7319 ## > ####################################################### > > On Mon, 24 Feb 2003, Randy Bush wrote: > > > > > could someone else please check the dns for www.united.com? the servers > > for united.com seem to delegate www.united.com, but the delegatee seems > > not to return an soa. i get very confusing results. > > > > randy, feeling stoopid > > >

1 0

Re: untied
by Randy Bush 24 Feb '03

24 Feb '03

> btw, when querying bind9 and requesting > 'any www.united.com', i get servfail, but when requesting > 'A www.united.com', i do get a response. that is the reaction to their misconfiguration. i am in a dual-stack universe over here (iij/tokyo). so the browser, looking for an A or AAAA, probably issues a query for ANY. united's dns is sorely broken. anyone know how to get their attention. i can't email to postmaster@... for the same reason. randy

1 0