February 2018 - Test - lists.nanog.org

RIPE NCC Global IPv6 Deployment Survey
by Massimiliano Stucchi 21 Mar '18

21 Mar '18

Dear colleagues, The RIPE NCC would like to invite you to participate in its Global IPv6 Survey 2018. The goal of the survey is to get an overview IPv6 deployment across the world, and to assess how this is seen from the perspective of ISPs and Enterprise users. The 2018 survey is a follow up to similar surveys run between 2008 and 2013, and will serve as a comparison with the data acquired back then. You can find the survey at the following address: https://www.surveymonkey.com/r/GlobalIPv6survey2018 Responses can be submitted until 31 March 2018. We will then collect the data with the aim of presenting the preliminary results during the upcoming RIPE 76 meeting in Marseille. If you have any question about the survey, please feel free to email us at: ipv6survey2018(a)ripe.net. Thank you very much in advance for your participation! -- Massimiliano Stucchi IPv6 Programme Manager RIPE NCC mstucchi(a)ripe.net Follow us on Twitter for the fastest and latest RIPE NCC Training news! @TrainingRIPENCC

2 1

IPv4 smaller than /24 leasing?
by Filip Hruska 18 Mar '18

18 Mar '18

Hi, I have stumbled upon this site [1] which seems to offer /27 IPv4 leasing. They also claim "All of our IPv4 address space can be used on any network in any location." I thought that the smallest prefix size one could get routed globally is /24? So how does this work? [1] http://www.forked.net/ip-address-leasing/ Thanks -- Filip Hruska Linux System Administrator

16 42

TWC/Charter/Spectrum contact off-list ? (Reverse DNS issue)
by Brandon Applegate 17 Mar '18

17 Mar '18

Hello, I had success with this issue about 2 years ago when some TWC folks contacted me. I don’t know if those folks are still with TWC/Charter here in the end of 2017 - hence posting on NANOG. The tl;dr is IPv6 reverse DNS issues. It was broken, got fixed, and seems to have broken again recently. Thanks in advance. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible."

2 2

New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks
by Barry Greene 02 Mar '18

02 Mar '18

