- NZNOG - lists.nznog.org

NZRR Route Registry Update
by NZRR Database Notifications 20 Aug '08

20 Aug '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 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 REPLACED BY: 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, 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.6.116.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 20080821 source: NZRR ------------------------------------------------------------

1 0

History of the Internet in New Zealand
by Roger Williams 19 Aug '08

19 Aug '08

In July last year InternetNZ advised this list: >InternetNZ has commissioned Keith Newman to write a >history of the Internet in New Zealand. The book will >go to the publishers later this year. I happened to wonder what had happened with this. Finding my way to http://www.internetnz.net.nz/projects/history/ I read ... "5pm, 21 August - Book launch at the National Library" That's tomorrow evening. -- Roger Williams, GNS Science, New Zealand : www.gns.cri.nz : xyzzy

1 0

uTorrent, IPv6
by Nathan Ward 18 Aug '08

18 Aug '08

(Also posted to NANOG. Apologies if you're sensitive about that sort of thing.) Sit up and pay attention, even if you don't now run IPv6, or even if you don't ever intend to run IPv6. Your off-net bandwidth is going to increase, unless you put some relays in. As a friend of mine just said to me: "Welcome to your v6-enabled transit network, whether you like it or not ;-)". uTorrent 1.8 is out, as of Aug 9. uTorrent actively enables IPv6 on XP SP2 and Vista machines in the install process (by default, it can be turned off). IPv6 is turned on, on lots of PCs. uTorrent does DHT, so that uTorrent users will talk to eachother to exchange peers - IPv6 does not require tracker support. uTorrent (as far as I understand) knows how to set IPV6_PROTECTION_LEVEL appropriately on sockets, so that Teredo is actually used. What does this mean? It means that many uTorrent end users will have Teredo addresses, and many will have 6to4 addresses. As we roll out IPv6 globally, more and more uTorrent users will have non-tunnelled IPv6 addresses. uTorrent users move **LOTS** of data. This means relay load. There are very few 6to4 relays around the world. There are fewer Teredo relays. If you run a network today and do not have 6to4 and Teredo relays, traffic between a 6to4 end user and a Teredo end user will go off-net. That costs you money. So, if you run a network today, deploy 6to4 and Teredo relays, regardless of whether you have customer facing IPv6 or not. If you serve IPv6 content, you are already running Teredo and 6to4 relays, so that Windows Vista users get near to IPv4-speed access to your IPv6 content, right? Right... Azureus does IPv6 now, but does not turn on IPv6, and does not set the IPV6_PROTECTION_LEVEL (as far as I understand), so Teredo is not used. Windows uses 6to4 if you have a non-RFC1918 address, and it uses Teredo if you do not (typically, this means you are behind NAT). With the huge amount of end users behind NAT, this means that uTorrent will have a much wider effect than Azureus has had. Running a relay *does not* mean that people outside your network can use it. - Who uses your 6to4 relay is controlled by how far you advertise the well known IPv4 and IPv6 prefixes. - Your Teredo relay is used only by Teredo clients trying to get to your non-Teredo connected users (ie your 6to4 or natively connected users). 6to4 relays can be Cisco boxes, Juniper NetScreen, FreeBSD, Linux, etc. OpenBSD does not have 6to4 support. Teredo relays can be Windows boxes, or Linux/FreeBSD/etc. boxes running `Miredo'. I have pre-built FreeBSD images that run both 6to4 and Teredo relays, and can talk BGP to your network. They are about 30MB, so will run on a compact flash card, and will happily run on anything from a 133Mhz 468 (ie. Soekris net4501) through to whatever top of the line server you have. They can also optionally do this "Tui" thing, which uses 6to4 and BGP to build direct IPv6 over IPv4 tunnels to everyone else with one of these boxes, without you having to configure each tunnel manually - I have some central route-servers. Optional, experimental, YMMV, etc. Thankfully, both Teredo and 6to4 use anycast for relay discovery, so if you have load problems you can deploy more of these for the cost of a server. As per usual, I'm giving it away free, see the following URL, or contact me off list: http://www.braintrust.co.nz/tui/ If you don't care about the "Tui" stuff, ignore those parts of the document, the rest will work just fine. ps. I'm looking at packet dumps of things right now, captured from torrent clients from the last wee while. I'll be rambling about this and pointing at pretty graphs in about a week at APNIC26. -- Nathan Ward

2 1

IPv6 Technical Workshops - PCH / Cisco - REMINDER
by Keith Davidson 18 Aug '08

18 Aug '08

All, I know I have already posted this message to the NOG list, but given there are still a few vacancies in both Auckland and Wellington, thought that I could again intrude with a reminder for folks who haven't yet responded... InternetNZ, in conjunction with REANNZ, Cisco, Packet Clearing House, NZRS, auDA and FX Networks, is offering IPv6 technical workshops in Christchurch and Auckland. This follows on from having already run this workshop in Wellington in August last year. The first 5 day programme will run in Christchurch from Saturday 30 August to Wednesday 3 September, and the second in Auckland from Monday 8 September to Friday 12 September. Attendence on each course is limited to 28 participants. Registration is on a first come, first served basis. Please see the attached document for details. More details are available at http://blog.internetnz.net.nz/wp-content/uploads/2008/07/2008-augsep-ipv6-w… To register email richard at internetnz.net.nz To keep this message list-compliant, please note InternetNZ will possibly provide beer to workshop participants. Cheers Keith Davidson Executive Director - InternetNZ

3 3

Getting your websites ready for Internet Explorer 8 - Come to our free Roadshow!
by Nick MacKechnie 13 Aug '08

13 Aug '08

HI All, FYI - This may be useful to you and your customers - feel free to pass this information on and participate where appropriate. Many thanks, Nick. Nick MacKechnie | Senior Technical Account Manager | Microsoft New Zealand Level 3, State Building, 88 Division Street, PO Box 8953, Riccarton, Christchurch 8041 p +64 3 961 7246 | m +64 21 999 010 | f +64 3 355 5527 | e nick.mackechnie(a)microsoft.com <mailto:nick.mackechnie(a)microsoft.com> Microsoft Premier Online <https://premier.microsoft.com/> Security Central <http://www.microsoft.com/security/> New Zealand Events <http://www.microsoft.com/nz/events/> New Zealand Press Centre <http://www.microsoft.com/nz/presscentre/> Technet/MSDN Flash <https://profile.microsoft.com/RegSysProfileCenter/SubCntDefault.aspx?lc id=5129> Services Catalogue <http://download.microsoft.com/documents/australia/services/mssrvcat_cur rent_lowres.pdf> OpenXML <http://www.microsoft.com/downloads/details.aspx?familyid=941b3470-3ae9- 4aee-8f43-c6bb74cd1466&displaylang=en> Blog <http://blogs.msdn.com/nickmac> This email is intended solely for the use of the addressee and may contain information that is confidential or subject to legal professional privilege. If you receive this email in error please immediately notify the sender and delete the email. If you prefer not to receive these types of communications from the sender, please forward this email to uptodate(a)microsoft.com <mailto:uptodate(a)microsoft.com> with "unsubscribe" in the subject line. To learn how to manage your contact preferences for other parts of Microsoft, please read our privacy statement <http://privacy.microsoft.com/en-nz/default.aspx> . From: Nick MacKechnie Sent: Wednesday, 13 August 2008 5:06 p.m. Subject: Getting your websites ready for Internet Explorer 8 - Come to our free Roadshow! Importance: High Hi All, Internet Explorer 8 takes the web experience beyond the page and introduces a new way to seamlessly experience the best of the web whether you are a web developer writing to standards or an end-user discovering a new online service integrated into the browser. We've also taken steps to deliver the fastest version of Internet Explorer available, making it easy to launch quickly, find what you want efficiently, and navigate seamlessly. Consistent with our efforts to promote further interoperability across the Web, Microsoft will be releasing Internet Explorer 8 to render content in its most standards-compliant way by default. Giving top priority to Web standards interoperability allows us to help web developers and designers drive toward the ideal of "write once, run anywhere", freeing up more time to innovate rather than modify content for different browsers. This commitment also addresses several development and design pain points from previous Internet Explorer releases. However, browsing with this default setting may cause content written for previous versions of Internet Explorer to display differently than intended. This creates a call to action for site owners to ensure their content will continue to display seamlessly in Internet Explorer 8. As such, we have provided a meta-tag usable on a per-page or per-site level to maintain compatibility for sites designed for Internet Explorer 7. Adding this tag instructs Internet Explorer 8 to render content like Internet Explorer 7, without requiring any additional changes. We are encouraging site administrators to get their sites ready now for broad adoption of Internet Explorer 8, as there will be a beta release in the third quarter of this year targeted for all consumers. Internet Explorer 8 Roadshow Come and have an overview of the new features and capabilities of Internet Explorer 8 straight from a senior member of the US based Internet Explorer team. Jefferson Fletcher is a Senior Product Manager working on Internet Explorer. Since joining Microsoft in 1996, Jefferson has spent the bulk of his career in engineering and has helped to deliver end-user features in multiple versions of Windows and Internet Explorer. A Seattle native, he left life as a poor Political Science major at the University of Washington 12 years ago because earning some extra cash as a software tester sounded like a good idea. (He has yet to find his way back...) Christchurch Monday 8th September Register <http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032385768&C ulture=en-NZ> 1.45pm: registrations/refreshments 2pm: Session begins 3pm: Session concludes Wellington Wednesday 10th September Register <http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032385790&C ulture=en-NZ> 1.45pm: registrations/refreshments 2pm: Session begins 3pm: Session concludes Auckland Friday 12th September Register <http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032385793&C ulture=en-NZ> 10.45pm: registrations/refreshments 11am: Session begins 12pm: Session concludes To learn more and to get started, please visit the New Zealand Internet Explorer Readiness website <http://www.microsoft.co.nz/ie8> and the New Zealand Internet Explorer 8 blog <http://blogs.msdn.com/nzie8> for more information. Many thanks, Nick. Nick MacKechnie | Senior Technical Account Manager | Microsoft New Zealand Level 3, State Building, 88 Division Street, PO Box 8953, Riccarton, Christchurch 8041 p +64 3 961 7246 | m +64 21 999 010 | f +64 3 355 5527 | e nick.mackechnie(a)microsoft.com <mailto:nick.mackechnie(a)microsoft.com> Microsoft Premier Online <https://premier.microsoft.com/> Security Central <http://www.microsoft.com/security/> New Zealand Events <http://www.microsoft.com/nz/events/> New Zealand Press Centre <http://www.microsoft.com/nz/presscentre/> Technet/MSDN Flash <https://profile.microsoft.com/RegSysProfileCenter/SubCntDefault.aspx?lc id=5129> Services Catalogue <http://download.microsoft.com/documents/australia/services/mssrvcat_cur rent_lowres.pdf> OpenXML <http://www.microsoft.com/downloads/details.aspx?familyid=941b3470-3ae9- 4aee-8f43-c6bb74cd1466&displaylang=en> Blog <http://blogs.msdn.com/nickmac> This email is intended solely for the use of the addressee and may contain information that is confidential or subject to legal professional privilege. If you receive this email in error please immediately notify the sender and delete the email. If you prefer not to receive these types of communications from the sender, please forward this email to uptodate(a)microsoft.com <mailto:uptodate(a)microsoft.com> with "unsubscribe" in the subject line. To learn how to manage your contact preferences for other parts of Microsoft, please read our privacy statement <http://privacy.microsoft.com/en-nz/default.aspx> .

1 0

AusNOG-02
by Jonny Martin 11 Aug '08

11 Aug '08

Just a reminder on behalf of our Austrlian colleagues that AusNOG-02 takes place next Thursday and Friday in Sydney. A NZ presence there would be much appreciated, particularly given many around the world hold NZNOG up as an example of a well- functioning NOG. I'm sure that's just asking for smart remarks from the dysfunctional amongst us! :) Full details at the now spangly http://www.ausnog.net/ Cheers, Jonny. (oh, and register for APNIC26 in Christchurch if you haven't already. Otherwise you'll be missing out on some good training and presentations. And more importantly leaving it up to others to decide what to do with the remaining IPv4 space...)

