- NZNOG - lists.nznog.org

Wassenaar Agreement and strong crypto exports
by neil gardner 29 Mar '05

29 Mar '05

Hi guys - this isn't strictly operational but I think it's an appropriate audience. As per the subject, I'm after current info about experiences with MFAT over the export of strong crypto, either as software, or embedded in hardware. The online references I can find (Some listed below) are reasonably old and I was hoping there had been some change. (I quote from a 1997 letter from Sec Foreign affairs and trade - Mr Borrie) "This sort of product (encrpytion software) is considered a "dual use" good in terms of the New Zealand Export Controls which means that they are able to be adapted for military, terrorist or criminal use" (I could adapt a plastic spoon for criminal use - but that's beside the point!) Source : http://www.cs.auckland.ac.nz/~pgut001/policy/mfat_2r.html I looked at the MFAT site and they still list encryption software on their "New Zealand Strategic Goods List Index of Controlled Goods" page. Source : http://www.mfat.govt.nz/foreign/dis/nzsgl/pages/laste.html So I guess my question is does anyone know if they have relaxed their approach to 3DES (or even AES-xxx) given that these 'technologies' are freely available internationally, and that 128bit encryption has been effectively opened way up by international adoption in browsers? I'm happy to summarise if there's a bit of feedback. Cheers - Neil Gardner. NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

1 0

[enum-sg] Request to be invited to a workshop on ENUM policy for New Zealand (Draft)
by Peter Macaulay 29 Mar '05

29 Mar '05

In Auckland, on April 13 2005, at SkyCity, InternetNZ is hosting a one day workshop on ENUM policy for New Zealand. Chaired by Tony Holmes, a globally known speaker on ENUM issues, the workshop is for all those who will be involved in decisions about implementation of ENUM in New Zealand, or who have a commercial or technical interest. InternetNZ is in the process of developing some components for an ENUM trial which will be shown at a later workshop. More details will be published in the next few days, and will be echoed on the InternetNZ website. Places are limited. Please respond to office(a)internetnz.net.nz so your request can be considered. DRAFT AGENDA: Desired Outcome: A foundation and way forward for trialling ENUM in New Zealand 1. INTRODUCTIONS 2. AIM OF THE WORKSHOP To determine: - Why should there be a trial - what questions are we setting out to answer? - What are the objectives of the trial? - What needs to happen before a trial can take place? - Who needs to be involved in a trial? - Who will administer the trial? - What are the deliverables of the trial? 3. THE DELEGATION OF 4.6.e164.arpa - Tony Holmes: UK Experience 4. EXPERIENCE OF OTHER TRIALS - Tony Holmes: Experience of UK and other jurisdictions 5. MAXIMISING BENEFITS FROM STANDARDS - Tony Holmes: Overview of the role of standards to be applied in a trial 6. UNIVERSAL COMMUNICATIONS IDENTIFIERS (UCI) and PERSONAL USER AGENTS (PUA) - Micheal Sutton. An Overview of the assignment 7. SOME ADDITIONAL PERSPECTIVES - Regulatory perspectives - Variations on the use of .arpa for ENUM that are occurring in the US and the UK 8. THE WAY FORWARD FOR NZ - issues - what needs to be done - who needs to be involved - actions - timeframe 9. Concluding Summation -- *Peter Macaulay* /Executive Director/ *InternetNZ */Direct +64 4 495 2113 Skype petermacaulay Mobile +64 21 488 485 / _______________________________________________ enum-sg mailing list enum-sg(a)internetnz.net.nz http://farsight.internetnz.net.nz/mailman/listinfo/enum-sg

1 0

HEADS UP - Upcoming webcast
by Richard Naylor 28 Mar '05

28 Mar '05

Evening All, This is a slightly late-ish advisory that R2.co.nz will be webcasting the NZ Secondary Schools Rowing Championships from Lake Kaipiro on 8 and 9 April. The webcast servers are located at both APE and WIX and network operators may experience a frenzy of teenagers wanting to watch their team win. Or hassling their Help Desks that nothing works. Operators not currently peering at APE or WIX should contact CityLink if they would like assistance with peering. During the webcast, we will be attempting to do the event live, as well as uploading a recorded version of each race, so that folks can relive those few moments of glory. This will add to the potential traffic experienced on the day(s). Thank you for your co-operation. Richard aka richard.naylor(a)r2.co.nz

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 22 Mar '05

