- NZNOG - lists.nznog.org

TICSA and Lawful Interception
by ticsa＠police.govt.nz 01 Oct '17

01 Oct '17

Hi NZNOG The TICSA Registrar invites you to a Technical Discussion about Lawful Interception. There has been a lot of discussion about LI recently and we would like to clarify what it means to be Compliant. The aim of this meeting is to work through ‘the how’ and to answer any questions you may have. This is targeted at Network Engineers to whom PCAP, ASN.1 and ETSI 102.232-1 means something. Please register your interest by emailing off list, as space is limited (attendance by invitation only). Meeting will be held in Wellington on the 16th of October. Cheers Neil =============================================================== WARNING The information contained in this email message is intended for the addressee only and may contain privileged information. It may also be subject to the provisions of section 50 of the Policing Act 2008, which creates an offence to have unlawful possession of Police property. If you are not the intended recipient of this message or have received this message in error, you must not peruse, use, distribute or copy this message or any of its contents. Also note, the views expressed in this message may not necessarily reflect those of the New Zealand Police. If you have received this message in error, please email or telephone the sender immediately

1 0

KSK Rollover Postponed
by Save Vocea 28 Sep '17

28 Sep '17

Dear NZNOG community, A couple of weeks ago I posted ICANNs’ KSK rollover timelines in here. It was announced today that the plan to change the cryptographic key that helps protect the Domain Name System (DNS) is being postponed. The changing or "rolling" of the KSK Key was originally scheduled to occur on 11 October, but it is being delayed because some recently obtained data shows that a significant number of resolvers used by Internet Service Providers (ISPs) and Network Operators are not yet ready for the Key Rollover. The availability of this new data is due to a very recent DNS protocol feature that adds the ability for a resolver to report back to the root servers which keys it has configured. Full announcement is here: https://www.icann.org/news/announcement-2017-09-27-en Regards, Save Vocea ICANN staff in the region From: Save Vocea <save.vocea(a)icann.org> Date: Tuesday, September 12, 2017 at 4:53 PM To: NZNOG <nznog(a)list.waikato.ac.nz> Subject: KSK rollover timeline and how to check if your systems are ready Dear NZNOG list members, I’d appreciate if this is shared through your network /organizations and to check if your systems won’t be affected by the following change. The Internet Corporation for Assigned Names and Numbers (ICANN) is planning to roll, or change, the “top” pair of cryptographic keys used in the Domain Name System Security Extensions (DNSSEC) protocol, commonly known as the Root Zone KSK. This will be the first time the KSK has been changed since it was initially generated in 2010, and is considered an important security step, in much the same way that regularly changing passwords is considered a prudent practice by any Internet user. What does that mean? Rolling the KSK means generating a new cryptographic public and private key pair and distributing the new public component to parties who operate validating resolvers, including: Internet Service Providers; enterprise network administrators and other Domain Name System (DNS) resolver operators; DNS resolver software developers; system integrators; and hardware and software distributors who install or ship the root's "trust anchor." The KSK is used to cryptographically sign the Zone Signing Key (ZSK), which is used by the Root Zone Maintainer to DNSSEC-sign the root zone of the Internet's DNS. Why do you need to prepare? Currently, 25% of global Internet users, or 750 million people, use DNSSEC-validating resolvers that could be affected by the KSK rollover. If these validating resolvers do not have the new key when the KSK is rolled, end users relying on those resolvers will encounter errors and be unable to access the Internet. How to know if your systems are up-to-date? ICANN is offering a test bed for operators or any interested parties to confirm that their systems handle the automated update process correctly. Check to make sure your systems are ready by visiting: http://go.icann.org/KSKtest. What is the timeline for this process? October 27, 2016: KSK rollover process begins as the new KSK is generated. July 11, 2017: Publication of new KSK in DNS. September 19, 2017: Size increase for DNSKEY response from root name servers. October 11, 2017: New KSK begins to sign the root zone key set (the actual rollover event). January 11, 2018: Revocation of old KSK. March 22, 2018: Last day the old KSK appears in the root zone. August 2018: Old key is deleted from equipment in both ICANN Key Management Facilities. More information about the root zone KSK rollover is available here: https://www.icann.org/resources/pages/ksk-rollover. Thank you, Save vocea VP, Global Stakeholder Engagement, Oceania ICANN

2 1