4 4

NZRR Route Registry Update
by NZRR Database Notifications 11 Aug '08

11 Aug '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:AS4770 descr: advertised to AS9439 by ICONZ Ltd - AS4770 members: 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 114.134.160.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 114.134.176.0/21^21-29, 120.138.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 203.80.60.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 199.212.92.0/23^23-29, 202.36.76.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.174.6.0/23^23-29, 205.233.136.0/23^23-29, 210.4.212.0/23^23-29, 192.88.85.0/24^24-29, 198.32.66.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.45.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.37.57.0/24^24-29, 202.37.73.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.163.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.139.0/24^24-29, 205.233.243.0/24^24-29, 210.54.211.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: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080627 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ Ltd - AS4770 members: 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 114.134.160.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 114.134.176.0/21^21-29, 120.138.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 205.233.128.0/21^21-29, 210.4.208.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 203.80.60.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 199.212.92.0/23^23-29, 202.36.76.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.174.6.0/23^23-29, 205.233.136.0/23^23-29, 192.88.85.0/24^24-29, 198.32.66.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.45.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.37.57.0/24^24-29, 202.37.73.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.163.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.139.0/24^24-29, 205.233.243.0/24^24-29, 210.54.211.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: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080812 source: NZRR --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.160.116.0/22^22-29, 202.124.106.0/23^23-29, 202.160.114.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 198.32.71.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.0/24^24-29, 203.119.56.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: noc(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.14.32.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.160.116.0/22^22-29, 202.124.106.0/23^23-29, 202.160.114.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 198.32.71.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.0/24^24-29, 203.119.56.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: peering(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080812 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 11 Aug '08

11 Aug '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:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.160.116.0/22^22-29, 202.124.106.0/23^23-29, 202.160.114.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 198.32.71.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.0/24^24-29, 203.119.56.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: noc(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.14.32.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.160.116.0/22^22-29, 202.124.106.0/23^23-29, 202.160.114.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 198.32.71.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.0/24^24-29, 203.119.56.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: peering(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080812 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 11 Aug '08

11 Aug '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:AS4770 descr: advertised to AS9560 by ICONZ Ltd - AS4770 members: 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 114.134.160.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 114.134.176.0/21^21-29, 120.138.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 203.80.60.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 199.212.92.0/23^23-29, 202.36.76.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.174.6.0/23^23-29, 205.233.136.0/23^23-29, 210.4.212.0/23^23-29, 192.88.85.0/24^24-29, 198.32.66.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.45.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.37.57.0/24^24-29, 202.37.73.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.163.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.139.0/24^24-29, 205.233.243.0/24^24-29, 210.54.211.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: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080627 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ Ltd - AS4770 members: 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 114.134.160.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 114.134.176.0/21^21-29, 120.138.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 205.233.128.0/21^21-29, 210.4.208.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 203.80.60.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 199.212.92.0/23^23-29, 202.36.76.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.174.6.0/23^23-29, 205.233.136.0/23^23-29, 192.88.85.0/24^24-29, 198.32.66.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.45.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.37.57.0/24^24-29, 202.37.73.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.163.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.139.0/24^24-29, 205.233.243.0/24^24-29, 210.54.211.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: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080812 source: NZRR ------------------------------------------------------------

1 0

FW: Akamai streaming cluster on APE.
by Craig Spiers 09 Aug '08

09 Aug '08

So is this supposed to be still operating? Trailers.apple.com went there for about a week.. as did downloads.microsoft.com now it appears to go via an akamai cluster in Australia? Tested via traceroute from orcon.. -----Original Message----- From: Steve Kurzeja [mailto:steve(a)a.geek.nz] Sent: Thursday, 31 July 2008 3:38 p.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] Akamai streaming cluster on APE. Hi All, This is a courtesy email to let those peering at APE know that their APE traffic may start to increase today. Callplus and Akamai have worked together to deploy an Akamai streaming cluster on the APE. ISPs peered at the APE accessing Akamai streaming content (e.g. trailers.apple.com) should see this traffic shift from your transit providers to APE today or in the near future. The IP address range for this cluster is 119.224.143.0/26. To check you are reaching it correctly trailers.apple.com should resolve to an IP address within 119.224.143.0/26 and route via callplus1.ape.net.nz. Regards, Steve _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

4 4

Comp tickets to Digital Future Now Event - Auckland
by Thomas Rowley 07 Aug '08

07 Aug '08

Hi all, I have a couple of comps to the digital future now event ( www.digitalfuturenow.co.nz) If anyone is interested drop me an email, Cheers Thomas

1 0

dns cache poisoning and "slutty" isp recursors
by Jasper Bryant-Greene 07 Aug '08

07 Aug '08

in light of the recently-discussed vulnerability (details of which are now public) and the exploit now available, do any of the affected ISPs think it might be prudent to stop letting the whole Internet recurse through their recursive nameservers? testing from an IP in the USA, I was able to make recursive queries at six major NZ ISPs, and there are no doubt more. I won't bother naming, it's trivial for anyone to figure it out for themselves, and the affected ISPs (should) know who they are. answering recursive queries from anywhere removes the need to get a client on the ISP's network to look up names for you in order to poison the cache of the recursor... -jasper

