March 2017 - Test - lists.nanog.org

RNP Santa Catarina Point of Presence (PoP-SC)
by James Bensley 09 Mar '17

09 Mar '17

Hi All, Anyone from RNP on-list that can reach out to me off-list, minor technical problem in your network. Thanks, James.

2 2

Fwd: CIA Exploits on Mikrotik Hardware /Software
by Tom Smyth 08 Mar '17

08 Mar '17

---------- Forwarded message ---------- From: Tom Smyth <tom.smyth(a)wirelessconnect.eu> Date: Wed, Mar 8, 2017 at 3:02 PM Subject: CIA Exploits on Mikrotik Hardware /Software To: INEX Members Technical Mailing List <tech(a)inex.ie> Hi Lads, For MikroTik Users in the community there are apparently live exploits for MikroTik software and apparently this was used by the CIA, if the tools are released in the wild this would represent a significant threat to your ISPs for those of you who have MikroTik Routers with public IPs on them and if they are not adequately filtered, I would humbly suggest that you apply best practices and filter the management services and disable any management services that you dont absolutely need, for further details please find the following More Details on the MikroTik CIA Exploits https://forum.mikrotik.com/viewtopic.php?t=119255 you can disable un needed administration services in IP/services menu, and I would suggest filtering access to the management ports and disabling the web management interface altogether and disable ftp If you want to protect the Routers apply filters on the input chain of the Firewall Filter, tcp dstport 22 for ssh tcp dstport 8291 for winbox tcp dstport 23 for telnet tcp dstport 8729 api tcp dstport 8728 api tcp dstport 20,21 ftp be aware that the api interfaces could have been enabled if you were upgrading the software from an older version I have included a sample configuration script below just to help But make sure to adjust it to suit your own needs... /ip service set telnet disabled=yes set ftp disabled=yes set www disabled=yes set www-ssl certificate=cert1 disabled=yes set api disabled=yes set api-ssl disabled=yes /ip firewall address-list add address=5.134.88.0/29 list=Management #STOP REPLACE the address above with your management ip ranges #copy the lines to add more ips /ip firewall filter add action=accept chain=input comment="Drop input Rule to protect MikroTik Devices" dst-port=22 src-address-list=Management_ipprotocol=tcp add action=accept chain=input comment="Drop input Rule to protect MikroTik Devices" dst-port=8291 src-address-list=Management_ipprotocol=tcp add action=drop chain=input comment="Drop input Rule to protect MikroTik Devices" dst-port=22 protocol=tcp add action=drop chain=input comment="Drop input Rule to protect MikroTik Devices" dst-port=8291 protocol=tcp add action=drop chain=input comment="Drop input Rule to protect MikroTik Devices" dst-port=23 protocol=tcp add action=drop chain=input comment="Drop input Rule to protect MikroTik Devices" dst-port=21 protocol=tcp add action=drop chain=input comment="Drop input Rule to protect MikroTik Devices" dst-port=8729 protocol=tcp add action=drop chain=input comment="Drop input Rule to protect MikroTik Devices" dst-port=8728 protocol=tcp after running that script on your mikrotik Firewall ensure the rules that you added are moved straight to the top of the firewall rule set .... it is important to note that full details on the exploits are not available but any service that Mikrotik is running could be an entry point so bear that in mind , eg , NTP DNS ... Hotspot , CDP / MNDP / and the long list of VPN services that can be configured on MikroTik... -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 --------------------------------- PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL This email contains information which may be confidential or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify me by telephone or by electronic mail immediately. Any opinions expressed are those of the author, not the company's .This email does not constitute either offer or acceptance of any contractually binding agreement. Such offer or acceptance must be communicated in writing. You are requested to carry out your own virus check before opening any attachment. Thomas Smyth accepts no liability for any loss or damage which may be caused by malicious software or attachments.

1 2

google ipv6 routes via cogent
by Aaron 08 Mar '17

08 Mar '17

