From ck at minxs.net Tue Apr 2 15:41:30 2013
From: ck at minxs.net (Christian Kaufmann)
Date: Tue, 2 Apr 2013 15:41:30 +0200
Subject: [mat-wg] RIPE66 - Call for presentations in the MAT-WG
Message-ID: <17529B77-E0E8-48AE-9BA6-2E7654CC7285@minxs.net>
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 at ripe.net
Best regards,
CK & Richard
Co-chair's MAT Working Group
From BECHA at ripe.net Mon Apr 8 15:02:34 2013
From: BECHA at ripe.net (Vesna Manojlovic)
Date: Mon, 08 Apr 2013 15:02:34 +0200
Subject: [mat-wg] Recent RIPE Atlas features and developments
Message-ID: <5162BFEA.8040302@ripe.net>
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-update
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
From Olivier.Bonaventure at uclouvain.be Wed Apr 17 10:28:46 2013
From: Olivier.Bonaventure at uclouvain.be (Olivier Bonaventure)
Date: Wed, 17 Apr 2013 10:28:46 +0200
Subject: [mat-wg] Verifying the deployability of Multipath TCP
Message-ID: <516E5D3E.7070002@uclouvain.be>
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
From ripemat at omni.poc.net Wed Apr 17 16:01:18 2013
From: ripemat at omni.poc.net (Anatole Shaw)
Date: Wed, 17 Apr 2013 16:01:18 +0200
Subject: [mat-wg] Measuring IP address hijacking with RIPE Atlas?
Message-ID: <20130417140118.GI2200@topset.berm.ch>
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
From rbarnes at bbn.com Wed Apr 17 17:24:42 2013
From: rbarnes at bbn.com (Richard Barnes)
Date: Wed, 17 Apr 2013 11:24:42 -0400
Subject: [mat-wg] Measuring IP address hijacking with RIPE Atlas?
In-Reply-To: <20130417140118.GI2200@topset.berm.ch>
References: <20130417140118.GI2200@topset.berm.ch>
Message-ID: <3E37DF0F-FDA3-44C7-8B40-44E1F00D836E@bbn.com>
Hi Anatole,
I agree that hijacking is a problem. The IETF SIDR working group has been developing extensions to BGP to help deal with it [1].
However, it's not clear to me how Atlas could help measure hijacking. Atlas is an active measurement network. What sort of probes would detect a hijack?
I wonder if analyzing some of RIPE's passive data sets might be a better approach.
Best,
--Richard
On Apr 17, 2013, at 10:01 AM, Anatole Shaw wrote:
> 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
>
>
From ripemat at omni.poc.net Wed Apr 17 18:51:46 2013
From: ripemat at omni.poc.net (Anatole Shaw)
Date: Wed, 17 Apr 2013 18:51:46 +0200
Subject: [mat-wg] Measuring IP address hijacking with RIPE Atlas?
In-Reply-To: <3E37DF0F-FDA3-44C7-8B40-44E1F00D836E@bbn.com>
References: <20130417140118.GI2200@topset.berm.ch>
<3E37DF0F-FDA3-44C7-8B40-44E1F00D836E@bbn.com>
Message-ID: <20130417165146.GG856@topset.berm.ch>
On Wed, Apr 17, 2013 at 11:24:42AM -0400, Richard Barnes wrote:
> However, it's not clear to me how Atlas could help measure hijacking. Atlas is an active measurement network. What sort of probes would detect a hijack?
If you look at the behavior of a service on a remote host from the
vantagepoint of network A, and that behavior is especially distinct from
how it appears from network B, then you can infer that it's not the same
remote host. Aside from the possibility that it's an anycast address
reaching differently-configured hosts, this would serve as an indicator
of a hijack. More or less an automated version of what we did at
Greenhost to unravel the hijacked Spamhaus name server case.
When I talk about "behavior" I'm including everything under the umbrella
of OS fingerprinting, network service fingerprinting, etc.
And I think there are plenty more possibilities besides.
> I wonder if analyzing some of RIPE's passive data sets might be a better approach.
Likely also a valuable approach.
Regards,
Anatole
From rbarnes at bbn.com Thu Apr 18 16:10:19 2013
From: rbarnes at bbn.com (Richard Barnes)
Date: Thu, 18 Apr 2013 10:10:19 -0400
Subject: [mat-wg] Measuring IP address hijacking with RIPE Atlas?
In-Reply-To: <20130417165146.GG856@topset.berm.ch>
References: <20130417140118.GI2200@topset.berm.ch>
<3E37DF0F-FDA3-44C7-8B40-44E1F00D836E@bbn.com>
<20130417165146.GG856@topset.berm.ch>
Message-ID: <1DE72AD2-303B-4D6F-AA33-539AD08237E2@bbn.com>
On Apr 17, 2013, at 12:51 PM, Anatole Shaw wrote:
> On Wed, Apr 17, 2013 at 11:24:42AM -0400, Richard Barnes wrote:
>> However, it's not clear to me how Atlas could help measure hijacking. Atlas is an active measurement network. What sort of probes would detect a hijack?
>
> If you look at the behavior of a service on a remote host from the
> vantagepoint of network A, and that behavior is especially distinct from
> how it appears from network B, then you can infer that it's not the same
> remote host. Aside from the possibility that it's an anycast address
> reaching differently-configured hosts, this would serve as an indicator
> of a hijack. More or less an automated version of what we did at
> Greenhost to unravel the hijacked Spamhaus name server case.
>
> When I talk about "behavior" I'm including everything under the umbrella
> of OS fingerprinting, network service fingerprinting, etc.
>
> And I think there are plenty more possibilities besides.
Thanks, that actually sounds like a very interesting approach, assuming you can find proper test addresses in the relevant prefixes. (That could be hard, especially for IPv6.)
Is this sort of fingerprinting something you could do with the current Atlas UDM capability?
>> I wonder if analyzing some of RIPE's passive data sets might be a better approach.
>
> Likely also a valuable approach.
It might also be worthwhile to look at combining active and passive measurements. For example, you might observe a change in behavior in Atlas measurements, and check whether there is a change in BGP.
--Richard
>
> Regards,
>
> Anatole
>
>
From randy at psg.com Thu Apr 18 16:21:58 2013
From: randy at psg.com (Randy Bush)
Date: Thu, 18 Apr 2013 07:21:58 -0700
Subject: [mat-wg] Measuring IP address hijacking with RIPE Atlas?
In-Reply-To: <20130417165146.GG856@topset.berm.ch>
References: <20130417140118.GI2200@topset.berm.ch>
<3E37DF0F-FDA3-44C7-8B40-44E1F00D836E@bbn.com>
<20130417165146.GG856@topset.berm.ch>
Message-ID:
> When I talk about "behavior" I'm including everything under the
> umbrella of OS fingerprinting, network service fingerprinting, etc.
some folk consider these invasive
randy
From rbarnes at bbn.com Thu Apr 18 17:43:05 2013
From: rbarnes at bbn.com (Richard Barnes)
Date: Thu, 18 Apr 2013 11:43:05 -0400
Subject: [mat-wg] Measuring IP address hijacking with RIPE Atlas?
In-Reply-To:
References: <20130417140118.GI2200@topset.berm.ch>
<3E37DF0F-FDA3-44C7-8B40-44E1F00D836E@bbn.com>
<20130417165146.GG856@topset.berm.ch>
Message-ID: <00235475-6C40-4C50-BBCD-FC585F2383CC@bbn.com>
Maybe it could be set up on a voluntary basis, so that you would have to opt in to get hijack protection? That would also bound the scope of the measurements you would need, and make the fingerprinting simpler.
Notional design
1. ISP that wants to be protected publishes an IP address and a public key for a test host
2. Probe node sends a packet to test host IP address with a nonce
3. Test host responds with signature over nonce
4. Probe node knows hijack is not happening if
(1) Signature over nonce is valid under the public key, and
(2) Latency is not significantly higher
The signature would guarantee that the hijacker wouldn't be able to trivially fake responses. The latency check helps address the case where the hijacker can get real signatures from the real test host (e.g., via a peer).
I went ahead and threw a prototype up on GitHub. Only 43 lines of python!
On Apr 18, 2013, at 10:21 AM, Randy Bush wrote:
>> When I talk about "behavior" I'm including everything under the
>> umbrella of OS fingerprinting, network service fingerprinting, etc.
>
> some folk consider these invasive
>
> randy
From robachevsky at isoc.org Fri Apr 19 10:07:02 2013
From: robachevsky at isoc.org (Andrei Robachevsky)
Date: Fri, 19 Apr 2013 10:07:02 +0200
Subject: [mat-wg] Measuring IP address hijacking with RIPE Atlas?
In-Reply-To:
References: <20130417140118.GI2200@topset.berm.ch>
<3E37DF0F-FDA3-44C7-8B40-44E1F00D836E@bbn.com>
<20130417165146.GG856@topset.berm.ch>
Message-ID: <5170FB26.8060204@isoc.org>
On Apr 17, 2013, at 12:51 PM, Anatole Shaw wrote:
> On Wed, Apr 17, 2013 at 11:24:42AM -0400, Richard Barnes wrote:
>> However, it's not clear to me how Atlas could help measure hijacking.
Atlas is an active measurement network. What sort of probes would
detect a hijack?
>
> If you look at the behavior of a service on a remote host from the
> vantagepoint of network A, and that behavior is especially distinct from
> how it appears from network B, then you can infer that it's not the same
> remote host. Aside from the possibility that it's an anycast address
> reaching differently-configured hosts, this would serve as an indicator
> of a hijack. More or less an automated version of what we did at
> Greenhost to unravel the hijacked Spamhaus name server case.
I agree getting consistent data about route hijacks is important. But in
many cases a prefix hijack will result in blackholing the traffic and no
service availability at all. Besides, for the authenticity check of the
DNS service we have DNSSEC and I wonder how difficult it'd be for
Spamhaus to use it.
I heard about the idea of using RIPE Atlas for testing of the ISP
anti-spoofing capabilities, similar to what the spoofer project
(http://spoofer.csail.mit.edu/) is doing, and I like it. (Although, it
might make Atlas look too alike a botnet ;).
Andrei
From rbarnes at bbn.com Tue Apr 23 16:46:32 2013
From: rbarnes at bbn.com (Richard Barnes)
Date: Tue, 23 Apr 2013 07:46:32 -0700
Subject: [mat-wg] Preliminary agenda for MAT @ RIPE66
Message-ID: <28E93075-4D0A-4F73-83F2-EFCC266692F7@bbn.com>
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 at ripe.net.
The session will take place at 16:00 local time on Thursday 16th May.
See you in Dublin!
Richard & Christian
From mir at ripe.net Wed Apr 24 15:01:38 2013
From: mir at ripe.net (Mirjam Kuehne)
Date: Wed, 24 Apr 2013 15:01:38 +0200
Subject: [mat-wg] New on RIPE Labs: The BGP Visibility Scanner
Message-ID: <5177D7B2.5050002@ripe.net>
[apologies for duplicates]
Dear colleagues,
Please find some interesting research by Andra Lutu, Marcelo Bagnulo and
Olaf Maennel on RIPE Labs: "The BGP Visibility Scanner"
https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner
The authors developed a tool that checks if prefixes have limited
visibility. The article describes some of the results found after
analysing many months of global routing table data.
Please also note the call for feedback at the end of the article.
Kind regards,
Mirjam Kuehne
RIPE NCC
From mir at ripe.net Fri Apr 26 09:20:46 2013
From: mir at ripe.net (Mirjam Kuehne)
Date: Fri, 26 Apr 2013 09:20:46 +0200
Subject: [mat-wg] New on RIPE Labs: New Dashboard View and More New Feature
on RIPE Atlas
Message-ID: <517A2ACE.1040700@ripe.net>
Dear colleagues,
Our latest RIPE Atlas release includes a lot of new features, including
completely new opening pages on the website for logged in users and the
general public. We also have one-off measurements, APIs, new maps, probe
sharing and more! Please find all the details described here:
https://labs.ripe.net/Members/kistel/new-ripe-atlas-features-april-2013
Kind regards,
Mirjam Kuehne
RIPE NCC
From pavelveselovskiy at gmail.com Tue Apr 30 14:43:05 2013
From: pavelveselovskiy at gmail.com (Pavel V. Veselovskiy)
Date: Tue, 30 Apr 2013 16:43:05 +0400
Subject: [mat-wg] Full BGP full view
Message-ID:
Hello,
I'm validating a new technique for finding the route between autonomous
systems with the least number
of transitions. This method is came from the wireless sensor networks.
To compare the efficiency of this method, and BGP algorithms, we need a
full BGP routing table that reflects the configuration of all the
neighbors for all AS on the Internet. At first I took the BGP Full View
from O-IX site http://www.routeviews.org/
And that's specifically from herehttp://archive.routeviews.org/oix-route-views/
Already in the first few tests, it was found out that these tables are
incomplete, since a number of traceroutes, we have given from the
servers is not suitable neighbors and a method results mismatched with
the actual path, or the path is
longer than the traceroute outputs. Besides knowing the total number of
announced AS and counting the number of unique AS numbers for these log
files (http://archive.routeviews.org/oix-route-views/), we found that
these logs contains references to only about 60% of the number All
advertised by AS.
Recommend, please, where we can find a really complete picture of all
the neighboring AS?
--
Kind Regards,
Pavel Veselovskiy,
Samara State Aerospace University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.ripe.net/ripe/mail/archives/mat-wg/attachments/20130430/b27c73b7/attachment.html
From sebastian at nzrs.net.nz Tue Apr 30 22:18:44 2013
From: sebastian at nzrs.net.nz (Sebastian Castro)
Date: Wed, 01 May 2013 08:18:44 +1200
Subject: [mat-wg] Full BGP full view
In-Reply-To:
References:
Message-ID: <51802724.7000601@nzrs.net.nz>
On 01/05/13 00:43, Pavel V. Veselovskiy wrote:
> Hello,
Hi,
>
> I'm validating a new technique for finding the route between autonomous
> systems with the least number
> of transitions. This method is came from the wireless sensor networks.
>
> To compare the efficiency of this method, and BGP algorithms, we need a
> full BGP routing table that reflects the configuration of all the
> neighbors for all AS on the Internet. At first I took the BGP Full View
> from O-IX site http://www.routeviews.org/
> And that's specifically from here
> http://archive.routeviews.org/oix-route-views/
>
> Already in the first few tests, it was found out that these tables are
> incomplete, since a number of traceroutes, we have given from the
> servers is not suitable neighbors and a method results mismatched with the actual path, or the path is
> longer than the traceroute outputs. Besides knowing the total number of
> announced AS and counting the number of unique AS numbers for these log
> files (http://archive.routeviews.org/oix-route-views/), we found that
> these logs contains references to only about 60% of the number All
> advertised by AS.
>
I've came across the same issue while doing some research for CAIDA. You
have to bear in mind the locations where the BGP dumps are taken are
"vantage point", so you will get a view of the network from that point.
If you collect enough vantage point, you will reach a state when you can
"see" mostly everything.
What I did at that time was combine various sources from RouteViews and
RIPE RIS (http://www.ripe.net/data-tools/stats/ris/ris-raw-data) until
reaching an acceptable level of coverage.
> Recommend, please, where we can find a really complete picture of all
> the neighboring AS?
>
Cheers,
> --
> Kind Regards,
> Pavel Veselovskiy,
> Samara State Aerospace University
>
--
Sebastian Castro
DNS Specialist
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 495 2337
mobile: +64 21 400535