12 14

Google Apps Issues
by Ashwin Vasanth 06 Aug '08

06 Aug '08

Hello there, Sorry if this is the wrong place to post but just wondering, anyone on this list having issues with Google Apps this morning? Been seeing issues with multiple clients especially with the Email services. Anyone else seeing any noise about this or is it just me? -- Regards Ashwin Vasanth skype: ashwin_vasanth

2 1

Importance of end-to-end IPv4 - research - please help
by Shane Alcock 05 Aug '08

05 Aug '08

As Richard mentioned earlier, WAND has recently done some work on behalf of Alcatel looking at the viability of SP-NAT. In particular, I've been investigating the number of incoming connections to DSL customers for a NZ ISP - how many customers are accepting connections and how many connections are they accepting? Long story short, over 40% of observed customer addresses accepted at least one incoming TCP connection over the time period we looked (around 4 consecutive days, including a weekend). This ratio grows to be more than 60% when UDP is also considered, although the counts for UDP aren't as reliable. Most of the incoming connections are on either well-known p2p ports or high-number ports, suggesting a lot of customers doing some form of p2p. More detailed results (plus pretty graphs!) can be found at http://www.wand.net.nz/~spa1/someisp/flow_counting/result_page.html#inbound In addition, WAND also looked into the average number of outbound sessions that those same DSL customers were using. The main aim there was to determine how many customers it would be feasible to place behind a single SP-NAT device. The results of that can be found on the same web-page (just scroll up a bit). Note that all these results are for a single ISP during a particular time period. It is very likely that other ISPs would see significantly different numbers depending on the profiles of the customers they tend to attract - warez monkeys vs Grandma, for instance. Shane Alcock WAND Network Research Group University of Waikato Nathan Ward wrote: > Hi all, > > I'm attempting to get a bead on the importance of end-to-end IPv4. > > By that I mean, home DSL user talking to another home DSL user. > > This is something that would break if we ran out of IPv4 space > tomorrow, and had to start putting customers behind service provider > NAT (SP-NAT). > > There's two ways I'm looking at doing this are: > 1) Using a vendor box on loan to do p2p packet inspection for a month > or so. This will tell us about how much "p2p[1]" traffic there is on a > network, compared to non-p2p traffic. > 2) Getting a packet capture from somewhere on a network for an hour, > or whatever is feasible in terms of storage and processing power. The > target of the capture would be traffic to/from a certain block of an > ISPs end user type customers (so, a DSL pool probably). Analyse this > and match it against dynamic address pools. > - Anything going out to another dynamic pool (as determined by > one of those dynamic pool lists) is something that would be broken by > SP-NAT. > - Any new incoming connections is something that would be broken > by SP-NAT. > > If there's anyone that's interested in the following please let me know: > a) Helping me with some research > b) Getting some free intelligence on the type of traffic on your > network (wave it in front of marketing, and drip feed them the pretty > graphs whenever you want something from them) > > My intent is to publish the results stuff freely, publicly and widely. > > I'd even like to get to the point where we can do it regularly > perhaps? Let me know if you're open to that. > > -- > Nathan Ward > > [1] By this I mean file sharing, skype, etc. Stuff commonly identified > with the "p2p" buzz word, as opposed to the technical peer-to-peer > phrase. > _______________________________________________ > NZNOG mailing list > NZNOG(a)l... <http://list.waikato.ac.nz/mailman/listinfo/nznog> > http://list.waikato.ac.nz/mailman/listinfo/nznog >

21 33

Apply for your ISIF ICT grant online
by Srinivas Chendi 04 Aug '08

04 Aug '08

Apply for your ISIF ICT grant online [Brisbane, Australia - August 4th] With the successful launch of The Information Society Innovation Fund (ISIF), many developing economies in the Asia Pacific region are expecting to benefit from grants funding later in 2008. ISIF has been widely praised for helping ICT development projects in Asia Pacific developing economies. This will now be further enhanced with the ability to apply online for ISIF grants. APNIC'S Paul Wilson is "pleased with the positive response we have received from the community so far and are happy to notify potential applicants that grant applications may now be lodged directly on our website using an online form. Most importantly, we look forward to seeing the grants come to fruition." ISIF is a joint initiative between the Canadian International Development Research Centre (IDRC), the Internet Society (ISOC), and the Asia Pacific Network Information Centre (APNIC), aimed at stimulating creative solutions to ICT development needs in the Asia Pacific region. ISIF provides grants of up to US$30,000 per project to help advance local and regional projects aimed at introducing, improving, and applying Internet and other digital communications technologies for the benefit of Asia-Pacific users and communities. Project proposals from Asia-Pacific based public or private sector organisations, university or research and development institutions, and non-government organisations will be considered. Applications must be aligned with ISIF program objectives, selection criteria and administrative guidelines. Individuals are not eligible for grants. The ISIF grant round for 2008 is now open and applications are due 1 September 2008. A total of US$375,000 is available for grants in 2008. Grants are to be made on a competitive basis and successful applicants will be required to make project details, outcomes and findings publicly available. Complete information on the program and how to apply is available on the ISIF website at http://www.isif.asia The online application for the grant can be accessed directly from http://application.isif.asia ISIF is proudly sponsored by the DotAsia Organisation, the registry operator for the .ASIA top level domain. For more information: Sylvia Cadena | ISIF Program Officer | info(a)isif.asia | http://www.isif.asia

1 0

Importance of end-to-end IPv4 - research - please help
by Nathan Ward 04 Aug '08

04 Aug '08

Hi all, I'm attempting to get a bead on the importance of end-to-end IPv4. By that I mean, home DSL user talking to another home DSL user. This is something that would break if we ran out of IPv4 space tomorrow, and had to start putting customers behind service provider NAT (SP-NAT). There's two ways I'm looking at doing this are: 1) Using a vendor box on loan to do p2p packet inspection for a month or so. This will tell us about how much "p2p[1]" traffic there is on a network, compared to non-p2p traffic. 2) Getting a packet capture from somewhere on a network for an hour, or whatever is feasible in terms of storage and processing power. The target of the capture would be traffic to/from a certain block of an ISPs end user type customers (so, a DSL pool probably). Analyse this and match it against dynamic address pools. - Anything going out to another dynamic pool (as determined by one of those dynamic pool lists) is something that would be broken by SP-NAT. - Any new incoming connections is something that would be broken by SP-NAT. If there's anyone that's interested in the following please let me know: a) Helping me with some research b) Getting some free intelligence on the type of traffic on your network (wave it in front of marketing, and drip feed them the pretty graphs whenever you want something from them) My intent is to publish the results stuff freely, publicly and widely. I'd even like to get to the point where we can do it regularly perhaps? Let me know if you're open to that. -- Nathan Ward [1] By this I mean file sharing, skype, etc. Stuff commonly identified with the "p2p" buzz word, as opposed to the technical peer-to-peer phrase.

4 4

NZRR Route Registry Update
by NZRR Database Notifications 03 Aug '08

03 Aug '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:AS23755 descr: Route set advertised to AS9560 by MediaNET - AS23755 members: 202.7.4.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: rpsl-admin(a)nzix.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060222 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS23755 descr: advertised to AS9560 by Citylink - AS23755 members: 202.7.4.0/22^22-29, 202.8.44.208/28^28-29, 202.8.47.64/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dylan(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080804 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 03 Aug '08

03 Aug '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:AS23755 descr: Route set advertised to AS9439 by MediaNET - AS23755 members: 202.7.4.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: rpsl-admin(a)nzix.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060222 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS23755 descr: advertised to AS9439 by Citylink - AS23755 members: 202.7.4.0/22^22-29, 202.8.44.208/28^28-29, 202.8.47.64/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dylan(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080804 source: NZRR ------------------------------------------------------------

1 0

Re: [nznog] Akamai streaming cluster on APE.
by Richard Naylor 03 Aug '08

03 Aug '08

At 04:08 p.m. 31/07/2008, Allard, Simon, VF-NZ wrote: >Keep in mind that Akamai Streaming != Akamai Static content Not neccessarily. I did a live streaming job just before Christmas 07 for a site in Germany that had Akamai as its back end for both Live and on-demand. We were live for about 10 days. The feed point (ingest) was Sydney (via 2 different ISPs). The closest server was also Sydney from memory. The on-demand we uploaded to Germany each night. Peering used to be a dirty word at Akamai. Their business model/architecure didn't encourage it. So it would have been a "very large customer" (tm) who got it changed. It means on-line.skytv.co.nz will work now. Good work by CallPlus.

2 1

Re: [nznog] Akamai streaming cluster on APE.
by Anton Smith 02 Aug '08

02 Aug '08

