- NZNOG - lists.nznog.org

Government changes 2.3 GHz rules (and other bands)
by Ian McDonald 22 Nov '06

22 Nov '06

>From http://www.beehive.govt.nz/ViewDocument.aspx?DocumentID=27807 Government promotes wireless broadband investment The government's decision to reallocate spectrum for wireless broadband is another essential step in providing New Zealanders with better, more competitive access to broadband, says Communications Minister David Cunliffe. The decision will see spectrum in the 2.3 GHz range – suitable for such emerging wireless broadband applications as WiMAX – put up for auction in early 2007. While current right-holders do not have to give up their rights before they expire in 2010, some may choose to do so. It is expected that some of the 2.3 GHz spectrum could be available for development immediately after the auction, enabling early development of new broadband wireless services. Other decisions include making a 16MHz block as a "managed park" suitable for local and regional broadband operations, and developing policies to facilitate future use of other spectrum suitable for broadband wireless access (BWA). Along with the other recent measures to develop a vibrant, competitive ICT sector, the availability of additional broadband wireless spectrum will help unlock the potential of these new technologies, and aid New Zealand's economic transformation into an innovative and creative knowledge-based economy. "This decision reflects the fairest and most effective way of giving new and existing wireless broadband services providers the opportunity to develop this very important spectrum for broadband in New Zealand," Mr Cunliffe said. "BWA technology for this band is only just starting to become available. It is critical that we create the right conditions for its future deployment by giving a wide range of players the opportunity and the certainty they need to make a long-term investment." "How we run the process and allocate the rights will obviously be critical. A spectrum cap of 30 MHz per operator – which generally accepted industry standards indicate would be ample – would ensure at least three separate lots of spectrum will be on offer. Successful purchasers will be required to implement services within a specified period." This announcement reaffirms a 2004 government decision that existing rights would not be renewed when they expire in 2010. It follows public consultation in which industry feedback showed strong support for immediate reallocation of this spectrum. Background information: Summary of decisions Allocation of the 2.3 GHz spectrum Up to eight 10 MHz-wide management rights in the 2.3 GHz band will be reallocated by auction as soon as is practicable. A 16 MHz block will be made available as a managed spectrum park from 2010, or earlier if available. The Ministry of Economic Development expects to conduct the auction in the first quarter of 2007, with the following conditions: * a spectrum cap of 30 MHz per operator will apply for two years from the date of allocation; and * right-holders will be required to implement services within a specified period or face revocation. Subject to discussions with right-holders for early relinquishment of their current 2.3 GHz spectrum rights, some of the auctioned spectrum rights will be available for use immediately after the auction, while a smaller amount may not become available until current rights expire in 2010. Transition plan for 2.5 GHz spectrum Spectrum at 2.5 GHz is suitable for BWA technology in a manner equivalent to the 2.3 GHz band, but the band is currently used for television outside broadcasting (e.g. linking back to the studio). The ministry will develop and implement a transition plan, in consultation with stakeholders, to make this band available for future BWA allocation, once technical parameters have been determined at the World Radio Conference in 2007. New General User Licences at 5.4 GHz and 60 GHz The ministry intends to create a general user licence ('public park' licence) to facilitate the deployment of BWA services at 5.4 GHz by June 2007, subject to suitable protection for existing radar applications in the band. A general user licence will also be issued for BWA services at 60 GHz by June 2007, with conditions that balance technical neutrality with spectrum utility and efficiency. 70, 80, 90 GHz and other bands There are at present no policies for licensing of the 70, 80 and 90 GHz bands, but interest in using these bands for BWA is becoming evident. In anticipation of future demand, the ministry is developing policy proposals for these bands. There is some interest in other bands, including projected changes to the existing 921 to 929 MHz general user licence and the 10.5 GHz bands. Policy and technical work for these bands is continuing. -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand

1 0

NZNOG 2007: CFP: Network Systems Administration MiniConf
by Ewen McNeill 22 Nov '06

22 Nov '06