22 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2128] Routing updates for APE Route Servers (fwd) - Date: Wed, 23 Mar 2005 16:49:23 +1200 (NZST) - Msg-Id: <Pine.LNX.4.58.0503231649060.23389(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 202.6.5.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 203.97.42.0/24^24-29, 203.167.219.56/29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 210.55.155.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.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: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050323 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 22 Mar '05

22 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. 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. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2129] Routing updates for WIX Route Servers (fwd) - Date: Wed, 23 Mar 2005 16:48:32 +1200 (NZST) - Msg-Id: <Pine.LNX.4.58.0503231648120.23389(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9889 descr: advertised to AS9439 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9889 descr: advertised to AS9439 by Maxnet - AS9889 members: 202.6.5.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 203.97.42.0/24^24-29, 203.167.219.56/29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 210.55.155.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.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: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050323 source: NZRR

1 0

telecom planning to break VoIP over its network?
by Joe Abley 21 Mar '05

21 Mar '05

http://www.pbs.org/cringely/pulpit/pulpit20050317.html "And there are other dirty tricks available to broadband ISPs. Telecom New Zealand, for example, is reportedly planning to alter TCP packet interleaving to discourage VoIP. By bunching all voice packets in the first half of each second, half a second of dead air would be added to every conversation, changing latency in a way that would drive grandmothers everywhere back to their old phone companies. This is because phone conversations happen effectively in real time and so are very sensitive to problems of latency. Where one-way video and audio can use buffering to overcome almost any interleaving issue, it is a deal-breaker for voice."

18 22

SANOG 6 in Thumpu, Bhutan, 16-23 July 2005
by Joe Abley 21 Mar '05

21 Mar '05

SANOG VI 16-23 July, 2005 Thimphu, Bhutan SANOG VI Program and Fellowship Announcement SANOG VI program and agenda are now published on <http://www.sanog.org/sanog6/>. SANOG VI is being held in Thimphu, Bhutan from 16-23 July, 2005. You can refer to <www.sanog.org/sanog6/> for details. Program and Agenda SANOG VI program incorporates the following: Three hands-on workshops (16-20 July 2005) - IP Services Workshop - ISP Routing and BGP Multihoming Workshop - ISP and NSP Security Workshop, Tutorials (21-22 July 2005) - BGP and High Availability Routing Workshop by Juniper - VOIP and SIP Deployment - ISP and Network Security - IP Networks and Wireless Architecture - Netflow / Flowtools - DNS and DNSSec deployment Birds-of-a-Feather (22 July 2005) - Regional Updates BoF - APNIC BoF Full Day Conference Program (23 July 2005) - Routing and Internet Operations - Network Architecture and - Application Deployment Additional Programs: (21-23 July 2005) - APNIC Regional policy update - APNIC hostmaster Consultation SANOG VI Fellowship Annoucement SANOG VI is also pleased to annouce the fellowship program with support of the Internet Society and Network Startup Resource Center (NSRC). SANOG VI fellows will received a maximum of USD 500 towards air fare and local accomodation during the event. You can find more information about the fellowship program from the SANOG Fellowship Site at <http://www.sanog.org/fellowship/>. SANOG VI Call for Papers SANOG VI Call for papers for the conference is available online at <http://www.sanog.org/sanog6/cfp.htm>. Everyone is Welcome We expect a huge turn out from the region at this SANOG meeting owing to the popularity at previous meets. With more involvement of APNIC in the content of overall program, We hope you would be able to make it to this meeting. The meeting is open to everyone from the operational community, and thus anyone who wants to find out more about Internet operations in South Asia is welcome. You can register for SANOG by sending in the form available at <www.sanog.org/sanog6/> or using the online registration system. Registrations from inside Bhutan can be paid by cheques.

1 0

RE: [nznog] telecom planning to break VoIP over its network?
by Philip D'Ath 20 Mar '05

20 Mar '05

Perhaps you missed the billion dollar announcement they made sometime ago how they are building a new all IP network, and are phasing out most of the old PSTN exchanges. From memory, something like 700 of them are scheduled to be decommissioned. -----Original Message----- Perhaps I phrased that a little off, what I was meaning to insinuate was that they wouldn't be ditching the ole PSTN anytime soon. But hey *shrug* there are alot of varying ideas on that aswell. -Richard _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

OT: WTD: Cisco expert for short job in Sydney, .au.
by Zach Bagnall 20 Mar '05

20 Mar '05

Hey all. We're sending a router (Cisco 831) to a datacentre in Sydney, and need someone to install on site, establish connectivity, and get an IPSec tunnel up. The router has been configured for NAT and IPSec here in NZ, but obviously not tested in the live environment. Probably an hour or so to get connectivity up, and a few more to liase with the techs on the other end of the VPN in order establish that connection. Hoping to get this done in the week following Easter. Any (off-list) personal recommendations appreciated. Zach.

4 3

RE: [nznog] telecom planning to break VoIP over its network?
by Olof Olsson 20 Mar '05

20 Mar '05

All, I believe the only "things" that Telecom have done to-date are: 1. To change the ADSL modulation speed to each subscribers "plan speed" + ATM overhead. For example, the 256/128 kbps plan has an ADSL modulation speed of 320/160 kbps (downstream/upstream). 2. Always have ADSL interleaving on, with a relatively long interleaving delay. Interleaving is used between the ADSL modem and the DSLAM to improve error correction performance against burst errors. The above means: *** An interleaving delay of approximately 28 ms is introduced *** A serialisation delay of approximately 3-50 ms is introduced (64 - 1024 byte packets). In other words, the total one-way latency is approximately 36 - 83 ms depending on packet size. Jitter will of course increase as latency increses. (Packets arriving behind large packets etc.) Which is bad for VoIP. The question is: did Telecom do this to make VoIPoUBS harder to implement? (The latency and jitter could be significantly reduced by lowering the interleaving delay and by not limiting ADSL modulation rates. Interleaving is not needed if the subscribers local loop is of a reasonable quality.) --Olof

1 0