> > Message: 18 > Date: Fri, 01 Aug 2008 00:37:36 +1200 > From: Richard Naylor <richard.naylor(a)r2.co.nz> > Subject: Re: [nznog] Akamai streaming cluster on APE. > To: "Allard, Simon, VF-NZ" <Simon.Allard(a)vodafone.com>, "Bill Walker" > <Bill.Walker(a)staff.snap.net.nz>, <nznog(a)list.waikato.ac.nz> > Message-ID: <20080731123754.0F3DD7D82D3(a)angus.iconz.co.nz> > Content-Type: text/plain; charset="us-ascii"; format=flowed > > At 04:08 p.m. 31/07/2008, Allard, Simon, VF-NZ wrote: > >Keep in mind that Akamai Streaming != Akamai Static content > > Not neccessarily. I did a live streaming job just before Christmas 07 > for a site in Germany that had Akamai as its back end for both Live > and on-demand. We were live for about 10 days. The feed point > (ingest) was Sydney (via 2 different ISPs). The closest server was > also Sydney from memory. The on-demand we uploaded to Germany each night. > > Peering used to be a dirty word at Akamai. Their business > model/architecure didn't encourage it. So it would have been a "very > large customer" (tm) who got it changed. > > It means on-line.skytv.co.nz will work now. > > Good work by CallPlus. > hmm... try telling that to Patrick Gilmore, the peering coordinator for akamai - one of the most vocal peering guys in europe. how long ago was it that peering was a dirty word for akamai? Anton

3 2

APNIC 26 - Early bird registration bonus
by Srinivas Chendi 31 Jul '08

31 Jul '08

________________________________________________________________________ APNIC 26 Early bird registration bonus - but hurry! ________________________________________________________________________ Dear APNIC members and friends APNIC 26 will be held from 25 to 29 August 2008 in Christchurch, New Zealand. Early bird registration ----------------------- Register by credit card before 01 August 2008 and go into the draw for an ASUS Eee PC! Now when you register online, you will be issued with an eTicket, which will make your onsite registration quicker and easier. Register now at: http://www.apnic.net/meetings/26/register Be part of APNIC 26 - from anywhere ----------------------------------- Participating in APNIC meetings from anywhere in the region is now even easier. Access the new APNIC remote participation interface that allows you to watch and hear the sessions in real time. Members can follow the meetings through live audio and video streaming, transcripts, and Jabber chat. If you would like to ask questions, you can join our Jabber chat rooms and have your question read live. If you are not able to access the session, you can log your question to be asked on your behalf. You can also attend the APNIC policy discussion and member meeting remotely at events in Manila, Philippines and Hanoi, Vietnam. APNIC would like to thank ASTI and VNNIC for their generous support for these events. Visit the meeting website for more details http://www.apnic.net/meetings/26/remote Hostmaster consultations ------------------------ Also at APNIC 26 are the hostmaster consultations, where members can personally consult with a hostmaster in a face-to-face environment. Online bookings are now available. Please visit "Hostmaster consultation" from: http://www.apnic.net/meetings/26 Sincerely, ________________________________________________________________________ APNIC Secretariat Asia Pacific Network Information Centre (APNIC) Tel: +61 7 3858 3100 PO Box 2131 Milton, QLD 4064 Australia Fax: +61 7 3858 3199 Level 1, 33 Park Road, Milton, QLD http://www.apnic.net ________________________________________________________________________

1 0

Akamai streaming cluster on APE.
by Steve Kurzeja 30 Jul '08

30 Jul '08

Hi All, This is a courtesy email to let those peering at APE know that their APE traffic may start to increase today. Callplus and Akamai have worked together to deploy an Akamai streaming cluster on the APE. ISPs peered at the APE accessing Akamai streaming content (e.g. trailers.apple.com) should see this traffic shift from your transit providers to APE today or in the near future. The IP address range for this cluster is 119.224.143.0/26. To check you are reaching it correctly trailers.apple.com should resolve to an IP address within 119.224.143.0/26 and route via callplus1.ape.net.nz. Regards, Steve

13 13

Re: [nznog] Akamai streaming cluster on APE.
by Steve Kurzeja 30 Jul '08

30 Jul '08

That is correct, and the streaming deployment also contains the standard Akamai content too. A heads up to ISPs with standard Akamai caches, you may want to check the traffic on your deployments hasn't dropped significantly. If it has then please contact Akamai. Steve > Keep in mind that Akamai Streaming != Akamai Static content > > > >> -----Original Message----- >> From: Bill Walker [mailto:Bill.Walker(a)staff.snap.net.nz] >> Sent: Thursday, 31 July 2008 4:03 p.m. >> To: nznog(a)list.waikato.ac.nz >> Subject: Re: [nznog] Akamai streaming cluster on APE. >> >> Lots of ISP's including Inspire, WorldxChange, Snap, Telstra >> and Telecom have Akamai Caching servers. >> >> traceroute download.microsoft.com >> >> Translating "download.microsoft.com"...domain server >> (202.37.101.1) [OK] >> >> Type escape sequence to abort. >> Tracing the route to a767.ms.akamai.net (202.124.116.42) >> >> 1 snap-chc-state2-rtr01.snap.net.nz (202.37.101.94) 0 msec >> 0 msec 0 msec >> 2 a767.ms.akamai.net (202.124.116.42) 0 msec 0 msec 0 msec >> >> Cheers, >> >> Bill >> >> -----Original Message----- >> From: Jed Laundry [mailto:jlaundry(a)gmail.com] >> Sent: Thursday, 31 July 2008 3:58 p.m. >> To: Matthew Poole >> Cc: nznog(a)list.waikato.ac.nz >> Subject: Re: [nznog] Akamai streaming cluster on APE. >> >> TelstraClear has a direct connection to Akamai, or at least >> it appears to from here at Waikato uni. >> >> I believe Xtra also has a direct link as well. >> >> Jed. >> >> >> >> Matthew Poole wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > >> > Jonathan Brewer wrote: >> > | Hi Steve, >> > | >> > | As an end user I can't begin to express how happy I am that my >> > | Akamai content will start coming from New Zealand, >> instead of from >> > | Japan via San Jose. >> > | >> > | Cheers to Callplus! >> > | >> > But only if you're not connecting through TelstraClear. And >> has Xtra >> > got its peering sorted out yet? >> > - -- >> > 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 >> > >> > iD8DBQFIkTV9TdEtTmUCdpwRAkROAKCdUYHyCV0sc2Kx5Uqy5G16l2kOBACfb0j9 >> > 0513O/k0m9KSupjls/jy56w= >> > =PYqC >> > -----END PGP SIGNATURE----- >> > _______________________________________________ >> > NZNOG mailing list >> > NZNOG(a)list.waikato.ac.nz >> > http://list.waikato.ac.nz/mailman/listinfo/nznog >> >> -- >> Thanks, >> Jed. >> >> -- >> Jed Laundry >> jlaundry(a)gmail.com >> >> +64 27 612 0522 >> _______________________________________________ >> 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 - http://www.avg.com >> Version: 8.0.138 / Virus Database: 270.5.8/1582 - Release >> Date: 30/07/2008 6:37 p.m. >> _______________________________________________ >> NZNOG mailing list >> NZNOG(a)list.waikato.ac.nz >> http://list.waikato.ac.nz/mailman/listinfo/nznog >> > ----------------------------------------------------------------------------------------------- > > Unless otherwise stated, any views or opinions expressed are solely those > of the author and do > not represent those of Vodafone New Zealand Limited. > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog >

1 0

very strange browsing issue from international after 5:XXpm
by Barry Murphy 30 Jul '08

30 Jul '08

