- mat-wg - mailman.ripe.net

Preliminary agenda for MAT @ RIPE66
by Richard Barnes 23 Apr '13

23 Apr '13

Hello All, This is the draft agenda for the Measurement, Analysis and Tools Working Group session at RIPE66: A. Introduction Welcome, Scribe, Jabber, Agenda B. Interconnection density in IPv4 / IPv6 - Christian Kaufmann (unconfirmed) B. IETF LMAP - Philip Eardley (BT) (unconfirmed) C. RPKI measurements - Arturo Servin (LACNIC) (unconfirmed) D. RIPE Atlas update - Vesna Manojlovic (RIPE NCC) E. RIPEstat update - Vesna Manojlovic (RIPE NCC) Z. AOB Timings are approximate. There is still some time left in our agenda and we would welcome any late submissions. Please email them to mat-wg-chairs(a)ripe.net. The session will take place at 16:00 local time on Thursday 16th May. See you in Dublin! Richard & Christian

1 0

Measuring IP address hijacking with RIPE Atlas?
by Anatole Shaw 19 Apr '13

19 Apr '13

Currently I work with Greenhost, which is a RIPE LIR that was recently the recipient of a malicious route advertisement, as described here: https://greenhost.nl/2013/03/21/spam-not-spam-tracking-hijacked-spamhaus-ip/ IP address hijacking is a real problem. How often does it happen? Which networks are being spoofed, and which networks are the victims? My sense is that we don't have solid up-to-date answers to these questions. I have some thoughts about how to detect successful IP hijacking, using empirical measurements taken from multiple network vantagepoints. I'll hold off on details for now, but I'm aware that the answer is *not* simple analysis of AS paths or traceroute output, both of which are increasingly spoofed. It seems like the RIPE Atlas probe network would be an ideal platform for this type of study. Does such a study already exist? How does one begin to propose a RIPE Atlas project? Regards, Anatole Shaw

4 6

Verifying the deployability of Multipath TCP
by Olivier Bonaventure 17 Apr '13

17 Apr '13

Dear colleagues, During RIPE66, I will present a tutorial on Multipath TCP, a major TCP extension that has recently been approved by the IETF (RFC6824). The design of Multipath TCP has been heavily influenced by various types of middleboxes that process/modify/... various fields of the IP/TCP packets. Multipath TCP is in theory capable of handling these middleboxes and either go through or at worst fallback to regular TCP. In order to check this fallback mechanism, we ask your help to perform test behing as many real middleboxes as possible. To ease the testing, we have placed a modified Linux kernel that includes Multipath TCP inside a virtualbox image, added several measurement scripts to automate the test and collect packet traces. The tests run on Linux and MacOS. They do not currently work on Windows. You can download the virtualbox image from : http://multipath-tcp.org/pmwiki.php?n=Users.AboutMeasures The script needs about 15 minutes to complete and you will have access to a trace of all the packets sent and received by your virtualbox and our server if you'd like to check the interference caused by your middleboxes. We'd appreciate tests in networks that are more likely to include middlboxes such as entreprise networks, WiFi hotspots or cellular networks. From a technical viewpoint, the tests use various applications including traceroute, ftp (to trigger NAT ALG), http, https, scp. We use multipath subflows (1 and 4) and a modified Multipath TCP kernel that provides more debugging and also three different schedulers. The first scheduler is the standard MPTCP scheduler that sends packets over the best subflows, a second scheduler that sends packets in strict round robin and a scheduler that copies each packet over all subflows to detect the impact of retransmissions. Since Multipath TCP has never been deployed/tested on a large scale, these tests might trigger some alarms from firewalls/IPS/DPI boxes that could detect unknown behaviour. If this happens, please send a report to Fabien Duchene indicating the type of alarm. All the data collected will be analysed and I plan to report on these results during the tutorial at RIPE66 Thanks for your help, Olivier Bonaventure

1 0

Recent RIPE Atlas features and developments
by Vesna Manojlovic 08 Apr '13

08 Apr '13

Dear colleagues, Please find a description of the recent RIPE Atlas features n RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-april-2013-u… Highlights: - one-off measurements & REST API for UDMs released to testers - new web-site navigation - we started shipping 3rd generation of probes We also have new ways to take part in the community, by: - adding your code to GitHub Community repository - submitting your photos of probes - meeting RIPE Atlas Ambassadors at some of the upcoming conferences We are looking forward to your feedback and questions. Regards, Vesna

1 0

RIPE66 - Call for presentations in the MAT-WG
by Christian Kaufmann 02 Apr '13

02 Apr '13

