RIPE 66 MAT Working Group Minutes

Date: 16 May 2013, 16:00 – 17:30
Co-chairs: Richard Barnes, Christian Kaufmann
Scribe: Suzanne Taylor

A. Introduction

MAT Working Group Co-chair Richard Barnes opened the session and thanked the scribe and chat monitor. He said the minutes from RIPE 65 had been posted on the website and asked whether they could be approved and whether there were any proposed revisions. The audience agreed to approve the minutes and there were no proposed revisions.

B. An Analysis of the Internet Interconnection Density in IPv6 Compared to IPv4

Christian Kaufmann, RIPE NCC Executive Board

The presentation is available at:
https://ripe66.ripe.net/presentations/219-20130516_MAT_CK_Interconnection_density.pdf

Christian asked for feedback about whether his project, which forms the basis for his master's thesis, was interesting and useful, and whether he should report back on the results at the next MAT Working Group session.

Jen Linkova, Google, stated that the results would be very useful.

Gert Doering commented that in his upstream networks he's seen that some peering points are reachable over only IPv4, which yields latency differences. While this hasn't been a problem yet for Gert, he said he found it interesting enough to investigate himself and so he also found Christian's project useful.

Andrew Yourtchenko, Cisco, said he also thought Christian's project sounded very useful and that it would also be interesting to see the progression over time and whether the results show any improvement.

Christian replied that most of the analysis would be done over the summer, so he should have enough data by the next MAT Working Group session and could report back then.

An unidentified member of the audience suggested that Christian might be interested in an article written for RIPE Labs by Emile Aben, RIPE NCC, which studied IPv6 density, as well as the related work of Matthew Luckie, CAIDA.

Christian replied that he was familiar with Emile's article and that Matthew's work was on his reference list to look into further.

Jan Zorz, ISOC, said he was trying to do a similar thing with the Go6 lab and that he was happy to share his data with Christian.

Christian thanked Jan and said he would be in touch.

Richard thanked Christian for his talk and said it sounded as though there was a lot of support and interest in his project.

C. Large Scale Broadband Measurement

Trevor Burbridge, BT

The presentation is available at:

https://ripe66.ripe.net/presentations/236-ripe66_trevor_burbridge.pdf

Daniel Karrenberg, RIPE NCC, asked whether the project is only about developing standards, or whether it is also about implementation.

Trevor responded that the EU (Leone) project is very much about implementation and has a test bed in place. He said the IETF project is currently focused on frameworks, ideas, capabilities and requirements and hopefully there will be vendors at some point and they will start building something.

Daniel commented that the scope Trevor described seemed sensible.

Andy Davidson, LONAP, commented that he thought this was a great project. He said that he knows from experience that giving a consistent level of support across a large number of access circuits and getting standardised data is difficult, so he appreciated these efforts. However, he added that getting actionable data that can lead to diagnosis is difficult, and wondered whether the scope of this project would allow for transport analysis.

Trevor responded that the measurement framework would allow for running tests over different parts of the network, and could enhance the data returned with knowledge of the topology and assets, so they should be able to say which part of the network is experiencing problems; the next step is to determine exactly what the problem is. He said that the framework would then fall back on existing diagnostic and test systems.

Andy responded that being able to confirm that an end user's claims matches reality would be very useful, and suggested that the scope of the next version of the project could include such diagnostic capabilities as helping identify a problematic piece of copper in the transport chain, for example.

Trevor responded that it's dependent on the device, so for example if they're doing a test from a home gateway that is also the modem, then in addition to reporting back test results, they could also report back DSL and FTTP diagnostics, etc.

Richard thanked Trevor and asked for input from the MAT community and pointed the audience to the IETF LMAP mailing list.

D. RIPEstat Update

Vesna Manojlovic, RIPE NCC

The presentation is available at:
https://ripe66.ripe.net/presentations/312-ripe66-RIPEstat-mat-wg-v2.key

An unidentified audience member asked whether there is a RIPEstat app.

Vesna replied that there is a RIPEstat app available and that she mentioned only the mobile site in her presentation because it is new.

Thomas Smyth, Wireless Connect, said that the revamped BGPlay tool is really helpful, especially for people new to BGP. He commented that sometimes various sensors around the world aren't available and that it would be nice if unreachable sensors were removed from the reachability calculations.

Vesna thanked Thomas for his feedback and said she would follow up with him.

Richard thanked Vesna for her presentation.

E. BGPlay2

Massimo Candela, Roma Tre University

The presentation is available at:
https://ripe66.ripe.net/presentations/317-BGPlay_js-ripe66.pdf

Daniel Karrenberg, RIPE NCC, commented that he was stunned when he first saw the revamped BGPlay tool. He added that it works on phones and is a great tool, and was happy that the RIPE NCC could help make it available.

Massimo thanked Daniel for his feedback.

Donal Cunningham, AirSpeed Telecom, said that he wanted to thank Massimo on behalf of network engineers everywhere for BGPlay. The audience applauded.

Richard thanked Massimo for his presentation.