Hello Fellow NANOGer, If you have not already seen it, experiences it, or read about it, working to head off another reflection DOS vector. This time it is memcached on port 11211 UDP & TCP. There are active exploits using these ports. Reflection attacks and the memcached is not new. We know how reflection attacks work (send a spoofed packet to a device and have it reflected back (yes please deploy source address validation and BCP 38). Operators are asked to review their networks and consider updating their Exploitable Port Filters (Infrastructure ACLs) to track or block UDP/TCP port 11211 for all ingress and egress traffic. If you do not know about iACLs or Explorable port filters, you can use this white paper details and examples from peers on Exploitable Port Filters: http://www.senki.org/operators-security-toolkit/filtering-exploitable-ports… Enterprises are also asked to update their iACLs, Exploitable Port Filters, and Firewalls to track or block UDP/TCP port 11211 for all ingress and egress traffic. Deploying these filters will help protect your network, your organization, your customers, and the Internet. Ping me 1:1 if you have questions. Sincerely, -- Barry Raveendran Greene Security Geek helping with OPSEC Trust Mobile: +1 408 218 4669 E-mail: bgreene(a)senki.org ---------------------------- Resources on memcached Exploit (to evaluate your risk): More information about this attack vector can be found at the following: • JPCERT – memcached のアクセス制御に関する注意喚起 (JPCERT-AT-2018-0009) http://www.jpcert.or.jp/at/2018/at180009.html • Qrator Labs: The memcached amplification attacks reaching 500 Gbps https://medium.com/@qratorlabs/the-memcached-amplification-attack-reaching-… • Arbor Networks: memcached Reflection/Amplification Description and DDoS Attack Mitigation Recommendations https://www.arbornetworks.com/blog/asert/memcached-reflection-amplification… • Cloudflare: Memcrashed – Major amplification attacks from UDP port 11211 https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-por… • Link11: New High-Volume Vector: Memcached Reflection Amplification Attacks https://www.link11.com/en/blog/new-high-volume-vector-memcached-reflection-… • Blackhat Talk: The New Page of Injections Book: Memcached Injections by Ivan Novikov https://www.blackhat.com/docs/us-14/materials/us-14-Novikov-The-New-Page-Of… • Memcache Exploit http://niiconsulting.com/checkmate/2013/05/memcache-exploit/

29 42

Removing the four stale TAL from the APNIC RPKI validation set.
by George Michaelson 28 Feb '18

28 Feb '18

Updating RPKI trust anchor configuration ------------------------------------------------------- APNIC has completed the process of transitioning from its previous Resource Public Key Infrastructure (RPKI) trust anchor arrangement to a new single trust anchor configuration. Each RIR will publish an 'all resources' global trust anchor, under which its own regional resources (IP addresses and ASNs) will be certified. APNICs trust anchor is one of the previous five, which has been retained as the sole trust anchor over all APNIC resource certificate products. If you are using relying-party software, such as the Dragon Research Labs RPKI Toolkit, RPSTIR or the RIPE NCC’s RPKI Validator, you are advised to update your software’s configuration to use only the current APNIC trust anchor, rather than the set of five APNIC trust anchors that were previously in use. The update is to remove four of the five: One has been retained as the current live Trust Anchor. Note: this update is not critical. However, if it is not done, the software will log or report warnings about being unable to retrieve the trust anchors that are no longer being used. All resources now validate under the single active trust anchor and no orphan products are valid under the other prior trust anchors. The current APNIC TAL is as follows: ------ rsync://rpki.apnic.net/repository/apnic-rpki-root-iana-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx9RWSL61YAAYumEiU8z8 qH2ETVIL01ilxZlzIL9JYSORMN5Cmtf8V2JblIealSqgOTGjvSjEsiV73s67zYQI 7C/iSOb96uf3/s86NqbxDiFQGN8qG7RNcdgVuUlAidl8WxvLNI8VhqbAB5uSg/Mr LeSOvXRja041VptAxIhcGzDMvlAJRwkrYK/Mo8P4E2rSQgwqCgae0ebY1CsJ3Cjf i67C1nw7oXqJJovvXJ4apGmEv8az23OLC6Ki54Ul/E6xk227BFttqFV3YMtKx42H cCcDVZZy01n7JjzvO8ccaXmHIgR7utnqhBRNNq5Xc5ZhbkrUsNtiJmrZzVlgU6Ou 0wIDAQAB ------ Configuring Relying Party Software ----------------------------------------------- RIPE NCC RPKI Validator: If you upgrade to RIPE validator rpki-validator-app-2.24 the correct Trust Anchor is configured. No further work is required. Dragon Research Labs Rcynic Validator: If you run rcynic, you need to remove all the TAL, TA or CER entries in rcynic.conf except ones which point to apnic-rpki-root-iana-origin.cer or the related TAL. If you use the trusted-certs/ directory, simply remove the four files which are named for the non-APNIC RIR as follows: cd /etc/trust-anchors # or wherever you place the TAL files rm apnic-rpki-root-ripe-origin.tal rm apnic-rpki-root-arin-origin.tal rm apnic-rpki-root-lacnic-origin.tal rm apnic-rpki-root-afrinic-origin.tal RPSTIR To modify an installed RPSTIR system, locate the /usr/local/etc/rpstir directory and remove all but the current live APNIC TAL. More information is in the attached PDF describing how to update the trust anchor configuration in these three popular relying-partner software systems. -George

2 1

ALTDB maintainer creation
by Jacob Slater 28 Feb '18

28 Feb '18

Hello all, Any chance anyone has a contact for any of the ALTDB admins? I put in a maintainer creation request several months ago and haven't heard back. Working with an upstream who will only take ALTDB or LOAs and would like to avoid having to due LOAs in the future. Thanks all, Jacob Slater

1 0

Re: MSFT reverse IP failure?
by Ken Chase 28 Feb '18

28 Feb '18

Having a client doing a test from the MSFT exchange tools site, which is failing. NOQUEUE: reject: RCPT from unknown[13.67.59.89]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [13.67.59.89]; NetRange: 13.64.0.0 - 13.107.255.255 CIDR: 13.96.0.0/13, 13.104.0.0/14, 13.64.0.0/11 NetName: MSFT A bit of an oversight? /kc -- Ken Chase - math(a)sizone.org Guelph Canada

6 8

TEKTONIC CONTACT
by Matt Hoppes 28 Feb '18

28 Feb '18

Could someone from Tektonic VPS please contact me off list about routing issues?

1 0

Re: Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks
by Brian Kantor 28 Feb '18

28 Feb '18

It seems to me that since peer pressure hasn't worked, it's time to resort to legal means. Have a talk with your own organization's lawyers, explain to them how much time and money those folks are costing your organization, and see if there isn't something you can do in the way of billing for the time, small claims court, stern letters from your lawyers to their legal department, criminal illegal-computer-access complaints, etc. - Brian

1 0

cgnat - how do you handle customer issues
by Aaron Gould 27 Feb '18

27 Feb '18

Couple questions please. When you put thousands of customers behind a cgnat boundary, how do you all handle customer complaints about the following. 1 - for external connectivity to the customers premise devices, not being able to access web servers, web cameras, etc, in their premises? 2 - from the premise natted device, when customers go to a university or bank web site, how do you handle randomly changing ip addresses/ports that may occur due to idle time and session tear-down in nat table such that the bank website has issues with seeing your session ip change? -Aaron

6 7