May 2014 - mat-wg - mailman.ripe.net

The Beta Version of the New DNSMON is Now Available
by Vesna Manojlovic 08 Sep '14

08 Sep '14

Dear colleagues, The DNS Monitoring Service (DNSMON) has been providing a comprehensive, objective and up-to-date overview of the quality of various global and regional DNS operators' services since 2003. We are in the process of integrating DNSMON within RIPE Atlas and the beta version of the new DNSMON is now publicly available: https://atlas.ripe.net/dnsmon We have also published a RIPE Labs article detailing what’s changed in the new DNSMON: https://labs.ripe.net/Members/fatemah_mafi/an-updated-dns-monitoring-service We invite you all to try the new service and provide your feedback. We’re confident that the new DNSMON will continue to meet your needs and hope that you'll be happy with the new features. Please send your comments and questions to the DNS Working Group Mailing List at dns-wg(a)ripe.net. Kind regards, Vesna Manojlovic Measurements Community Building RIPE NCC

7 11

New article on RIPE Labs: Basic Evaluation of new IXP Peering Partners with RIPE Atlas and Zabbix
by Mirjam Kuehne 26 May '14

26 May '14

Dear colleagues, In this new article on RIPE Labs, Daniel Gomez explains how he used RIPE Atlas to evaluate new peering partners within an Internet Exchange Point and how this helped to improve customer services: https://labs.ripe.net/Members/daniel_gomez/basic-evaluation-of-new-ixp-peer… Kind regards, Mirjam Kuehne RIPE NCC

1 0

BEREC - Network Neutrality
by Gordon Lennox 20 May '14

20 May '14

BEREC have just issued a press release commenting on the Parliament's modified proposal and recalling some of their concerns with the Commission's initial proposal. About network neutrality they write: <<BEREC supports the promotion of and the clear commitment of the European Parliament to the principle of net neutrality. This is in line with BEREC’s public position, and indeed BEREC has been deeply involved with the subject since 2010, since when it has developed a set of principles and guidelines that can be implemented and adapted by national regulatory authorities, under the existing framework. The internet has proven to be highly innovative, thanks to certain fundamental principles such as the separation of network and application layer, the best effort principle and universal connectivity. This innovation should be safeguarded, both on the edges and within the network. BEREC recognizes that guaranteeing an open internet is a challenging objective, not least given its complex and dynamic ecosystem. Yet, the Commission’s original proposal would turn a flexible and progressive regulatory regime (under the 2009 Framework) into a rigid regulatory system and the European Parliament has generally retained this approach. BEREC would instead prefer an approach based on principles rather than detailed rules and which provides NRAs with the necessary powers to ensure that those principles (such as the ones developed by BEREC on what constitutes reasonable traffic management and on the relationship between specialized services and internet access services) are respected. Under such an approach, national regulators would be pursuing the same objective and enforcing the same principles, but the specific triggers and thresholds for regulatory intervention in a given market could be adapted to address national circumstances. If a rules-based approach is nonetheless to be pursued, then further work would be required to ensure that the definitions and rules were legally precise, future-proof and enforceable in practice. While some of the language in the text adopted by European Parliament draws upon BEREC previous publications on the subject, improving the original Commission’s proposals, it does not yet meet these standards. A balanced approach to promoting net neutrality on the Internet in parallel to the provision of specialised services is a difficult challenge. BEREC considers that specialised services should be clearly separated (physically or virtually) from internet access services at the network layer, to ensure that sufficient safeguards prevent degradation of the internet access services. Therefore BEREC welcomes the European Parliament’s acknowledgement of this principle. However, some inconsistencies in the proposed rules and definitions still raise legal and policy concerns.>> http://berec.europa.eu/eng/news_consultations/whats_new/2203-berec-publishe… So if you want network neutrality then you need regulation? The only question left is what kind. One indication of where they see the limits can perhaps be found in the sentence "This innovation should be safeguarded, both on the edges and within the network." I feel this is a significant shift. I cannot remember regulators looking in detail at what happens within traditional networks. They limited themselves to the "edges". Gordon

1 0

BEREC
by Gordon Lennox 16 May '14

16 May '14

BEREC - the Body of European Regulators for Electronic Communications, http://berec.europa.eu - are interested in metrics and monitoring. They are looking in particular at how regulators can monitor QoS for Internet access services in the context of network neutrality. Indeed they just had a public consultation on: "Monitoring quality of services in the context of network neutrality" based on a draft report, a draft which I think is still worth reading. See: http://berec.europa.eu/eng/news_consultations/ongoing_public_consultations/… From there - still also accessible from their home page - you can access the draft report and the annex where Atlas is mentioned. They have published a number of other reports on this going back over the past few years. Lots of reading! I brought this up on the Cooperation List and was requested to made a short presentation at the Connect session. There was an initial discussion on where this could sit between Cooperation and Connect. But looking forward maybe a more natural home would be between Connect and MAT. I will leave that for others to decide. But I do think it would be good to get somebody from BEREC to present in London. I will share the contact details I have with the co-chairs. Regards, Gordon

1 0

RIPE Atlas use cases and more
by Vesna Manojlovic 13 May '14

13 May '14

