February 2018 - Test - lists.nanog.org

Open Souce Network Operating Systems
by Colton Conor 04 May '18

04 May '18

If one were to deploy whitebox switches, X86 servers, low cost ARM and MIBPS CPE devices, and basically anything that can run linux today, what network operating system would you recommend? The goal would be to have a universal network operating system that runs across a variety of devices. >From low cost residential CPE's with wifi to switches to BGP speaking routers. Is there anything that can do it all today? I will use something like OpenWRT as an example. I don't consider this anywhere near carrier grade, but it runs on X86 and low cost routers. I don't think it will run on whitebox switches though. Mikrotik RouterOS would be another example as it can run on low cost Routerboards, and X86 servers. But it is not opensouce. Is there any up and coming projects to look into?

14 17

survey on BGP prefix hijacking
by Alberto Dainotti 02 May '18

02 May '18

Dear NANOG Community, BGP prefix hijacking remains a problem for Internet routing, despite the (partial) use of RPKI or detection services. We would like to hear your opinions on BGP prefix hijacking (concerns, existing defenses, needs, etc.) that would help us research new defense mechanisms both for its detection and mitigation. Please help us by answering this short (< 10min, 21 questions) and anonymous survey. Survey URL: http://tinyurl.com/hijack-survey *** The survey *** This survey is part of a joint research effort by CAIDA (www.caida.org) and the ICS-FORTH (www.ics.forth.gr) research institute, to study (a) operator awareness of BGP prefix hijacking attacks/incidents, (b) presently used defenses against BGP prefix hijacking, (c) the willingness to adopt new defense mechanisms, and (d) reasons that may hinder the deployment of BGP prefix hijacking defenses. We expect the findings of this survey to increase the understanding of existing BGP hijacking defenses and the needs of network operators, as well as help us design and implement new defense mechanisms that we will present to the operator and scientific communities. A summary of the aggregate results will be published as a part of an article/conference paper. Thank you in advance, and we look forward to your responses! Alberto (CAIDA) and Pavlos (ICS-FORTH)

1 1

Quanta LB4M
by Mike Hammett 20 Apr '18

20 Apr '18

Has anyone gotten a "non-factory" firmware to go onto these guys? There are a couple threads on Google that are inconclusive. There are rumors that it's the same as a Dell something or an HP something else, but no one has outright said, "I loaded a Dell XXXX firmware onto it and solved all of the random ass bugs." If I didn't already have a couple of stacked Extreme x400s, I'd consider these at home, but they're somewhat buggy. Quanta told me to contact whomever I bought it from... but I don't think the random guy on eBay is going to have much of anything useful to say. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com

4 7

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 01 Mar '18

01 Mar '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