- NZNOG - lists.nznog.org

DNS Vulnerability
by Jamie Baddeley 08 Jul '08

08 Jul '08

Vulnerability Summary: Deficiencies in the DNS protocol and common DNS implementations facilitate a DNS cache poisoning attack that affects BIND, Microsoft Windows DNS services and CISCO IOS. The vulnerability has been assigned the following Common Vulnerability and Exposure number: CVE-2008-1447 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447 Note: Authorative name servers are not affected. Impact criticality: CCIP assess the impact of this vulnerability to be VERY HIGH. CCIP is unaware of any active exploit code for this vulnerability. Type of fix available: Microsoft has released a patch for this in their latest updates. More information can be found at http://www.microsoft.com/technet/security/bulletin/MS07-062.mspx. CCIP understands that other vendors will be releasing updates shortly. BIND have released a notification which is located at http://www.isc.org/index.pl?/sw/bind/index.php CISCO have also released a notification which can be accessed at http://www.cisco.com/warp/public/707/cisco-sa-20080708-dns.shtml

2 1

Re: [nznog] DNS Vulnerability
by Ewen McNeill 08 Jul '08

08 Jul '08

In message <1215550691.3987.44.camel(a)titan>, Jamie Baddeley writes: >Vulnerability Summary: >Deficiencies in the DNS protocol and common DNS implementations >facilitate a DNS cache poisoning attack that affects BIND, Microsoft >Windows DNS services and CISCO IOS. See also, eg, http://isc.sans.org/diary.html?storyid=4687 which has some sane discussion of the issue (which basically seems to boil down to insufficient randomness in queries allowing spoofed replies, given the lack of any actual properly deployed security in DNS). Amongst other things they suggest patching any recursive/caching DNS servers with vendor patches at the soonest suitable patch window. The priority for patching other things depends on their reliance on DNS and protection gained from other DNS servers -- for instance things which only rely on DNS to look up internal management network names from a DNS server which is already patched are probably a much lower priority than the recursive DNS servers for your customers. (And while, eg, Cisco have a patch out for IOS, I'd imagine most routers/switches are not configured to offer recursive DNS or otherwise using the DNS functionality in IOS in a way that puts them at much risk.) Also for recursive DNS servers for customers see the note at the end of the isc.sans.org page (link above) about a beta version of BIND9 with performance improvements for high query load recursive servers. Ewen

1 0

APRICOT 2009: Call for Papers
by Gaurab Raj Upadhaya 02 Jul '08

02 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) 18-27 February 2009, Manila, Philippines http://www.apricot2009.net Call for Papers The APRICOT 2009 Program Committee is now seeking contributions for Presentations and Tutorials for APRICOT 2009. Full CFP available at : http://www.apricot2009.net Please submit proposals online at http://submission.apricot.net/paper/user/login.php?event=13 CONFERENCE MILESTONES - --------------------- Call for Papers Opens: 1 July 2008 Deadline for Speaker Submissions: 30 September 2008 First Draft Program Published: 15 October 2008 Final Program Published: 15 December 2009 Final Slides Received: 15 January 2009 Additional Information ______________________ APRICOT Program will be organized in three parts, including workshops, tutorials and the conference. APNIC Policy SIG and Annual Members Meeting will be held subsequently. Topics for tutorials and conference would include amongst others relevant to Internet Operations and Technologies: Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions. APRICOT is a TECHNICAL conference so marketing and commercial content is not allowed within the program. Speakers from developing countries may be eligible for the APRICOT Fellowship Program. More information on the APRICOT Fellowship program can be found at the APRICOT 2009 website at http://www.apricot2009.net/ Thanks. APRICOT Program Committee -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhsZNIACgkQSo7fU26F3X21cgCgiTw0kXxmySOQwl4383LVHXID wPkAoKQMj28KautqgXUH5bkxqtmiUieZ =VSDe -----END PGP SIGNATURE-----

1 0

NZRR Route Registry Update
by NZRR Database Notifications 02 Jul '08