Hey guys, I've a little problem which I've logged with Orcon but wondering if anyone on this list could possibly give some advise, or if anyone else on this list has seen this issue lately. A client of mine has developers in India, there developers have not been able to access servers hosted by us after 5:30pm in the evening, however during the day (NZST) they can view the pages fine. what happens is the page doesn't load at all, they just get a blank page and it times out, however they can ping and traceroute to our servers just fine. During the time when they get these timeouts, they're able to load Orcon.net.nz with no issues and all other sites in NZ. I will also mention that I've had people test this from windows, linux, unix, internet explorer, firefox, lynx, etc and the users are coming from South Africa, india, kenya, the odd one in Australia, etc. Most other countries can view the sites with no issues, but the whole of india cant and other select countries. I've had them run mturoute, traceroute, ping, load sites by IP address, and much more, but it doesn't work, every now and then pages will start loading for a short period. I've cut data over to our secondary circuit, checked for errors, checked mtu's, replaced juniper gear with cisco gear, had them attempt to connect to other servers etc. I've replaced every node and piece of gear in our network and used different ethernet paths from within Orcons DC and the problem still persists. Unfortunately Orcon's technical support ends at 5pm, this problem starts at 5:30pm, on-call staff don't appear to be able to help as the problem is a little over their head and network engineers only work on faults during the day. The problem started Sunday from what I can tell and 2 nights in a row I've asked for help from orcon but have received none yet, however they did mention it's funny one other person reported a similar issue. So, does anyone have any suggestions for me (off list please) and is anyone else seeing similar issues on their network in the evening through orcon or other vendor? In case this is a little off-topic (which I hope it's not), beer for the person that can fix this! Thanks Barry Murphy

3 2

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

28 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:AS24324 descr: advertised to AS9560 by Kordia - AS24324 members: 118.148.0.0/15^15-29, 124.157.64.0/18^18-29, 58.84.224.0/20^20-29, 114.134.0.0/20^20-29, 116.89.224.0/20^20-29, 202.56.32.0/20^20-29, 202.68.80.0/20^20-29, 203.144.32.0/20^20-29, 116.90.128.0/21^21-29, 117.104.176.0/21^21-29, 123.108.144.0/21^21-29, 202.20.0.0/21^21-29, 202.49.16.0/21^21-29, 202.49.128.0/21^21-29, 202.56.48.0/21^21-29, 202.137.240.0/21^21-29, 218.185.224.0/21^21-29, 202.6.116.0/23^23-29, 202.27.88.0/23^23-29, 202.65.160.0/23^23-29, 202.174.190.0/23^23-29, 203.110.28.0/23^23-29, 192.173.17.0/24^24-29, 202.21.130.0/24^24-29, 202.27.34.0/24^24-29, 202.27.83.0/24^24-29, 202.27.90.0/24^24-29, 202.36.75.0/24^24-29, 202.36.137.0/24^24-29, 202.36.154.0/24^24-29, 202.36.173.0/24^24-29, 202.37.168.0/24^24-29, 202.37.197.0/24^24-29, 202.49.158.0/24^24-29, 202.49.183.0/24^24-29, 203.30.174.0/24^24-29, 203.92.25.0/24^24-29, 203.171.4.0/24^24-29, 203.174.26.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: smc(a)kordia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080630 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS24324 descr: advertised to AS9560 by Kordia Ltd - AS24324 members: 118.148.0.0/15^15-29, 124.157.64.0/18^18-29, 58.84.224.0/20^20-29, 114.134.0.0/20^20-29, 116.89.224.0/20^20-29, 202.56.32.0/20^20-29, 202.68.80.0/20^20-29, 203.144.32.0/20^20-29, 116.90.128.0/21^21-29, 117.104.176.0/21^21-29, 123.108.144.0/21^21-29, 202.20.0.0/21^21-29, 202.49.16.0/21^21-29, 202.49.128.0/21^21-29, 202.56.48.0/21^21-29, 202.137.240.0/21^21-29, 218.185.224.0/21^21-29, 202.6.116.0/23^23-29, 202.27.88.0/23^23-29, 202.49.164.0/23^23-29, 202.65.160.0/23^23-29, 202.174.190.0/23^23-29, 203.110.28.0/23^23-29, 192.173.17.0/24^24-29, 202.21.130.0/24^24-29, 202.27.34.0/24^24-29, 202.27.83.0/24^24-29, 202.27.90.0/24^24-29, 202.36.75.0/24^24-29, 202.36.137.0/24^24-29, 202.36.154.0/24^24-29, 202.36.173.0/24^24-29, 202.37.168.0/24^24-29, 202.37.197.0/24^24-29, 202.49.158.0/24^24-29, 202.49.168.0/24^24-29, 202.49.183.0/24^24-29, 203.30.174.0/24^24-29, 203.92.25.0/24^24-29, 203.171.4.0/24^24-29, 203.174.26.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: praneel.prasad(a)kordia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080729 source: NZRR ------------------------------------------------------------

1 0

Change to APNIC minimum IPv4 allocation size
by Elly Tawhai 28 Jul '08

28 Jul '08

________________________________________________________________________ Change to APNIC minimum IPv4 allocation size ________________________________________________________________________ The information in this announcement is to enable the Internet community to update network configurations, such as routing filters, where required. Dear NZNOG Community, >From 4 August 2008, the new APNIC minimum IPv4 allocation size will be /22. For information on this policy change, see: http://www.apnic.net/policy/proposals/prop-053-v003.html For information on the minimum allocation sizes within address ranges administered by APNIC, please see: http://www.apnic.net/db/min-alloc.html For more information on the resources administered by APNIC, please see: http://www.apnic.net/db/ranges.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

Re: [nznog] Digital Future Now Event - Auckland
by Stu Fleming 28 Jul '08

28 Jul '08

> > "Hon. David Cunliffe, Minister for Communication and Information Technology, > will discuss the government's final Digital Strategy for New Zealand > business." "Final". Ouch. So the election has been [bf]ought already?

1 0

Digital Future Now Event - Auckland
by Thomas Rowley 28 Jul '08

28 Jul '08

Just letting everyone know about 'Digital Future Now' 13th August 2008 - Sky city Convention Centre, Auckland "This one day business forum is a follow up to the Digital Future Summit and will look at all of the issues for businesses operating in an increasingly online environment." "Hon. David Cunliffe, Minister for Communication and Information Technology, will discuss the government's final Digital Strategy for New Zealand business." *www.digitalfuturenow.co.nz* <http://www.digitalfuturenow.co.nz> Thanks Thomas

1 0

Re: [nznog] DNS Cache Poisoning
by Spiro Harvey, Knossos Networks Ltd 28 Jul '08

28 Jul '08

> Once this had gone public CCIP should have engaged this forum. CCIP has > well defined procedures and processes in place when sharing information with > the National and International security communities and the "traditional" > critical infrastructure community. Outside of those communities the process Does "critical national infrastructure" (as quoted from your website) include all NZ ISPs, or just the big players? > Another suggestion is the > need for a closed mailing list for the NZ ISP community. Closed lists seem to serve two purposes: 1) making the members feel 1337; and 2) money spinners. And who would act as the "police" to ensure that all members are ISP representatives? Who would keep tabs on which members have changed jobs and thus require removal from the list? I see this as a way to introduce #2 as above. Then you give all members club cards or secret decoder rings and if the smaller ISPs have trouble coming up with the funds, they'll be excluded. Perhaps it's more pertinent to ask "What is the end goal?" Is it to keep the NZ ISP industry aware of all security issues? Or is it to create a secret club? It's likely that the undesirables already know of the vulnerabilities, and the media will find out anyway and put some dramatic spin on it to keep themselves employed. What about operators of private networks? Shouldn't they know about these issues to protect their networks from attack? In this scenario, one poisoned DNS cache on a company intranet could lead to an entire company's PCs being hijacked or infected, or whatever the poisoner decides will provide the maximum amusement. With your secret club proposal, these network operators would not be aware of the issues because they're not ISPs. I believe NZNOG is the perfect avenue for security vulnerability disclosure. -- Spiro Harvey Knossos Networks Ltd 021-295-1923 www.knossos.net.nz

1 0

Re: [nznog] DNS Cache Poisoning
by Nathan Ward 27 Jul '08

27 Jul '08