Call for Presentations for NZNOG 2007: Network Systems Administration Mini-Conference In conjunction with the NZNOG 2007 conference (http://www.nznog.org/) we will be holding a network systems administration mini-conference on the tutorial day, Wednesday 2007-01-31. The NZNOG 2007 conference will be held in Palmerston North between 2007-01-31 and 2007-02-02. Registration at the NZNOG 2007 conference is a mandatory prerequisite for attendence at the mini-conference; we expect there will be no additional charge. The mini-conference's focus is on "Layer 7" issues to do with network and ISP operations, including providing customer services (email, DNS, etc) and provisioning and management topics. We are now seeking proposals for presentations at the mini-conference. We have openings for: - 50-60 minute full presentations - 25-30 minute half presentations - 5-10 minute "lightning talks" Presentations are expected to be directed at a technical audience, and focused on a system administration area related to network or ISP operations. Some possible topics: - Email servers and spam filtering techniques - DNS servers, registry systems - server security and best sysadmin practices in an internet provider environment - VoIP servers - network management / monitoring tools - RADIUS/TACACS - Netflow, routing, and traffic analysis tools - server tuning for high performance networking - provisioning tools - honeypots and other security techniques - network based storage - high availability and disaster recovery for network services - virtual machine technology for network services - *nix based routing and fire-walling - tools you need that you may not know about We are happy to discuss the suitability of other topics with intending presenters. Timeline: - proposals due by 2006-12-04 - selection advised by 2006-12-11 - draft program published by 2006-12-18 - presentations 2007-01-31 Please send all proposals and questions to <talks(a)nznog.miniconf.org> Simon Lyall and Ewen McNeill, Conveeners

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 21 Nov '06

21 Nov '06

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. --- PREVIOUS OBJECT: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS23754 import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS23754 import: from AS24385 accept ANY AND NOT fltr-bogons export: to AS24385 announce AS23754 import: from AS7657 accept {0.0.0.0/0} export: to AS7657 announce AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050801 source: NZRR REPLACED BY: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: WIX peering at '202.7.0.32' descr: see Citylink RT job #7338 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS23754 import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS23754 import: from AS24385 accept ANY AND NOT fltr-bogons export: to AS24385 announce AS23754 import: from AS7657 accept {0.0.0.0/0} export: to AS7657 announce AS23754 import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061122 source: NZRR --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS23754 descr: advertised to AS9439 by CityLink - AS23754 members: 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 202.7.6.0/23^23-29, 97.64.46.0/24^24-29, 198.32.71.0/24^24-29, 202.7.5.0/24^24-29, 203.118.144.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: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061116 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS23754 descr: Route set advertised to AS9439 by Cafenet-Free - AS23754 members: 198.48.3.192/26^26-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)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061122 source: NZRR

1 0

Re: [nznog] [Fwd: Re: [Fwd: [Computer-support] Greylisting - one day after]
by Russell Fulton 15 Nov '06

15 Nov '06

> > -------- Original Message -------- > Subject: Re: [nznog] [Fwd: [Computer-support] > Greylisting - one day after] > Date: Thu, 16 Nov 2006 14:08:46 +1300 > From: Jasper Bryant-Greene <jasper(a)albumltd.co.nz> > Organisation: Album Limited > To: Richard <richard(a)alternativeuniverse.net> > CC: Russell Fulton <r.fulton(a)auckland.ac.nz>, > nznog(a)list.waikato.ac.nz > References: <2.1.1-1800921-393-A-OEWW(a)222.154.242.106> > > > > Question around this - we are currently looking at > implementing it, but > we have three mail servers behind a load balancer. The software we're > looking at is postgrey (as we use Postfix), but it uses BDB database > files... > > Which means each server has an individual greylisting > database, and mail > could potentially (worst case) be bounced three times before getting > through. Has anyone solved this problem already? With BDB database files you really don't have a lot (any?) options. You could put the file on a NFS share and let all 3 servers use it, but locking issues and overall BDB speed would probably impact your performance greatly. The best solution in this case would be to bring a new server that will run a real database (MySQL, Oracle). If you use a greylisting package that supports these databases (gld does), you can have all servers point to this server and use one central greylisting database. Of course, this way you have a single point of failure (while gld will allow e-mails to flow if the database is not available, you loose greylisting, of course). We at the moment have local MySQL databases on each server. This means that the greylisting delay could be longer, but as we don't have real load balancer but use DNS only, so far this hasn't been the case. As far as I can see, actually, remote MTAs always came back to exactly the same server they were originally greylisted on, probably due to DNS caching on their side. Bojan

2 1

Notification of NZRR Database changes
by NZRR Database Notifications 15 Nov '06

15 Nov '06

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. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS23754 descr: advertised to AS9439 by CityLink - AS23754 members: 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 198.32.71.0/24^24-29, 203.118.144.0/24^24-29, 202.7.4.32/28^28-29, 202.7.7.88/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)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050926 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS23754 descr: advertised to AS9439 by CityLink - AS23754 members: 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 202.7.6.0/23^23-29, 97.64.46.0/24^24-29, 198.32.71.0/24^24-29, 202.7.5.0/24^24-29, 203.118.144.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: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061116 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 15 Nov '06

15 Nov '06

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. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS23754 descr: advertised to AS9560 by CityLink - AS23754 members: 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 202.7.6.0/23^23-29, 198.32.71.0/24^24-29, 202.7.5.0/24^24-29, 203.118.144.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: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050624 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS23754 descr: advertised to AS9560 by CityLink - AS23754 members: 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 202.7.6.0/23^23-29, 97.64.46.0/24^24-29, 198.32.71.0/24^24-29, 202.7.5.0/24^24-29, 203.118.144.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: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061116 source: NZRR

1 0

[Fwd: [Computer-support] Greylisting - one day after]
by Russell Fulton 15 Nov '06

15 Nov '06

Hi Folks, This might be of interest to NZNOG members -- we have just implemented grey listing for some addresses and the results have been dramatic to say the least... Russell -------- Original Message -------- Subject: [Computer-support] Greylisting - one day after Date: Thu, 16 Nov 2006 10:50:26 +1300 From: Bojan Zdrnja <b.zdrnja(a)auckland.ac.nz> To: Computer Support <computer-support(a)list.auckland.ac.nz> Hi All, Yesterday at 12:00 (mid day) I enabled greylisting on our e-mail cluster. At the moment we are greylisting only machines that don't have reverse DNS entries, or match one of our predefined name regular expressions (these are matching on modem/dialup/cable/adsl machines). The results of this has been amazing - we are seeing a dramatic decrease in processed spam (almost 10 times!). I'm hoping that you are seeing effects of this in your mailboxes as well - there should be overall less spam (marked and unmarked). I'm attaching two graphs that are showing this. The first graph (total-messages.PNG) shows total messages received after I turned on greylising. Green are legitimate messages, blue is spam, red are infected messages. The second graph (CPU-groucho.PNG) shows CPU utilization on groucho (smtpa - the first SMTP machine). For some reason spammers like to hit this machine the most so you can see last 7 days. Now, this works great at the moment but spammers will adapt and improve their software. My wild guess is that this will help for maybe 6 months to a year, but it will definitely give us some time to prepare for future spam waves. Bojan

2 1

Re: [nznog] [Fwd: [Computer-support] Greylisting - one day after]
by Mark Seward 15 Nov '06

15 Nov '06

On 11/16/06, Daniel <daniel(a)fx.net.nz> wrote: > > Which means each server has an individual greylisting database, and mail > > could potentially (worst case) be bounced three times before getting > > through. Has anyone solved this problem already? .. > http://sqlgrey.sourceforge.net/ We have postfix+sqlgrey deployed across several mail hosts. It would be nice to have a replicated postgres behind it but otherwise it does the job very nicely. Also seen here: Similar dramatic reduction in inbound crap and recent increase in abuse of relays behind legit whitelisted hosts. Cheers, Mark.

1 0

Inbound mail filtering at Ihug
by Martin Kealey 14 Nov '06

14 Nov '06

Hi folks, Just a heads-up: We've recently tightened up the reverse & forward DNS tests applied by our inbound SMTP servers (zuul.ihug.co.nz); sending hosts with mismatched DNS entries are now likely to have all messages rejected. If you need an exception to this rule please let us know (presumably by phone...) -Martin Kealey (Systems Engineer, ihüg)

3 2

Re: [nznog] Inbound mail filtering at Ihug
by Martin Kealey 14 Nov '06

14 Nov '06

Ok, before I get a complete deluge of replies... Personally I agree that dropping connections without explanation is, to say the least, unhelpful. I only started here on Monday so some things might take longer than you'd expect, but I'm already looking into this and other outstanding email issues. -Martin

1 0