NZNOG 2018 Updates
by Dave Mill 24 Sep '17

24 Sep '17

Hi all As promised here is the list of workshops/tutorials that we have organised so far. These aren't definite yet but are very likely to happen. *Wednesday tutorials:* -Network Security Tutorial (run by APNIC) -Facebook Network Automation Hack event (run by Facebook, will be similar to https://netengcodehack2017.splashthat.com/%29 ) *Workshop (roughly Monday 9am to Wednesday 12pm):* -Mikrotik MTCINE training - Outline here https://mikrotik.com/download/pdf/MTCINE_Outline.pdf Our CFP is still open. Details here - http://www.nznog.org/nznog18/call-for-papers-2018 . If anyone else wants to help Richard Nelson and myself put together the programme for Thur/Fri please get in contact. So far we've received details on some really interesting talks. If you want to sponsor NZNOG please reach out also. Cheers Dave

1 0

Datacom having network problems?
by Mauricio Freitas 23 Sep '17

23 Sep '17

Does anyone have a network contact at Datacom please? I can't get to datacom.co.nz (direct) from my NZ connection, and can't get to Geekzone via Cloudflare either (CF returns a timeout trying to reach origin). However if I fire a VPN to Sydney both datacom.co.nz and Geekzone work fine. Called datacentre and ops guys have no idea what's going on. Seems that traffic to NZ is being impacted but not to overseas. Cheers Mauricio Freitas https://about.me/freitasm

1 1

NZNOG 2018 updates
by Dave Mill 14 Sep '17

14 Sep '17

Hi all I wanted to give some more details on our plans for the conference next year. On Wednesday Facebook are looking at holding a Network Automation Hack event as part of NZNOG. This should be a really awesome session. It will be similar to this - https://netengcodehack2017.splashthat.com/%29 . Whilst this isn't completely locked in yet it has approval internally at Facebook and looks set to happen. I'd suggest if this interests you then plan to be at NZNOG from Wed - Fri. Be warned, seats will be limited. The other event I wanted to announce I unfortunately still can't. I've been chasing people pretty hard on it and I still don't know that it will definitely happen :( I will update when I know more. Cheers Dave

1 0

Dialup over Ethernet
by Ewen McNeill 13 Sep '17

13 Sep '17

A client had a (business) customer switch over to UFB and needed assistance reconfiguring the (Mikrotik) router being attached to the ONT -- it turned out whoever first set up the Mikrotik (sensibly) assumed it'd be seeing IP packets over VLAN 10, but actually the ISP required IP packets over PPPoE over VLAN 10 in order for it to work. Looking around it appears this client's customer's ISP isn't the only one that is requiring PPPoE over VLAN tagging over Ethernet for their UFB connections. Is there a reason other than "let's make everything look like 1990s dialup so it works with our legacy equipment" for the bit/CPE CPU overhead of PPPoE on UFB, including imposing the lowered usable MTU and PMTU discovery headaches on the end user? The only one that really comes to mind is "user/password authentication" (rather than needing to collect CPE MAC addresses which seems to happen with, eg, Vodafone cable/FibreX). But it's not clear to me why, eg, 802.1X isn't used for the user/password authentication in that case; or DHCP with some extension to pass a "secret" identifier. 20-bytes-per-packet-forever seems a large overhead to pay for user/password authentication at CPE power on.... (Maybe in the beginning there's "lack of CPE support" -- but we're a few years into the UFB rollout, and lots of ISPs seem to be supplying their own ISP-badged CPEs anyway, which could presumably implement whatever was needed.) Ewen

10 16

AirNZ SPF Issues
by Pieter De Wit 11 Sep '17

11 Sep '17

Hey NZNOG’rs, I know that this is not “nice to do” but I have tried the contact centre - the issue is logged but I doubt it will get to the right people ? AirNZ currently has 2 SPF entries and this is causing emails to fail: dig TXT airnz.co.nz | grep spf1 airnz.co.nz. 21301 IN TXT "v=spf1 a ..." airnz.co.nz. 21301 IN TXT "v=spf1 …" Please fix :) I have error logs going back to the 8th of Aug, if that helps ? I don’t know what other domains this was done on. Cheers, Pieter

2 1

KSK rollover timeline and how to check if your systems are ready
by Save Vocea 11 Sep '17

11 Sep '17