Dear colleagues, There have been a lot of great examples recently of how RIPE Atlas can be used to investigate network events, troubleshoot problems, explore how the Internet behaves, and more. Some of the topics include: - Investigating customer complaints about slow servers - Comparing TCP and UDP Response Times of DNS Root Servers - Discovering Path MTU black holes on the Internet We’ve collected all of these user experiences, analyses, papers and presentations in one place on RIPE Labs, in order to make it easy to discover how others are making use of the RIPE Atlas network - and maybe spark some ideas about how you can, too. https://labs.ripe.net/atlas/user-experiences If you have your own story about how you’ve used RIPE Atlas, we want to hear from you! Please get in touch with us at atlas(a)ripe.net. Kind regards, Vesna Manojlovic Measurements Community Building RIPE NCC

1 0

Re: [mat-wg] Trimble GPS from old TTM
by George Michaelson 13 May '14

13 May '14

We just upgraded BSD to 10 and it seems to be fne, but I haven't completed the cutover. Certainly, the driver ID for the 127.x.x.x instance is still in the BSD port codebase. -G On Tue, May 13, 2014 at 9:39 AM, Romeo Zwart <romeo.zwart(a)ripe.net> wrote: > Hi Antonio, > > On 14/05/13 00:44 , Antonio M. Moreiras wrote: > > Hello, we are trying to reuse the trimble GPS from our old TTM server in > > a Linux NTP machine, and it is not working. > > We have been doing some testing in the RIPE NCC with some linux > flavours. A RIPE Labs article with details is in preparation and will be > shared with this list soon. > > We will contact you off line to share our experience. > > Regards, > Romeo > > > We can read some trash with a "cat /dev/ttyS0" (what means that the GPS > > is sending information), and we can use PPS driver (127.127.22.0) to > > read correctly the PPS signal. But the driver from RIPE (127.127.43.0) > > doesn't work. > > > > We compiled the ntpd (version 4.2.6p5) with the following options: > > > > ./configure --with-openssl-libdir=/usr/lib/x86_64-linux-gnu > > --with-openssl-incdir=/usr/include --enable-RIPENCC > > > > Our Linux is: > > > > # uname -a > > Linux monitor 3.11.0-20-generic #35~precise1-Ubuntu SMP Fri May 2 > > 21:32:55 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > > > > # lsb_release -a > > No LSB modules are available. > > Distributor ID: Ubuntu > > Description: Ubuntu 12.04.4 LTS > > Release: 12.04 > > Codename: precise > > > > Only after follow the recommendations at > > http://linuxpps.org/wiki/index.php/LinuxPPS_NTPD_support, the driver > > 127.127.43.0 is loaded by NTP, and appears in the list of peers, but no > > sync, just zeros. > > > > Does anyone in this list have any tips? > > > > Regards, > > Moreiras. > > > > > > > >

2 2

Prevention of NTP reflection attacks using TTM systems
by Romeo Zwart 13 May '14

13 May '14

Dear colleagues, During the evening of Wednesday 8 January, the RIPE NCC received initial reports about the abuse of some of our Test Traffic Measurement (TTM) systems, specifically about the use of NTP in reflection attacks. Within 24 hours of receiving the first report, we adapted the NTP configuration on all our TTM hosts so that this specific type of attack is no longer possible using the TTM infrastructure. We would like to thank Gert Doering (SpaceNet) and Michael Hausding (SWITCH-CERT) for reporting the abuse to us. We’d also like to share this resource about securing NTP servers that you may find useful: http://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html We are taking this opportunity to remind you that we are nearing end of service for TTM. As we announced previously, TTM shutdown is scheduled for the end of Q1, 2014. RIPE Atlas, and specifically RIPE Atlas anchors, will provide much of the functionality of TTM. More details, including information about hosting a RIPE Atlas anchor, are available at: https://atlas.ripe.net/about/anchors/ Kind regards, Romeo Zwart RIPE NCC

4 4

Five more RIPE Atlas anchors in the previous month
by Vesna Manojlovic 07 May '14

07 May '14

Dear colleagues, We are proud to announce that five new RIPE Atlas anchors have been activated since my previous announcement last month: - uy-mvd-as28000, hosted by LACNIC in Montevideo, Uruguay. (This is the first anchor in Latin America and the first one hosted by an RIR on behalf of the RIPE NCC. ) - au-bne-as4608, hosted by APNIC in Brisbane, Australia - cz-prg-as39392, hosted by SuperNetwork in Prague, Czech Republic - fr-tin-as196670, hosted by ADP in Pantin, France - be-lln-as2611 by the Université catholique de Louvain in Belgium This brings the total number of anchors to 55. All RIPE Atlas anchors can be seen on this list, where logged-in users can access each anchor's measurements: https://atlas.ripe.net/anchors/list/ We are still accepting new applications from individuals and organisations interested in hosting a RIPE Atlas anchor. We are particularly interested in deploying anchors in the Middle East, Western Asia, Latin America and Africa, in order to add more geographical diversity to the measurement data. Learn more about RIPE Atlas anchors and the benefits of hosting an anchor at: https://atlas.ripe.net/about/anchors/ For detailed announcements and updates about RIPE Atlas, please join the RIPE Atlas mailing list: https://www.ripe.net/mailman/listinfo/ripe-atlas Kind regards, Vesna Manojlovic Measurements Community Building Team RIPE NCC

1 0