Hi, I'm new to the nanog list, hope this isn't out of scope for what is usually discussed here. Cogent is telling me that I can't route through cogent to get to google ipv6 routes (particularly the well known dns addresses 2001:4860:4860::88xx) because google decided not to advertise those route to one of their mutual peers. Anyone know anything about this ? .and why it happened and when it will be resolved ? -Aaron

13 18

scalematrix network access
by Mark Stevens 08 Mar '17

08 Mar '17

Good Morning, Is anyone having access issues into sites within scalematrix.net network? Our traces make it out of Cogent and into Level3 and either die in Level3 or a couple hops past Level3 into scalematrix.net network. If someone from Scalmatrix or Level3 reads this, can you email me offline to discuss? Thanks Mark

1 0

RE: WEBINAR TUESDAY: Can We Make IPv4 Great Again?
by Jakob Heitz (jheitz) 08 Mar '17

08 Mar '17

1.1.1.1.e.f and 2.2.2.2.e.f both get translated to 192.168.e.f. Some higher layer protocols embed IP addresses into their data. These points make changing IP so difficult. In addition, IPv6 has link local addresses. This one seemingly insignificant detail causes so much code churn and is probably responsible for 10 years of the IPv6 drag. Thakfully, site local was deprecated. Thanks, Jakob. > Date: Mon, 6 Mar 2017 22:00:45 +0100 > From: Baldur Norddahl <baldur.norddahl(a)gmail.com> > To: nanog(a)nanog.org > Subject: Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again? > Message-ID: <5645714e-e468-4655-34cf-6e70aa7cfa26(a)gmail.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > That proposal is far too wordy. Here is the executive summary: > > Encode extra address bits in extension headers. Add a network element > near the destination that converts such that the destination IP of a > packet to IP a.b.c.d with extension header containing e.f is translated > to 192.168.e.f. In the reverse direction translate source address > 192.168.e.f to a.b.c.d and add option header with e.f. > > Executive summary end. > > As far as I can tell, the only advantage of this proposal over IPv6 is > that the network core does not need to be changed. You could communicate > with someone that had an EZIP address regardless that your ISP did > nothing to support EZIP. > > The disadvantage is that every single server out there would need to be > changed so it does not just drop the option headers on the reply > packets. All firewalls updated so they do not block packets with option > headers. All applications updated so they understand a new address format. > > Servers and applications could also confuse TCP or UDP streams that are > apparently from the same source, same port numbers, only thing that > differentiates the streams is some option header that the server does > not understand. > > The customers of the ISP that deploys EZIP would not need to update > anything (unless they need to communicate with other poor souls that got > assigned EZIP addresses), however everyone else would. This is not a > good balance. The customers would experience an internet where almost > nothing works. It would be magnitudes worse than the experience of an > IPv6 only network with NAT64. > > It is a fix for the wrong problem. Major ISPs have IPv6 support now. It > is the sites (=servers) that are lacking. If Twitter did not deploy IPv6 > why would you expect them to deploy EZIP? Why would some old forgotten > site with old song texts in some backwater country somewhere? > > We already have better solutions such as CGN with dual stack, NAT64, > DS-Lite, MAP etc. > > None of that is discussed in the RFC. Is the author aware of it? > > Regards, > > Baldur >

5 5

WEBINAR TUESDAY: Can We Make IPv4 Great Again?
by Joly MacFie 07 Mar '17

07 Mar '17

To say that Mr. Chen's EZIP proposal has not, thus far, been received with open arms by the networking community would be an understatement. It is seen as delaying the inevitable and introducing an impractical extra routing hardware layer that will be hit & miss. Nevertheless, since much of the world is still IPv4 dependent, it just could take off. ISOC-NY is happy to give him the opportunity to expound on its merits. We'd welcome some expert respondents. See: https://tools.ietf.org/html/draft-chen-ati-ipv4-with-adaptive-address-space… ================================================================== WEBINAR TUESDAY: Can We Make IPv4 Great Again? w/ @AbrahamYChen On Tuesday March 8 2017 at noon EST the Internet Society New York Chapter (ISOC-NY) presents a webinar Can We Make IPv4 Great Again?. Abraham Y. Chen, VP of Engineering, Avinta Communications, will present his EzIP proposal to reinvigorate the diminishing pool of IPv4 addresses. Optional registration at the link below. This will be recorded. What: WEBINAR: Can We Make IPv4 Great Again? When: Tuesday March 8 2017 Noon EST | 17:00 UTC Register + info: https://www.meetup.com/isoc-ny/events/238164448/ Computer: https://zoom.us/j/914492141 Phone: http://bit.ly/zoomphone ID: 914 492 141 Twitter: #ezip ==================================================================== Permalink http://isoc-ny.org/p2/9031 -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- -