Dear NZNOG list members, I’d appreciate if this is shared through your network /organizations and to check if your systems won’t be affected by the following change. The Internet Corporation for Assigned Names and Numbers (ICANN) is planning to roll, or change, the “top” pair of cryptographic keys used in the Domain Name System Security Extensions (DNSSEC) protocol, commonly known as the Root Zone KSK. This will be the first time the KSK has been changed since it was initially generated in 2010, and is considered an important security step, in much the same way that regularly changing passwords is considered a prudent practice by any Internet user. What does that mean? Rolling the KSK means generating a new cryptographic public and private key pair and distributing the new public component to parties who operate validating resolvers, including: Internet Service Providers; enterprise network administrators and other Domain Name System (DNS) resolver operators; DNS resolver software developers; system integrators; and hardware and software distributors who install or ship the root's "trust anchor." The KSK is used to cryptographically sign the Zone Signing Key (ZSK), which is used by the Root Zone Maintainer to DNSSEC-sign the root zone of the Internet's DNS. Why do you need to prepare? Currently, 25% of global Internet users, or 750 million people, use DNSSEC-validating resolvers that could be affected by the KSK rollover. If these validating resolvers do not have the new key when the KSK is rolled, end users relying on those resolvers will encounter errors and be unable to access the Internet. How to know if your systems are up-to-date? ICANN is offering a test bed for operators or any interested parties to confirm that their systems handle the automated update process correctly. Check to make sure your systems are ready by visiting: http://go.icann.org/KSKtest. What is the timeline for this process? October 27, 2016: KSK rollover process begins as the new KSK is generated. July 11, 2017: Publication of new KSK in DNS. September 19, 2017: Size increase for DNSKEY response from root name servers. October 11, 2017: New KSK begins to sign the root zone key set (the actual rollover event). January 11, 2018: Revocation of old KSK. March 22, 2018: Last day the old KSK appears in the root zone. August 2018: Old key is deleted from equipment in both ICANN Key Management Facilities. More information about the root zone KSK rollover is available here: https://www.icann.org/resources/pages/ksk-rollover. Thank you, Save vocea VP, Global Stakeholder Engagement, Oceania ICANN

1 0

New Zealand Internet Research Forum 2017 - Registrations open
by Nicole Skews-Poole 11 Sep '17

11 Sep '17

Kia ora, Registrations for this year's New Zealand Internet Research Forum are open. The Forum will be held on 8 November, the day before NetHui 2017 <https://2017.nethui.nz/> - as part of the NetHui umbrella. *You can register for free by selecting the first event here: https://nethui-2017.lilregie.com/step1 <https://nethui-2017.lilregie.com/step1>* you can also register there for NetHui 2017 should you want to come along! The programme for this year will be finalised soon, and in the meantime you can check out last year's programme <https://internetnz.nz/internet-research-forum-2016-programme> for an idea of what goes on at the NZIRF. Please consider sharing this with your networks. I look forward to seeing you there! *Ngā mihi nui,* *Nicole Skews-Poole* NZIRF Organiser InternetNZ Mobile: +64 27 323 8914 Email: nicole(a)internetnz.net.nz A better world through a better Internet

1 0

TICSA and lawful intercept
by Dave Mill 06 Sep '17

06 Sep '17

Hi all So, probably a bit a touchy subject this one but here goes.. If you are a network operator and you have more than 4000 customers in my understanding you need to have full interceptions capabilities. (I'm not a lawyer, etc, etc) This is more than just being 'interception ready'. http://www.police.govt.nz/advice/businesses-and-organisations/ticsa/interce… This will mean having a mediation system and being able to produce intercept data in the ETSI standard - again, as far as I know. What are companies/organisations out there doing about this? Is there a nice open source solution out there for this? (I haven't found one yet) Are people putting their heads in the sand and praying they never get served a warrant? Is everyone just shelling out hundreds of thousands of dollars on a vendor LI solutions? What network kit are people integrating with LI in NZ? And note, the last paragraph on the URL I linked above reads: "Can I share interception capability resources? Network operators may co-ordinate, share or contract for services (equipment or staff) in order to meet the interception capability requirements in the Act. However, it remains the responsibility of the network operator to ensure that any such arrangement does not affect any obligations that apply under the Act. Before entering into any such arrangement a network operator must notify the Director of the GCSB." Replies on or off list welcomed. Cheers Dave (AS17705)

9 20