02 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Limited - AS17746 members: 60.234.0.0/16^16-29, 121.98.0.0/16^16-29, 156.62.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 116.199.208.0/21^21-29, 120.136.48.0/21^21-29, 210.54.56.0/21^21-29, 210.79.48.0/21^21-29, 202.127.8.0/22^22-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.175.142.0/23^23-29, 203.84.134.0/23^23-29, 192.203.216.0/24^24-29, 202.27.77.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.64/27^27-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: benny.treefoot(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080516 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Limited - AS17746 members: 60.234.0.0/16^16-29, 121.98.0.0/16^16-29, 156.62.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 116.193.144.0/21^21-29, 116.199.208.0/21^21-29, 120.136.48.0/21^21-29, 210.54.56.0/21^21-29, 210.79.48.0/21^21-29, 202.127.8.0/22^22-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.175.142.0/23^23-29, 203.84.134.0/23^23-29, 192.203.216.0/24^24-29, 202.27.77.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.64/27^27-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: benny.treefoot(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080703 source: NZRR ------------------------------------------------------------

1 0

Re: [nznog] Vector, did you try turning it off and then on again
by Bill Walker 02 Jul '08

02 Jul '08

Thats the best reply so far. We have just proposed triple redundancy to a customer. Fibre wireless and satellite the ongoing costs aren't too bad it's the setup costs that are a killer. 10 mbp satellite gear isn't cheap. If you've got the money it's the way to go. .... Bill Walker Sent from my phone. -----Original Message----- From: "John Russell" <jsr(a)jsr.com> To: "NZNOG" <nznog(a)list.waikato.ac.nz> Sent: 1/07/2008 11:41 p.m. Subject: Re: [nznog] Vector, did you try turning it off and then on again On [Various Times], [Many People Wrote] wrote: > [Words] A 9 hour outage seems long, but it's hardly absurd. Though we haven't seen a cause report from Vector yet, if it was spade fade, 9 hours is pretty good. I wasn't on call when it broke, but my colleague who was tells me he was told "Hardware Failure" was the problem. If something like a 6509 plane died, I can see how you might hit 9 hrs: The thing faults, alarms go off, customers call, the on-duty tech at Vector has to do some basic diagnosis, wave his hands in the air and run around like a monkey for a bit, call the on-call call engineer. Then that engineer has to wake up and/or finish his beer and get home from the pub, then do some more diagnostics, see the dead module and then do that thing where you put your hands flat on your forehead and drag them down your face while going "Gahhhhh". Then he gets to go pull a spare from stores, or call Cisco for a part and then THEY get to kick off THEIR internal process to get the thing to you. Then there's truck time to the site, waiting for an elevator to L48 of the sky tower that isn't already full of tourists in orange jumpsuits ready to jump off and/or carts full of crab canapes, swaping out the dead unit, sanity checking the restored services and making config changes if required, etc. And all that is just if everything does go to plan, and you don't find out that your spare hardware is in the lab, and the lab is locked and the guy who has the key has gone fishing, or that Cisco have already given their only spare WS-X6516 to someone else, and so on and so on. So, anyway, thing is, 9hrs, sure. However it really shouldn't matter that much. The ISP network I am currently fussing over, for example, has vector connectivity to the Sky Tower, which carries APE and some other stuff. This all broke when Vector went down. Domestic traffic, however, simply switched over to other peering links, as it should because it is, you know, The Internet. Some Vector-only stuff broke, of course, but core services just failed over and carried on. If your network connection is absolutely critical for your business, and it's wholly dependent on one vendor, you should perhaps rethink your approach. Talk to your ISP, explain that you need redundancy in your connection. Chuck in something like a DSL connection beside that Vector link. Ask your ISP about sourcing you a router than can connect to both, and setting up BGP or MPLS-based failover to your secondary link in the event that your Vector link fails. Now your connection is vendor independent (if not ISP-independent - if they fail, you fail. Try to pick an ISP that Does Not Fail Much). If you can't get DSL, ask your ISP about Wireless or IPStar or something similar. If you can fail from optical to satellite, that's pretty good diversity. And it's not complicated to do. You may not get the same performance, of course, but you'll have _a_ connection, which is better than _no_ connection, especially if it's only for a short time. This setup won't, of course, solve the problem of a local power cut killing your Vector link. I'm not even certain why we're discussing that. Talk to Vector and your electrician to get a cable run from your generator and/or UPS-backed distribution board to wherever your building vector switch is. Plug the switch into it. And you're done. It's a one-off cost, and likely not a large one. Even without a UPS, the worst that can happen is that the switch powers down when the cut takes place, then boots back up when your generator starts. A few minutes, tops. If you _don't have_ a generator, and your building power is out, I guess you'll be sitting in the dark, looking at your blank screen, and won't care if your internet connection is down. This is a perfect opportunity to go to the pub, and have a drink with the Vector engineer. Assuming he's awake. JSR -- John S Russell Big Geek. Doing Geek Stuff. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog No virus found in this incoming message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.3/1526 - Release Date: 30/06/2008 8:43 a.m.

5 5

NZRR Route Registry Update
by NZRR Database Notifications 01 Jul '08

01 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9245 descr: advertised to AS9439 by Compass Communications - AS9245 members: 203.152.96.0/19^19-29, 203.96.0.0/20^20-29, 203.96.32.0/20^20-29, 117.104.176.0/21^21-29, 123.108.144.0/21^21-29, 116.90.132.0/24^24-29, 202.36.121.0/24^24-29, 202.36.157.0/24^24-29, 202.37.112.0/24^24-29, 202.37.234.0/24^24-29, 203.30.174.0/24^24-29, 203.171.4.0/24^24-29, 203.97.62.200/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: davey.goode(a)compass.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080213 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9245 descr: advertised to AS9439 by COMPASS NZ - AS9245 members: 203.152.96.0/19^19-29, 203.96.0.0/20^20-29, 203.96.32.0/20^20-29, 117.104.176.0/21^21-29, 120.136.0.0/21^21-29, 123.108.144.0/21^21-29, 116.90.128.0/23^23-29, 116.90.132.0/23^23-29, 202.174.6.0/23^23-29, 116.90.131.0/24^24-29, 202.36.157.0/24^24-29, 202.37.112.0/24^24-29, 202.37.234.0/24^24-29, 203.30.174.0/24^24-29, 203.171.4.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: davey.goode(a)compass.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080702 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 01 Jul '08

01 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9245 descr: advertised to AS9560 by Compass Communications - AS9245 members: 203.152.96.0/19^19-29, 203.96.0.0/20^20-29, 203.96.32.0/20^20-29, 117.104.176.0/21^21-29, 123.108.144.0/21^21-29, 116.90.132.0/24^24-29, 202.36.121.0/24^24-29, 202.36.157.0/24^24-29, 202.37.112.0/24^24-29, 202.37.234.0/24^24-29, 203.30.174.0/24^24-29, 203.171.4.0/24^24-29, 203.97.62.200/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: davey.goode(a)compass.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080213 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9245 descr: advertised to AS9560 by COMPASS NZ - AS9245 members: 203.152.96.0/19^19-29, 203.96.0.0/20^20-29, 203.96.32.0/20^20-29, 117.104.176.0/21^21-29, 120.136.0.0/21^21-29, 123.108.144.0/21^21-29, 202.174.6.0/23^23-29, 202.36.157.0/24^24-29, 202.37.112.0/24^24-29, 202.37.234.0/24^24-29, 203.30.174.0/24^24-29, 203.171.4.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: davey.goode(a)compass.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080702 source: NZRR ------------------------------------------------------------

1 0

Re: [nznog] Vector, did you try turning it off and then on again
by Matthew Poole 30 Jun '08

30 Jun '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Richard Naylor wrote: | OK MAN CPEs are tricky. A cheap UPS is useless. The line interactive | type do let thru spikes and surges and if your CPE device has a cheap | switching PSU it will often lock up, die, or do nasty things. So to get | a decent UPS (ie rectifier followed by inverter) you need to spend over | $1k. | And given that Vector were using, at the time, Cisco 29xxG's (I think. Pretty sure they were just dumb L2 switches) for CPE, a $1k UPS would almost double the equipment cost per install. That's not inconsiderable. | Then you have batteries and maintenance. A typical power company (I used Which was really my point. Keeping a lot (and it'll number in the hundreds for Vector) of UPS's up and running isn't a trivial ask. The cost would be phenomenal, and every time batteries need to be changed it's an outage for the CPE that's on the end of it. *SNIP* | If you want to help your MAN supplier deliver a better performance and | you run a nice UPS, then offer to give them some of your 230V off your | UPS. Then you know that they have power at your end. And if you have a | diesel as well....... | | Its a nice cheap solution, and you know the performance of their backup. | Yeah, I think that was kind of what Vector were hoping for. But a lot of their terminating switches are buried in basement rooms to which only the building manager has a key. I know that we had quite a few instances of banging heads on walls trying to get access to put our kit in with Vector's, because the keys to the appropriate room were hard to locate. - -- Matthew Poole "Don't use force. Get a bigger hammer." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIaWaWTdEtTmUCdpwRAvxSAKDIVU4tPqlHaZxpDSbZkk5s6XfwXgCeP99z rgL579ASX+9AcBjhAlgC56g= =sQy1 -----END PGP SIGNATURE-----

17 21

Re: [nznog] Vector, did you try turning it off and then on again
by Richard Naylor 30 Jun '08

30 Jun '08

At 01:15 p.m. 30/06/2008, Pshem Kowalczyk wrote: <snip> >Updates 4h into the problem saying - no ETA and about 2h later - it >will be fixed tomorrow are just not enough. The fact that it was >virtually impossible to get hold of anyone that actually had a clue is >not something that an average business is willing to accept. If a network connection is that important to the "average" business, then it should do something about it. What worries me is that people on this list think that a network operator should be infallible. If the Internet is that important to your business, then have more than one provider. If you have clue, you'll use one with a different layer 3, 2, 1, or maybe even 0 route topology. Its far simpler to have multiple providers and networks than paying a fortune to have some undeliverable level of reliability. And besides *you* have control over it. My business relies heavily on the Internet. We use 5 providers for our network and around 5 for the services. We mix dsl with wireless (3 forms), we have 4 satellite links, fiber and are known to run our own cable when we can't get what we want where we want it. A Km or two is no real issue. If a company uses a UPS for its computer, why doesn't it invest in a second link. Even crappy dsl will at least keep something going. Rich

5 7

Upcoming APNIC policy implementations
by Elly Tawhai 30 Jun '08

30 Jun '08

________________________________________________________________________ Upcoming APNIC policy implementations ________________________________________________________________________ On 4 August 2008, APNIC will implement two policy proposals that reached consensus at the APNIC 25 Policy SIG in Taipei, Taiwan in February 2008. The APNIC Executive Council (EC) endorsed the proposals during their May 2008 meeting. The two policy changes are: - Changing the minimum IPv4 allocation size to /22 This change will make it easier for small ISPs to receive direct allocations from APNIC. - Adding an alternative IPv6 initial allocation criteria This change will make it easier for more ISPs to receive IPv6 allocations from APNIC by enabling current LIRs with IPv4 allocations to receive IPv6 initial allocations without a plan for making 200 assignments. To view the history of these policy proposals, see: prop-053: Changing minimum IPv4 allocation size to /22 http://www.apnic.net/policy/proposals/prop-053-v003.html prop-057: Proposal to change IPv6 initial allocation criteria http://www.apnic.net/policy/proposals/prop-057-v002.html Kind regards, Elly ________________________________________________________________________ Elly Tawhai email: hostmaster(a)apnic.net Senior Internet Resource Analyst, APNIC sip: hostmaster(a)voip.apnic.net http://www.apnic.net/helpdesk phone: +61 7 3858 3188 fax: +61 7 3858 3199 ________________________________________________________________________ Hope to see you at APNIC 26 in Christchurch, New Zealand 25 - 29 August 2008 http://www.apnic.net/meetings/26/

1 0