11 15

Re: google ipv6 routes via cogent
by Baldur Norddahl 07 Mar '17

07 Mar '17

That will have the effect of prioritizing Cogent routes as that would be more specific than the default routes from the other providers. Cogent are not that good that you would want to do that. Den 2. mar. 2017 20.16 skrev "Jeff Waddell" <jeff+nanog(a)waddellsolutions.com >: Or at least ask for a full view from Cogent - then you won't get any routes they don't have On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay <alarig(a)swordarmor.fr> wrote: > On jeu. 2 mars 12:36:04 2017, Aaron Gould wrote: > > Well, I asked my (3) upstream providers to only send me a ipv6 default > > route and they sent me ::/0...here's one of them... > > Why did you don’t ask for a full view? With that, you can easily deal > with that kind of problem. > > -- > alarig >

13 15

Re: WWV Broadcast Outages
by Hal Murray 06 Mar '17

06 Mar '17

"Majdi S. Abbas" <msa(a)latt.net> said: > That said, I and many others "still use" WWV -- there aren't exactly a > surplus of suitable backup methods to GPS these days. Any suggestions for gear and/or software that works with WWV (or CHU)? Or general suggestions for non GPS sources of time? Dave Mills had a driver in ntpd that used a PC audio port to listen to WWV. I don't know anybody who ever used it. I think there was code to tell some brand of receiver with a serial/USB port how to change frequencies so you could use the one that worked best for that time of day. There used to be WWVB (60 KHz) receivers. The good ones phase locked to the carrier. The general rise in EMI made those close to useless in most locations. NIST finished the job when they changed the modulation format a few years ago. As far as I know, there aren't any replacements for the old gear that take advantage of the new modulation format. GPS works too well. There are some boxes that recover the time from nearby cell phone towers. I think they will stop working as the towers get upgraded to the newer protocols that use a different form of timing. That will probably take many years. But the cell phone towers depend on GPS. (You can ususlly spot the conical antenna(s) if you look around a bit.) -- These are my opinions. I hate spam.

4 3

2nd call for presentations RIPE 74
by Benno Overeinder 05 Mar '17

05 Mar '17

Dear colleagues, Please note the approaching deadline of *12 March 2017* for RIPE 74 plenary programme submissions. You can find the CFP for RIPE 74 below or at https://ripe74.ripe.net/submit-topic/cfp/, for your proposals for plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards, Benno Overeinder RIPE PC Chair https://ripe74.ripe.net/programme/ripe-pc/ -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 74 will take place from 8-12 May 2017 in Budapest, Hungary. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 74. See the full descriptions of the different presentation formats, https://ripe74.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 12 March 2017. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes total for both presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe74.ripe.net/submit-topic/submission-form/. - Lightning talks should also be submitted using the meeting submission system (https://ripe74.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. Allocation of lightning talks will start a few days before the meeting, and will continue throughout the meeting. During the meeting, they may be announced on the day before the talk or even on the same day as the talk. - Lightning talks should also be submitted using the meeting submission system (https://ripe74.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. - Due to potential technical issues, presenters/panellists should be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

1 0

IANA IPv4 Recovered Address Space registry updated
by Paula Wang 05 Mar '17

05 Mar '17

Hi, An update has been made to the IANA IPv4 Recovered Address Space registry according to the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA (https://www.icann.org/resources/pages/allocation-ipv4-post-exhaustion-2012-…) The list of allocations can be found at: https://www.iana.org/assignments/ipv4-recovered-address-space/ Kind regards, Paula Wang IANA Services Specialist PTI

3 2