F. RIPE Atlas Update

Vesna Manojlovic, RIPE NCC

The presentation is available at:
https://ripe66.ripe.net/presentations/307-ripe66-mat-wg-atlas-v2.pdf

David Freedman, Claranet Limited, commended Vesna on publishing the RIPE Atlas source code, but said he wasn't expecting to have to download a 7 MB file and asked whether the code could be published on GitHub.

Vesna replied that it was possible.

Andrei Rovinski, Internet Society, commented that he would like to see the ability for RIPE Atlas to detect networks that allow spoofing. He said that the panel on Tuesday made it clear there is a lack of data around this issue, which is difficult to track, and that without data, discussions around anti-spoofing are just “hot air”. He asked that Vesna put this issue on the RIPE Atlas roadmap. He also added that Daniel wrote a good email outlining the issue on the RIPE Atlas mailing list, and said he would like to continue discussing it. He said he understands that this is not an easy thing to do, but that data around spoofing would be very useful.

Vesna thanked him and said it could be discussed now or during the RIPE Atlas BoF.

Richard asked to hear Daniel Karrenberg's opinion on the matter.

Daniel Karrenberg, RIPE NCC, asked who had read the discussion on the RIPE Atlas mailing list; a number of people raised their hands. Daniel offered to summarise the discussion for those who hadn't seen it. He said that he was very interested in obtaining data about what networks are spoofable and is always interested in new measurements and insights. He also added that he was involved in the first anti-spoofing task force at RIPE, and that this is an issue dear to his heart. Having said that, he said that RIPE Atlas is also dear to his heart and he thinks there are significant risks to making probes – which are hosted by thousands of people around the world – do things that shouldn't be done. This includes spoofing addresses, he said, because this is the only way to find out whether a network allows spoofing. He said there is a significant risk that the RIPE NCC might lose the trust and confidence of current and potential RIPE Atlas probe hosts if they discover this is being done, or even if the RIPE Atlas team asks them if they can do this. He urged everyone to carefully consider the risks involved rather than blindly start doing something just because it is technically possible. He added that the worst thing that could happen would be to lose the probe hosts' trust, and urged everyone to be conscious of that.

David Freedman, Claranet Limited, agreed with Daniel but said that he would really like to have the spoofing data. The problem, he said, is that spoofing traffic goes against his acceptable use policy. He said that a better defined technical solution was needed. However, he added that if he was asked for consent for his probe to experiment by sending, for example, malformed packets and the information was kept confidential, he would be more amenable to that because he wouldn't know exactly what he should be hiding in that case and might learn something in the process.

Thomas Smyth, Wireless Connect, said he agreed with both David and Daniel and that he agreed in principle with an experimental version of a spoofing project that would allow for security research and perhaps use a special allocation of addresses that wouldn't harm anyone if they were spoofed. He said that it would also be useful to have some sort of alerting function if your probe is offline.

Vesna thanked Thomas for his comment.

Benno Overeinder, NLnet Labs, suggested that maybe the RIPE NCC could run such an experiment for a month or so, or form a group within the MAT Working Group and get consensus about the experiment's duration and scope, etc.

Daniel responded that there should be a discussion about this on the mailing list and encouraged everyone interested to join in that conversation. He added that he would want to know what the goal is of any of these experiments and determine whether RIPE Atlas is suitable for this kind of project, or whether there might be other means of doing this that would be less risky. He said that he asked the RIPE Atlas team to look at how many probes are behind NATs, as his intuition is that probes behind NATs aren't likely to be able to spoof. He reported that more than half of the probes are behind NATs, so maybe RIPE Atlas isn't the right tool for a spoofing project. He reiterated that this was a wider discussion that should take place on the mailing list.

Richard asked Daniel whether he meant the discussion should take place on the MAT Working Group mailing list.

Daniel confirmed that he thought the MAT Working Group mailing list was indeed the right place for the discussion and that it's very easy to subscribe to it.

Richard asked Daniel to send a message to the mailing list in order to kick off the discussion.

Daniel replied that Alexander Isavnin, NetLine, had already started the discussion and thanked him for it, and added that there is a whole thread now on the mailing list about this. He reiterated that he is not against the project in principle, but is merely cautious.

John McAleer, Dyn, commented that there was a discussion on the NANOG mailing list in which people were surprised at how many were able to get through NATs. He added that he would like to be able to opt in or out of a spoofing experiment and that once you opt in, there should be constant data acquisition. He said that if people were doing what they should be doing, no one would have to worry about “hurting feelings”. He said he was more interested in cleaning up what should never have been broken 20 years ago, which is likely being used to attack his network.

Randy Bush, Internet Initiative Japan, asked the room who among them would opt in to a spoofing experiment but do not know whether they're blocking or not. No one put up their hand, which he suggested was to be expected. He suggested that everyone who would opt in would know they're blocking, not because they're nefarious but because they have thought about it.

Richard thanked Vesna for her presentation.

Z. AOB

There was no further discussion.

Richard thanked everyone for coming and closed the session.