Dear Working Group Colleagues, RIPE 66 will take place from 13rd - 17th May 2013 in Dublin. (http://ripe66.ripe.net/) The MAT-WG session is scheduled to run between 16:00 - 17:30 on Thursday 16th May. My co-chair and I invite you to submit presentations or suggestions for content you would like to see in this session. As a reminder, the working group charter states: "The purpose of the working group is to provide a forum in which the RIPE NCC and the community can collaborate in the areas of data, tools and analysis relating to the Internet and its infrastructure, with a loose focus on monitoring, diagnosis, analysis and forecasting. It is not the purpose of the working group to compare the performance of networks for marketing purposes." If you would like to contribute anything to our session at the next RIPE meeting please email mat-wg-chairs(a)ripe.net Best regards, CK & Richard Co-chair's MAT Working Group

1 0

New on RIPE Labs: Cable Disruption as Seen in RIPEstat
by Mirjam Kuehne 27 Mar '13

27 Mar '13

Dear colleagues, We were curious to see what RIPEstat tells us about the recent cable disruption off the coast of Egypt. Please see the recent post on RIPE Labs: https://labs.ripe.net/Members/mirjam/mediterranean-cable-disruption-as-seen… Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: RIPEstat March Update
by Mirjam Kuehne 06 Mar '13

06 Mar '13

Dear colleagues, Many new features and improved functionality have been made available in RIPEstat since the last update. Users can now retrieve Internet number resource-related information by querying for hostnames and countries in RIPEstat. There are also five new widgets: Country Routing Statistics, Abuse Contact Finder, Forward DNS, DNS Chain, and RIPE Atlas Measurement Targets. In addition, we have created a new site tailored specifically for mobile users, and we released a new Apple mobile app. Please find more details on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripestat-march-update Kind regards, Mirjam Kuehne RIPE NCC

1 0

[MAT-WG]: Attributing inbound traffic from an IX
by Steve Nash 25 Feb '13

25 Feb '13

[This email has also gone to the EIX-WG ] Bad traffic is coming into my IX Peering interface. How do I find out where that bad traffic is coming from? How do I get it to stop? Customers of Internet Exchanges get a good deal on peering. Life is easy. Until something goes wrong. DDoS traffic starts coming into the IX interface.. I work for Arbor Networks and I have seen such questions many times. cFlow, Netflow, IPFIX can show that there is anomalous traffic arriving, but not where it is coming from (last hop). I have a suggestion and I would like to know if it is already in use, or considered of any use.. The answers are in Layer-2, of course. The MAC addresses identify which of the routers of my Peers actually transmitted a packet to my router. Problems: 1/ I could try to tap off the interface and get a packet trace, but I have to capture and identify a sample of the offending traffic, 2/ My peering router generates Netflow/IPFIX, but only populates Layer-3 data. Even if it did populate field 56 - Src MAC.. 3/ In either case I need to get into the ARP cache to figure out which IP address the MAC address belongs to.. Suggestion: Ask all IX customers to Embed the ASN into a Locally Administered MAC address on each peering interface. First byte for Local flag, second byte for interface number, others for four-byte ASN 02:00:00:00:01:00 for ASN 256 02:00:00:00:04:F9 for ASN 1273 (first interface) 02:01:00:00:04:F9 for ASN 1273 (second interface) Now, if all peers have their router interfaces configured with these Local MAC Addresses, then a customer can capture the traffic and very quickly extract the identity of each Peer that is sending packets. And peers can change their router hardware and still transmit from the same MAC address. Also, if I can get a peering Router to populate the Src MAC field of IPFIX and Netflow then I can start monitoring it all with flow reporting tools. Such MAC level encoding of ASN could be part of the peering agreement between organisations, or part of the requirement to connect to an IX RouteReflector. Even as a voluntary recommendation it could cut down the workload of identifying where traffic is coming from. I would appreciate your comments. I'll be in Dublin too, if a discussion is worthwhile. Regards Steve Nash

1 0

Call for Papers: RIPE 66, 13-17 May 2013 in Dublin, Ireland
by Benno Overeinder 22 Feb '13

22 Feb '13

Call for Papers: RIPE 66 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 66 will take place on 13-17 May 2013 in Dublin, Ireland. https://ripe66.ripe.net/ The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the Plenary, BoF and Tutorial sessions at RIPE 66. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data center technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange Submissions Attendees of the RIPE meetings 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 who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. In addition to presentations selected in advance for the Plenary, the RIPE PC also offers several time slots for “lightning talks” which are selected immediately before or during the conference. The following requirements apply: - Proposals for Plenary talks, BoFs, Panels and Tutorials must be submitted for full consideration no later than 24 February 2013, using the meeting submission system at: https://meetings.ripe.net/pc/ Proposals submitted after this date will be considered on a space-available basis. - Presenters should indicate how much time they will require (30 minutes for talks is a common maximum duration, although some talks can be longer). - Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For BoFs and panels, proposals must contain a clear description as well as names of invited panelists/presenters. - Due to potential technical issues, it is expected that most if not all presenters/panelists will be physically present at the RIPE meeting. - Lightning talks should be submitted using the meeting submission system. They must be short (10 minutes maximum) and often involve more timely topics. They can be submitted at any time. The allocation of lightning talk slots will be announced one day prior to the relevant session. 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

New on RIPE Labs: Finding Abuse Contact Information Using RIPEstat
by Mirjam Kuehne 19 Feb '13

19 Feb '13

[apologies for duplicates] Dear colleagues, We implemented a new widget in RIPEstat that allows you to find abuse contact information registered in the RIPE Database. Please find more information on RIPE Labs: https://labs.ripe.net/Members/cteusche/finding-anti-abuse-contact-informati… Kind regards, Mirjam Kuehne RIPE NCC

1 0