On 28/07/2008, at 11:28 PM, Paul McKitrick wrote: > Good Evening Everyone, > > I have to agree with Joe's post and I have also had a number of > other off > post emails reiterating the same message. > > Once this had gone public CCIP should have engaged this forum. CCIP > has > well defined procedures and processes in place when sharing > information with > the National and International security communities and the > "traditional" > critical infrastructure community. Outside of those communities the > process > is not as well defined and this event has highlighted this. What > this event > has also demonstrated is that the NZNOG community is dedicated to > protecting > New Zealand's networks and we just need to figure out how we can do > that > together, and part of that is ensuring the right information gets to > the > right people. > > One of the recent suggestions CCIP has received is the concept of > establishing an NSP-SEC group for New Zealand. Another suggestion > is the > need for a closed mailing list for the NZ ISP community. The > intention > would not be to replace the NZNOG mailing list but to have an > alternative > for when the community needed a closed and trusted mode of > communication. > CCIP would like to work with this community to investigate > establishing > something along these lines in New Zealand and to listen to your > thoughts > and suggestions on this topic as a number of you have been thinking > about > this for some time as well. I'm not sure I understand what benefit a closed list would have in this sort of scenario, to be honest. I can't imagine that CCIP, or anyone else, are going to have information about security problems like this before they are in the wild - there's just too many people involved globally for closed distribution to be truly closed. The NZ ISP community (or at least those who I imagine you'd put on such a closed list) is small enough that all those people have everyone else's contact details already, and any incident really only needs calls or emails to two or three other providers. A large benefit for most people who attend the NZNOG conferences is the ability to have a beer with their industry peers and set up those contacts[1]. The only thing I could imagine a list would be used for is discussion about technical issues where media, end users, and other generally non- technical people cannot read[2] - but that's not really a security list. -- Nathan Ward [1] This sentence doesn't really add much, but I'm bringing my post on topic :-) [2] Some have suggested that the presence of media, end users, etc. on NZNOG is a large factor in the lack of pure technical content. Some people talked about setting up an invite only list a few years ago, but it never got off the ground (or at least, if I did I wasn't invited ;-), largely because it was assumed that legal departments would have a problem with open technical discussion - even without media, end users, etc. listening in. -- Nathan Ward

2 1

DNS Cache Poisoning
by Paul McKitrick 27 Jul '08

27 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good Evening All, I thought it would be good to let you know that CCIP is aware of this vulnerability and has been working on it behind the scenes with the international community since May. In early July CCIP met with NZ Registry Services to discuss this issue and determine who the most appropriate audience for this information would be. Because of the sensitivity of this it was determined that the NZNOG mailing list would not be appropriate as it is an open forum with over 800 registered participants. It was agreed that the best method would be to send this out to the ISPANZ members. CCIP also issued an embargoed release to some of the larger ISP's prior to the public release. CCIP regularly work very closely with the international CERT community to coordinate on the dissemination of information such as this and we have been working a lot over the last few weeks to coordinate on this particular release. CCIP had the release prepared to send out the morning that it was made public. This was a report that had been prepared in conjunction with the international CERT community. While it may appear that CCIP or other CERTs reporting is just simply re-badged products from another country it has often has been worked on collaboratively prior to the release. This is to ensure that clear and consistent messages are being issued by all countries. CCIP is hosting an international meeting here later in the year where a key item on the agenda is this specific event. There will be a review of this collaborative effort and where it worked well and where there is room for improvement. CCIP has identified that in New Zealand there is a need for a stronger relationship between CCIP and the NZ ISP community and developing those relationships is going to be an ongoing process. If you have any details of vulnerable DNS servers in New Zealand please do not hesitate to send these through to incidents(a)ccip.govt.nz. There have been some already sent through today from members of this list and those have been or are being addressed by the relevant ISP's and thank you for sending those through. If you would like to introduce yourself to CCIP and/or to arrange a time to come in to meet with CCIP please feel free to contact CCIP at (info(a)ccip.govt.nz). Regards, Paul. - -- Paul McKitrick Business Manager Centre for Critical Infrastructure Protection P: (+64) 4 498 7654 F: (+64) 4 498 7655 E: paul.mckitrick(a)ccip.govt.nz W: www.ccip.govt.nz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBSIlzyDpQQM+EFUs7AQKLqwgAyfn/HPnxWW3MQvyt6nPHQJwkTIk8slpK 0SoclMnIoyX7HxJhjFF8z369Bfece1xg/3kUE4D2d693lVv1Aih6LUIf/BrprppF iJJmZCXbf3n3y2ZSLembf+vDj/Ff1/JYFECDKLsJNjDESTd2i2X6EgeZGMXeR41p cwKVUoyrmWbdmBcsxHkwAjy8KBwBBIBzBiwkW7tKd9Ed5RhoIlVrkmWgrJrdvMDf aF28UUUP2aYRisHrZJnTwkw1Z3ghFp12emNj2EMJons0ZLPKLhV1vt573eeyqFYH deQ6BbYNqpzvNrqVewSE07kBY2t8SDf3wFs8sI+VoPinAV8HGyvUvg== =NmEG -----END PGP SIGNATURE----- --- This e-mail contains official New Zealand Government information, which is intended for the use of addressees only. If you have received this e-mail in error, please notify the sender immediately and delete. You should not further disseminate, distribute or copy this e-mail in any way. ---

4 4

Christchurch 5756
by Stan Rivett 27 Jul '08

27 Jul '08

Hi Guys Has anyone fired up anything new or changed channels on Saturday around the Christchurch CBD? I've been running my South facing AP happilly on 5756 MHz for about 4 years and now all my clients on this AP are pretty much toast :( Cheers Stan Rivett ------------------ Netspeed Data Ltd PO Box 5691 Dunedin P: +64 3 481 7245 F: +64 3 481 7249 C: +64 21 323 841 Skype: stan-r ------------------

1 0

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

24 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:AS64595 descr: Route set advertised to AS9439 by Learning Media - AS64595 members: 210.55.244.160/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: gary(a)learningmedia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040702 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS64595 descr: advertised to AS9439 by LearningMedia - AS64595 members: 203.167.252.112/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: terry.moore(a)learningmedia.co.nz notify: gary.jarvis(a)learningmedia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080725 source: NZRR ------------------------------------------------------------

1 0

Fwd: [apnic-talk] [Apnic-announce] AS number change could affect Internet routing from 1 January 2009
by Neil Fenemor 24 Jul '08

24 Jul '08

A bit of an FYI. It may be worth members approaching their respective vendors to find out what the timelines are around this. ---------- Forwarded message ---------- From: <secretariat(a)apnic.net> Date: 2008/7/25 Subject: [apnic-talk] [Apnic-announce] AS number change could affect Internet routing from 1 January 2009 To: apnic-announce(a)apnic.net ________________________________________________________________________ AS number change could affect Internet routing from 1 January 2009 ________________________________________________________________________ Manufacturers urged to upgrade routers and network management software to support the use of four-byte Autonomous System numbers by 1 January 2009. Regional Internet Registries (RIRs), including Asia Pacific Network Information Centre (APNIC), have warned that routers and network management software should be upgraded ahead of the increased distribution of four-byte (also known as 32-bit) Autonomous System (AS) numbers. AS numbers are a vital part of the Internet's core routing system, the Border Gateway Protocol (BGP). With existing two-byte AS numbers predicted to run out in early 2011, RIRs will issue four-byte AS numbers by default (unless otherwise specifically requested) beginning 1 January 2009, as the next phase of a transition from two- to four-byte numbers. Following a globally coordinated policy, RIRs began allocating four-byte AS numbers by request only in January 2007; January 2009 marks the transition to allocating four-byte AS numbers by default. Without timely support from vendors, network operators risk having routers and network administration systems that won't accept the expanded four-byte number format. As such, the RIRs urge operators to verify their vendors' routers will support four-byte AS numbers. Geoff Huston, Chief Scientist at APNIC, expressed severe concerns over failure to prepare for four-byte AS numbers: "AS numbers are often used to identify external relationships, set routing attributes, and manage traffic. Learning from our current experiences with IPv6 preparation issues, Internet engineers designed four-byte AS numbers to be backward compatible with much of the installed network infrastructure. But new entrants and networks that are expanding or merging will need new AS numbers and as of 1 January 2009 these will be, by default, four-byte AS numbers. If router software and support systems in critical parts of the Internet's infrastructure aren't upgraded by January, we'll encounter some significant network routing problems. We're extremely concerned that a lot of routers and network management software out there cannot and will not be able to recognize four-byte AS numbers". An Autonomous System (AS) is a collection of networks, or routers, administered as a group sharing a common set of routing policies, each defined with a unique number, or AS number. Massive Internet growth has depleted the existing pool of two-byte AS numbers (65,536 numbers in total). As a result, engineers have expanded the AS number space from two bytes to four-bytes, to include over 4 billion AS numbers. Some routers do not currently support the use of four-byte AS numbers. To help vendors understand what they need to do to provide four-byte AS number support and to help network operators find products that support four-byte AS numbers, APNIC has set up a special website at: http://wiki.icons.apnic.net/display/ASN/Home Yours sincerely ________________________________________________________________________ APNIC Secretariat Asia Pacific Network Information Centre (APNIC) Tel: +61 7 3858 3100 PO Box 2131 Milton, QLD 4064 Australia Fax: +61 7 3858 3199 Level 1, 33 Park Road, Milton, QLD http://www.apnic.net ________________________________________________________________________ _______________________________________________ Apnic-announce mailing list Apnic-announce(a)lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-announce _______________________________________________ apnic-talk mailing list apnic-talk(a)lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-talk

1 0

IPv6 Technical Workshops - PCH / Cisco
by Keith Davidson 24 Jul '08

24 Jul '08

All, InternetNZ, in conjunction with REANNZ, Cisco, Packet Clearing House, NZRS, auDA and FX Networks, is offering IPv6 technical workshops in Christchurch and Auckland. This follows on from having already run this workshop in Wellington in August last year. The first 5 day programme will run in Christchurch from Saturday 30 August to Wednesday 3 September, and the second in Auckland from Monday 8 September to Friday 12 September. Attendence on each course is limited to 28 participants. Registration is on a first come, first served basis. Please see the attached document for details. More details are available at http://blog.internetnz.net.nz/wp-content/uploads/2008/07/2008-augsep-ipv6-w… To register email richard at internetnz.net.nz To keep this message list-compliant, please note InternetNZ will possibly provide beer to workshop participants. Cheers Keith Davidson Executive Director - InternetNZ

1 0

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

23 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:AS65531 descr: Route set advertised to AS9439 by parliament - AS65531 members: 202.22.16.0/23^23-29, 202.22.18.0/24^24-29, 202.22.23.0/24^24-29, 202.22.30.0/24^24-29, 202.49.210.0/24^24-29, 202.49.213.0/24^24-29, 203.97.200.0/24^24-29, 203.97.232.80/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: john.howell(a)parliament.govt.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20051102 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS65531 descr: advertised to AS9439 by Parliamentary Service - AS65531 members: 202.22.16.0/21^21-29, 202.49.208.0/21^21-29, 202.22.24.0/22^22-29, 202.22.28.0/23^23-29, 202.22.30.0/24^24-29, 203.97.232.80/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: John.Howell(a)parliament.govt.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR ------------------------------------------------------------

1 0

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

23 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:AS17705 descr: advertised to AS9560 by InspireNet - AS17705 members: 203.114.128.0/18^18-29, 121.79.192.0/19^19-29, 192.138.251.0/24^24-29, 203.92.25.0/24^24-29, 210.7.46.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: brenden(a)staff.inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080411 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17705 descr: advertised to AS9560 by InspireNet - AS17705 members: 203.114.128.0/18^18-29, 121.79.192.0/19^19-29, 140.200.248.0/22^22-29, 192.138.251.0/24^24-29, 203.92.25.0/24^24-29, 203.174.26.0/24^24-29, 210.7.46.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: brenden(a)staff.inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR ------------------------------------------------------------

1 0

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

23 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:AS17705 descr: advertised to AS9439 by InspireNet - AS17705 members: 203.114.128.0/18^18-29, 121.79.192.0/19^19-29, 192.138.251.0/24^24-29, 203.92.25.0/24^24-29, 210.7.46.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: brenden(a)staff.inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080410 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS17705 descr: advertised to AS9439 by InspireNet - AS17705 members: 203.114.128.0/18^18-29, 121.79.192.0/19^19-29, 140.200.248.0/22^22-29, 192.138.251.0/24^24-29, 203.92.25.0/24^24-29, 203.174.26.0/24^24-29, 210.7.46.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: brenden(a)staff.inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR ------------------------------------------------------------

1 0

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

23 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:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.160.116.0/22^22-29, 202.124.106.0/23^23-29, 202.160.114.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.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: service(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080619 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.160.116.0/22^22-29, 202.124.106.0/23^23-29, 202.160.114.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 198.32.71.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.0/24^24-29, 203.119.56.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: noc(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR ------------------------------------------------------------

1 0

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

23 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:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.160.116.0/22^22-29, 202.124.106.0/23^23-29, 202.160.114.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.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: service(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080619 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.160.116.0/22^22-29, 202.124.106.0/23^23-29, 202.160.114.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 198.32.71.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.0/24^24-29, 203.119.56.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: noc(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR ------------------------------------------------------------

1 0

Rule 6... part 2.
by Steve Holdoway 21 Jul '08

21 Jul '08

Apologies to those who didn't get the Monty Python reference ( there is no rule 6, after all! ), I'll take the general census as an ok, and hope this isn't too off-list. I'm working for a company down here in Christchurch who are developing a new tool aimed at catching email spam. Much simplified, it uses linear regression techniques to create a signature of the email involved, and then performs a fuzzy match on that sig against databases held on our servers ( via a local cache to improve performance ). We reckon we've got it to be pretty indestructible ( and with a pretty small footprint ), but we need to test it further. Are there any ISP's out there who could help us out by a) trialling it ( our testing up to now has been as a milter under sendmail/postfix on linux ), and/or b) sending us loads of spam to stress our backend processes?? If so, could they contact me offlist? Cheers and thanks, Steve

1 0

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

21 Jul '08

In message <20080708234533.B080B112872(a)wat.la.naos.co.nz>, Ewen McNeill writes: >See also, eg, http://isc.sans.org/diary.html?storyid=4687 which has some >sane discussion of the issue [...] It appears that someone guessed close enough to how the attack worked to cause one of the people "in the know" to post a confirmation, and then attempt to withdraw it -- but of course people have found traces of the confirmation description and mirrored it. So the cat seems to be out of the bag, and presumably the Bad Guys (tm) will now try to do this for real. See, eg, http://it.slashdot.org/it/08/07/21/2212227.shtml which has various cut'n'paste copies of what seems to be the confirmation description, plus a link to the guess that prompted it. >Amongst other things they suggest patching any recursive/caching DNS >servers with vendor patches at the soonest suitable patch window. If you haven't already patched your recursive/caching DNS servers used by customers, today would be a good day to do it. So says Dan Kaminsky who found the issue in the first place: http://www.doxpara.com/?p=1176 Also beware that the NAT in at least some firewalls has been reported to undo the port randomisation that the patch introduces, resulting in predictable port numbers again (and thus no increase in randomness or protection against this attack). Linux-based firewalls are reported to be okay (apparently by default they pass through the port number used by the client on outgoing UDP packets if they can), and presumably OpenBSD based ones are okay given their choice to randomise everything. But beware of running recursive DNS servers behind NAT on firewalls without checking what the outgoing packets look like -- if in doubt perhaps put your recursive DNS servers into the DMZ outside the NAT. Ewen

1 0

Rule 6.
by Steve Holdoway 20 Jul '08

20 Jul '08

... which in this case isn't 'No pommy poofters' (: Is is appropriate to post a request for partners to trial software, or is this a breach of the aforesaid rule??? Cheers, Steve

3 2

Compromised websites
by Glen Eustace 14 Jul '08

14 Jul '08

Hi, We have had only a single site compromised so far but googling around indicates that this particular hack is all over the place. On the site in question all files .htm, .html and .shtml have had code added before the </body> tag, the code is a <jscript></jscript> that loads fgg.js from http://www.usaadw.com, the script that is loaded then tries to open an iframe but the content gives a 500 server error. I can not identify the vector used to edit all the files. This is on a linux server running apache 2 but google finds plenty of .asp pages that have been attached as well. The script is also called ngg.js but has almost identical content. Has anyone else been hit and if so, has the vector been identified ? Any assistance appreciated. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Glen and Rosanne Eustace GodZone Internet Services, a division of AGRE Enterprises Ltd. P.O. Box 8020, Palmerston North, New Zealand 4446. Ph: +64 6 357 8168, Fax +64 6 357 8165, Mob: +64 21 424 015 http://www.godzone.net.nz "A Ministry specialising in providing low-cost Internet Services to NZ Christian Churches, Ministries and Organisations."

7 12

Re: [nznog] Compromised websites
by Gary T. Benner 14 Jul '08

14 Jul '08

[Reply] HI all, We use "denyhosts" as well to monitor attempts to break into SSH ports, and are getting on average 50 per day over 20 servers. Interesting that it is "real" regular! Weekends even. cheers Gary 123 Internet Ltd At 10:09 on 15/07/2008 you wrote >To : NZNOG(a)list.waikato.ac.nz >CC : >From: Steve Holdoway, steve(a)greengecko.co.nz >Content Type: text/plain >Attached: att-080715100913828-2.txt > > > > >On Tue, 15 Jul 2008 08:34:17 +1200 >Steve Holdoway <steve(a)greengecko.co.nz> wrote: > >> I don't, but I run logcheck to *tell* me ( and fcheck to tell me of any file changes, and... )! tbh my production servers have a backdoor single account ssh access to the internet, which is protected by denyhosts, and all other access is from a staging server via vpn, still using secure ( but separate ) protocols. I don't care too much about the shortcomings of denyhosts, as a) it's protecting the emergency backup service, and b) I've got enough static ip addresses whitelisted to get in from - imo it's perfect for this job. >> >> OK, you *could* break in through a distributed attack on the ssh port, but the real risk to my servers is now human, from those with the relevant knowledge of the network configuration. But to me the chances of someone looking for a starting point 9000 miles from the server, breaking in, then going through a few other hoops before hacking across the vpn to the production server is remote enough to put a long way down my list. >> >> And, of course, I'm lucky enough not to have to support 1903 vintage IBM boat anchors (: >> >> >> Steve >> >Just to follow this up from this morning... > >>From Logcheck... >Jul 15 07:16:54 server sshd[8129]: Failed password for invalid user hipcomix from 207.210.107.2 port 34553 ssh2 >Jul 15 07:16:54 server sshd[8132]: Failed password for root from 207.210.107.2 port 34566 ssh2 >Jul 15 07:16:55 server sshd[8134]: Failed password for invalid user jpeger from 207.210.107.2 port 34582 ssh2 >Jul 15 07:16:55 server sshd[8139]: Failed password for invalid user favs from 207.210.107.2 port 34606 ssh2 >and a few more... > >>From Denyhosts... >Date: Tue, 15 Jul 2008 07:17:00 +1200 > >Added the following hosts to /etc/hosts.deny: > >207.210.107.2 (unknown) > > >Steve > > >_______________________________________________ >NZNOG mailing list >NZNOG(a)list.waikato.ac.nz >http://list.waikato.ac.nz/mailman/listinfo/nznog Ref#: 41006

1 0

Re: [nznog] Compromised websites
by Scott Weeks 14 Jul '08

14 Jul '08

------- criggie(a)criggie.dyndns.org wrote: ------------ From: Criggie <criggie(a)criggie.dyndns.org> And if you're not watching/analyzing your logs, its very easy to miss someone trying passwords. <snip> Who's going to notice an extra 400 bytes/sec on a busy link, other than by monitoring logs for denied requests? -------------------------------------------------------- Depending on which program you use, you can set a max number of attempts by clients on the FTP server. scott

1 0

Kiwicon CFP 2k8 - Update
by Simon Howard 09 Jul '08

09 Jul '08

-----------------------------------------------------------------------] _.-.. __ .__ .__ ,'9 )\)`-.,.--. | | _|__|_ _ _|__| ____ ____ ____ 2k8 `-.| `. | |/ / \ \/ \/ / |/ ___\/ _ \ / \ \, , \) | <| |\ /| \ \__( <_> ) | \ `. )._\ (\ |__|_ \__| \/\_/ |__|\___ >____/|___| / |// `-,// \/ \/ \/ ]|| //" "" "" BAAAAAAaaaa!!11 [-------------------------------------------------- www.kiwicon.org----] Holy sheepshit, internets! Blanket-Man[1] has wrung out his loin cloth and is ready to fly-tackle more nerds with large egos and irc handles. Yes, it's time to open up your ~/haxing folder and get your talk together for Kiwicon 2k8! We've put out the black t-shirts, and deflated some satellite radomes, so where, as our more criminal yet fetchingly bikini clad cousins might say, the bloody hell are you? The Kiwicon Crüe is proud to announce the call for presenters for the second installment of New Zealand's very own security conference: Kiwicon 2k8. [CFP Update] Despite being a community con, Kiwicon is now pleased, if not delighted to the point of gratuitous Morris dancing to be able to offer financial support for travel to a limited number of speakers. More details are available in the Submission section below. We've already had a number of great talks submitted, and slots are filling fast. Those of you attending cons this year will already be aware of the number of Kiwis presenting - AusCERT, Shakacon, Syscan, Blackhat, Defcon, Ruxcon - you should see these guys in their natural habitat. They drop more 0day, wear tighter pants, and are 30% more likely to coyly flutter their eyelashes at you. [About] Kiwicon2k8 is intended to be an informal conference, drawing on the wider security community of Australia and New Zealand. It will be held in Wellington, New Zealand, on the weekend of the 27th and 28th of September, 2008. Kiwicon's focus is on sharing information; ideas, code, and good whisky, in a rabelaisan carnival of security, nerdery, and *nix beards. Last year, the inaugural Kiwicon ended up being kind of a big deal: highlights included tmasky's mighty Crackstation, the debut of Beau Butler as an "ethical hacker" making Microsoft "look like turkeys", and of course the Kiwicon Hax0r Quiz, with the winner taking the grand prize of An Illustrated Guide to the Commoner Skin Diseases. Hope it came in handy for the post-con diagnosis phase, dude. This year, Kiwicon's own Bogan is already making anti-virus vendors quake in their little signature-laden booties at Defcon's Race to Zero, and the cauldron of 0h-0h-0hday in Brett Moore's secret Insomnia lair is bubbling over with pernicious brew. If you missed last Kiwicon (not "professional enough"? couldn't convince your boss it wasn't a hoax?) then find one of the 230+ people who were there and ask them if they're just-not-gonna-bother this year. [Venue] Our hosts for the weekend will, once again, be Victoria University of Wellington. If you have any memory of last year's Kiwicon, then it'll look disturbingly familiar. The campus has the advantage of being close to the center of the city and its' various amenities. This includes cheap accommodation, good coffee, and, more importantly, several good pubs serving good, non-Australian, beer. [Costs] Kiwicon2k8 is a non-profit, non-commercial, non-corporate-funded event. Attendance for the entire weekend will cost $50 for employed individuals (self-employed and salaried). There is a discounted rate of $30 for students and the unemployed. GST receipts can be issued upon request. If your management can't be convinced of the value of something that only costs $50, we're happy to issue you with some kind of personalised limited edition invitation in crayon, glitter pen, and macaroni (spray-painted gold for that luxe look) for the low enterprise-only price of $500. [Topics] Suggested topics include but are not limited to: - Crowd Control Techniques and Panic Modeling - Information Warfare / Industrial Espionage - Malware (Viruses, Spam, Phishing, Botnets) - Cellular Networks (GSM,GPRS,CDMA,3G,4G) - Application Security, Testing, Fuzzing - Government Spy Networks / Surveillance - Nanotechnology / Quantum Computing - Access Control and Authentication - Wireless / Bluetooth / Infrared - Social Engineering / Trolling - Breaking EAL Certified Kit - Forensics / Antiforensics - Banking / ATMs / Carding - Exploitation Techniques - Layer 1/2/3 Nastiness - Reverse Engineering - Phreaking / VoIP - Virtualisation - Web Security - Lockpicking - Biometrics - Hypnosis - Crypto - Ohday - 23 There is no pre-determined talk length but we ask that speakers limit their presentation to an hour, including some question time. Kiwicon is a non-profit organisation, so generally funding is not available for travel and accommodation. However, we have a limited number of travel support packages available: 1 x NZ$1500 for a speaker from outside Australasia or the South Pacific 1 x NZ$750 for a speaker from Australia or the South Pacific 3 x NZ$250 for speakers from New Zealand These are available only to full length (>45min) speakers paying their own way. No speaking-in-a-corporate-capacity, no company logos on the slides and no industry weaseling. These stipends are for amateurs, crackpots, ecclesiasticals, students and other miserable doss-down-under-the-motorway-bridge-oh-my-goodness-two-cardboard-boxes-just-for-me? riff-raff. If you look too much like you should be hanging out between the pages of Men's Style magazine (and we know who you are), then we reserve the right to pick someone a trifle more threadbare. Organiser decision is final, no correspondence will be corresponded, and Sharrow has to think your existence does not constitute a putrefying abscess in the nostril of humanity. If you are a corporate sellout, however, a formal letter will be provided for employer leverage. Either way, unless you're a complete jackoff, people will try and buy you beer. To submit a presentation to Kiwicon2k8, send an email to cfp(a)kiwicon.org with the following information: Name or Handle: Country of Residence: Employer (if applicable): Presentation Title: Presentation Length: Presentation Synopsis: Brief Bio: Do Want Fat Cash: [Yes/No] ( If yes, pick one of the above support options, and explain how poor you are, and why you're worth spending our money on. Be creative. Poetry is acceptable? ) [CFP Submissions] Please submit your CFP by email to cfp(a)kiwicon.org, no later than 8:47pm NZST, Sunday 17th August 2008. There will be two rounds of selection, with the first half of the talks chosen in early August, so submit early for a better chance of acceptance. [Contacts & Further Information] Email us: kiwicon(a)kiwicon.org Check the site: http://www.kiwicon.org/ Drop by silc: silc.isig.org.nz:2706/kiwicon Join the list: kiwicon-subscribe(a)lists.isig.org.nz Greetz and thanks to all who helped make Kiwicon 2k7 the awesomeness it was, we'll see you fuckers again this year. Thick, meaty props to Pipes for stepping up and making 2k7 happen. We would miss you, but Sharrow's just as tall, and better looking. Sorry pal. -- The Kiwicon Crüe, 2k8 - Bogan, Metlstorm & Sharrow. \m/ [1] http://en.wikipedia.org/wiki/Ben_Hana

1 0

Dunedin Frequency 5735
by Dan Clark 08 Jul '08

08 Jul '08

Gidday Guys, anyone got anything new on 5735GHz in and around Dunedin CBD last 24 hours? Regards Dan Clark

10 11

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