- mat-wg - mailman.ripe.net

Re: [mat-wg] Using Atlas for commercial services
by Alex Saroyan 06 Sep '13

06 Sep '13

Instead, commercial companies will start hosting many probes in single room not for sake of community but for sake of getting credits. /Alex Saroyan Stephane Bortzmeyer <bortzmeyer(a)nic.fr> wrote: >On Fri, Sep 06, 2013 at 11:04:44AM +0200, > Peter Koch <pk(a)DENIC.DE> wrote > a message of 11 lines which said: > >> but don't forget credit transfers, even if that doesn't change the >> sum. > >You can get credits through a transfer easily when you are a poor >student having an interesting research project. But I assume >commercial companies selling services over Atlas won't have credits >easily for free :-) >

1 0

New on RIPE Labs: The Seismograph and Other New RIPE Atlas Features
by Mirjam Kuehne 06 Sep '13

06 Sep '13

Dear colleagues, We implemented a number of new features in RIPE Atlas, including the seismograph, an interactive tool to easily visualise multiple ping measurements. Please find more information on RIPE Labs: https://labs.ripe.net/Members/becha/seismograph-and-other-new-ripe-atlas-fe… Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: New RIPEstat Website
by Mirjam Kuehne 28 Aug '13

28 Aug '13

Dear colleagues, We've revamped the RIPEstat website to make it easier to find information. Please read more on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/new-ripestat-website Kind regards, Mirjam

1 0

RIPE 67 CFP extended deadline 9 September 2013
by Benno Overeinder 26 Aug '13

26 Aug '13

Dear Colleagues, A list of currently accepted RIPE 67 Plenary talks, BoFs, Tutorials and Workshops is now published at: https://ripe67.ripe.net/programme/meeting-plan/draft-programme/ There are still few slots remaining for a final RIPE 67 programme and RIPE Programme Committee will accept new proposals until *9 September 2013*. This is our last call for you to submit your proposals. See https://ripe67.ripe.net/programme/cfp/ or find the original CFP below. Kind regards Filiz Yilmaz for RIPE Programme Committee ------------------ 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 67 will take place from 14-18 October 2013 in Athens, Greece. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary session presentations, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 67. 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 centre technologies * Network and DNS operations * Internet governance and regulatory practices * Network and routing security * Content delivery * Internet peering and mobile data exchange 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. The RIPE PC accepts proposals for different presentation formats, including plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. See the full descriptions of these formats at https://ripe67.ripe.net/programme/i-want-to-present/presentation-formats/ 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 general requirements apply: * Proposals for plenary session presentations, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 4 August 2013, using the meeting submission system (https://ripe67.ripe.net/submit-topic/) Proposals submitted after this date will be considered on a space-available basis. * Lightning talks should also be submitted using the meeting submission system (https://ripe67.ripe.net/submit-topic/) and can be submitted just days before the RIPE Meeting starts or even during the meeting week. The allocation of lightning talk slots will be announced in short notice - in some cases on the same day but often one day prior to the relevant session. * Presenters should indicate how much time they will require. See more information on time slot allocations per presentation format (https://ripe67.ripe.net/programme/i-want-to-present/presentation-formats/) * 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 panels, proposals must contain a clear description, as well as the names of invited panelists, presenters and moderators. * Due to potential technical issues, it is expected that most, if not all, presenters/panelists will 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

Accessing Routing Information Via RIPEstat
by Vesna Manojlovic 23 Aug '13

23 Aug '13

Dear colleagues, Our Routing Information Service (RIS) has been collecting global BGP routing information for 12 years now. During this period, many different interfaces to analyse and visualise accumulated data have been developed. In line with our long-term goals to provide more consolidated services, we will be integrating the RIS interface's tools and services into RIPEstat. More information about this is detailed in a new RIPE Labs article: https://labs.ripe.net/Members/fatemah_mafi/improved-routing-information-ava… We invite the community to comment on these upcoming changes: https://www.ripe.net/ripe/groups/wg/mat Please submit any urgent requests for additional features via email to stat(a)ripe.net by 20 September 2013 so that we can implement these along with the planned migration of tools and features. Any feedback received after this date will be considered feature requests, and added to the RIPEstat Roadmap: http://roadmap.ripe.net/ripe-stat/ We look forward to your feedback. Regards, Vesna -- Vesna Manojlovic BECHA(a)ripe.net Senior Community Builder @Ms_Measurements for Measurements Tools RIPE NCC http://ripe.net

1 0

Future of RIPE NCC technical services
by Kaveh Ranjbar 20 Aug '13

20 Aug '13

Dear colleagues, In June of this year, I took on a new role at the RIPE NCC and joined the Senior Management team as Chief Information Officer (a role formerly called Head of Science Division). Since that time, I've had a chance to review the technical services we provide to the community, and I’d like to share with you some of my ideas about the planned future direction of these services. To summarise, these plans include: - Focusing on RIPE Atlas as the RIPE NCC’s data collection system - Developing RIPEstat as the RIPE NCC's consolidated point for data retrieval - Service agreements and other plans for hosted services like K-root, authoritative DNS servers and RIS data collectors - A greater focus on data analysis We believe the plans we have in place will allow you to access our services more easily and efficiently, and make better use of the data we collect. You can read the full details on RIPE Labs: https://labs.ripe.net/Members/kranjbar/future-of-ripe-ncc-technical-services I hope you'll take the time to read the full article and learn more about the planned future direction of our services. As always, we invite your comments and suggestions, which you can leave in the comments field of the article, or by contacting me directly at kranjbar(a)ripe.net. Our top priority is ensuring we provide you with the most useful services and data possible, and I look forward to hearing your thoughts. Best regards, Kaveh Ranjbar Chief Information Officer RIPE NCC

1 0

Re: [mat-wg] [atlas] RIPE Atlas maintenance on Tuesday, 6 August
by Robert Kisteleki 06 Aug '13

06 Aug '13

Dear All, This work is now done and we believe everything is back to normal (*). Please let us know (preferably via atlas-bugs(a)ripe.net) if you find something not working. Regards, Robert Kisteleki (*) independently of this maintenance, one of the data servers (zpm01) is having some hardware issues, which causes data downloads and RRDs for probes 1-499 to be flaky. We're working on this. On 2013.07.30. 12:19, Robert Kisteleki wrote: > > Dear RIPE Atlas users, > > We'd like to let you know that we plan to perform scheduled maintenance on > the RIPE Atlas central infrastructure on Tuesday, 6 August, for a couple of > hours during the day. In this period, main features including the RIPE Atlas > user interface (atlas.ripe.net) data downloads and measurement scheduling > functions will be unavailable. > > Probes will continue to work and all results will still be collected or > buffered; however, during the maintenance period you will be unable to log > in to the website, manage your probes/measurements, or get to result > data/visualisations. > > We apologise for any inconvenience this may cause. > > Regards, > Robert Kisteleki > >

1 0

RIPE Atlas maintenance on Tuesday, 6 August
by Robert Kisteleki 31 Jul '13

31 Jul '13

Dear RIPE Atlas users, We'd like to let you know that we plan to perform scheduled maintenance on the RIPE Atlas central infrastructure on Tuesday, 6 August, for a couple of hours during the day. In this period, main features including the RIPE Atlas user interface (atlas.ripe.net) data downloads and measurement scheduling functions will be unavailable. Probes will continue to work and all results will still be collected or buffered; however, during the maintenance period you will be unable to log in to the website, manage your probes/measurements, or get to result data/visualisations. We apologise for any inconvenience this may cause. Regards, Robert Kisteleki

1 0

Re: [mat-wg] [atlas] Spoofing the source IP address from a probe?
by Andrei Robachevsky 30 Jul '13

30 Jul '13

Alex Saroyan wrote on 7/18/13 8:53 AM: > Hi, > > I think some hosts would like theirs probes to be used for "source IP > spoofing" check, and only such probes could be used for this particular > type of check. > If RIPE Atlas team implement such features then probably many hosts will > "enable" "Source IP spoofing check ability" on theirs probes and that > can serve for community at the end. I support this point of view. I think controlled (anti-)spoofing measurements performed by the RIPE NCC with the consent of participating probes would be a good service to the community. I understand that a certain percentage of probes is sitting behind NAT where spoofing won't work in most cases, but there is hopefully a significant number of probes that are connected directly. Regarding the problem itself we are tackling here, we published a follow up to the panel we held at RIPE66: http://www.internetsociety.org/doc/anti-spoofing-continuing-dialogue. Hope this helps raising awareness of the issue further. > Of course overall mechanism should be in a way not make anyone to > suspect that probe can do spoofing by default or probe can do any > harmful thing. > Agree, Andrei > Alex Saroyan > > On 06/12/2013 10:37 PM, Daniel Karrenberg wrote: >> On 12.06.2013, at 17:44 , Joe Provo <jzp-ripe(a)rsuc.gweep.net> wrote: >> >>> I would encourage those in the community who wish to be >>> performing individual spoof testing (or instruct others how >>> to do so) to use the easy-peasey pointy-clicky CAIDA/CSAIL >>> tool: http://spoofer.cmand.org/ >>> (also spoofer.csail.mit.edu, spooftest.net, etc etc) >> Seconded. Using this something like this is a conscious decision of >> the user. I have personally run Robert Beverley's probes regularly for >> many years and I am proud to say that both my broadband providers have >> never allowed source address spoofing. This involves a conscious >> decision on my part taking into account local network etiquette, my >> relation to my providers and the local legal situation. It is very >> very different from the RIPE community deciding to use RIPE Atlas to >> do this from my network. >> >> Daniel > >

2 2

Re: [mat-wg] [atlas] Spoofing the source IP address from a probe?
by Alex Saroyan 30 Jul '13

30 Jul '13

Hi, Probably we don't need to spoof all address space, instead only if spoofing enabled just spoof to some predefined address range. Regards. /Alex Sanjeev Gupta <ghane0(a)gmail.com> wrote: >On Tue, Jul 30, 2013 at 11:22 AM, Randy Bush <randy(a)psg.com> wrote: > >> I support this point of view. I think controlled (anti-)spoofing >> measurements performed by the RIPE NCC with the consent of >> participating probes would be a good service to the community. > >perhaps the probe owners are not the only parties with skin in the game >and whose consent would be relevant? > > >Exactly. I host probes, and since you are spoofing others, we need to ask them. > >How you do this is left as an exercise to the reader. > >-- >Sanjeev Gupta >+65 98551208 http://www.linkedin.com/in/ghane > > >

1 0

Atlas UDMs and Probe-Assignments
by Gert Doering 26 Jul '13

26 Jul '13

Hi, I'm wondering about something, maybe one of you can enlighten me here. I have set up a few UDMs (... to eventually get out of Atlas what we had with TTM). A small one with only 10 probes is now showing that actually only 7 probes return data - two more have returned data at some point in the past - "Jul 06, 06:11" in one case - while the 10th assigned problem seems to have never sent anything. (This is UDM 1002000, the "dead" probe is #2760 in AS 3292). The question coming from this is: how do probes get assigned to UDMs, and will dead probes get replaced eventually? Or is the assignment done statically at the beginning of the UDM? The reason why this is relevant: if I am going to set up UDMs to replace what TTM does, the idea is to have a reasonable high number of probes, say "50" or "100", and define our Internet reliability as "more than 2/3rd of the UDM probes have been answered without loss", or something like that - taking into account that somewhere on the Internet, things will always be broken, but that's not our responsibility. This falls apart of probes deteriorate after a given time, and a given UDM measurement will use "less and less probes" (so in the extreme, of the 50 initial probes, 30 might be "dead probe" and thus the result is always "0% reliability, more than 50% of the probes can not reach us"), instead of the system keeping the requested number of probes by replacing dead ones... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

2 4

Atlas UDM and API keys?
by Gert Doering 25 Jul '13

25 Jul '13

Hi, maybe it's too hot today, maybe I'm a bit slow, but just how do I combine the Atlas UDM download links and the API KEY to form a "download will just work" URL? The download URL I want to use is https://atlas.ripe.net/api/v1/measurement/1002000/result/?start=1373972036&… so where does the API key go? Adding "?key=<key data>" or "?apikey=..." or "just the key with no tag" didn't work... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

1 1

New on RIPE Labs: In-widget Comparison and Monitoring in RIPEstat
by Mirjam Kuehne 24 Jul '13

24 Jul '13

Dear colleagues, You can now monitor network events in real time in two RIPEstat widgets: Country Routing Statistics and BGP Update Activity. And we would like to hear from you for which widgets we should provide this functionality next. Please find more details on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/new-in-ripestat-in-widg… Kind regards, Mirjam Kuehne RIPE NCC

1 0

Call for Papers: RIPE 67, 14-18 October 2013 in Athens, Greece
by Benno Overeinder 23 Jul '13

23 Jul '13

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 67 will take place from 14-18 October 2013 in Athens, Greece. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary session presentations, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 67. 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 centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange 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. The RIPE PC accepts proposals for different presentation formats, including plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. See the full descriptions of these formats at https://ripe67.ripe.net/programme/i-want-to-present/presentation-formats/ 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 general requirements apply: - Proposals for plenary session presentations, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 4 August 2013, using the meeting submission system (https://ripe67.ripe.net/submit-topic/) Proposals submitted after this date will be considered on a space-available basis. - Lightning talks should also be submitted using the meeting submission system (https://ripe67.ripe.net/submit-topic/) and can be submitted just days before the RIPE Meeting starts or even during the meeting week. The allocation of lightning talk slots will be announced in short notice - in some cases on the same day but often one day prior to the relevant session. - Presenters should indicate how much time they will require. See more information on time slot allocations per presentation format (https://ripe67.ripe.net/programme/i-want-to-present/presentation-formats/) - 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 panels, proposals must contain a clear description, as well as the names of invited panelists, presenters and moderators. - Due to potential technical issues, it is expected that most, if not all, presenters/panelists will 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

PORTOLAN: A Mobile Crowdsourcing Measurement System
by Luciano Lenzini 08 Jul '13

08 Jul '13

Dear All, The University of Pisa and IIT, an Institute of the Italian National Research Council, have developed a mobile crowdsourcing-based system, named PORTOLAN which uses smartphones as mobile monitors probing the Internet and reporting results to a central server located in Pisa. The aim of PORTOLAN is to enhance the current topology of the Internet at the Autonomous System level of abstraction - all with the contribution of volunteers. The PORTOLAN component that runs on smartphones is now available as an app for the Android platform. It can be downloaded by users from Google play ( <https://play.google.com/store/apps/details?id=it.unipi.iet.portolan.tracero ute> https://play.google.com/store/apps/details?id=it.unipi.iet.portolan.tracerou te). PORTOLAN works in the background, it is designed not to interfere in any way with users' activities and does not affect the smartphone's overall performance. In order to motivate users to contribute to the PORTOLAN project, we have added several services, which include diagnostic network tools (such as Ping, Paris Traceroute with Multipath Detection Algorithm, Maximum Throughput achievable along a path, etc.) and coverage measurement tools. All the tools are totally under the user's control. Data collected by these tools are stored in our servers, in a completely anonymous way. For details see <http://portolan.iet.unipi.it/> http://portolan.iet.unipi.it/. The success of our experiment depends upon the number of users who join the experiment. But to get people to download the app, we really need to raise as much awareness as possible regarding the PORTOLAN itself. So I would like to ask you if it would be possible for you to forward this message to your colleagues, students and anyone else who you think might be interested. Many thanks in advance for your cooperation. All the best, Luciano TECHNICAL NOTE: In PORTOLAN, each smartphone issues at max 200 traceroutes per day, which means a peak traffic rate never higher than 1 KB/s and an average traffic rate never higher than 2 MB/day. The impact of these activities on the battery consumption is negligible. Signal coverage measurements are completely costless in terms of energy or bandwidth, as the PORTOLAN app passively collects signal strength samples using GPS positions generated by other apps. You have to activate the GPS yourself if you want a coverage map along your route. Given that your route could be up to 50 km or more, then you will obviously use up quite a bit of your battery power. So if you are travelling, then connect your smartphone to a powersource in your car or in the train. In any case, if the battery level goes under 40%, PORTOLAN is automatically suspended. -------------------------------------------------------------- Prof. Luciano Lenzini Department of Information Engineering University of Pisa, Italy e-mail: l.lenzini(a)iet.unipi.it http://www.iet.unipi.it/~lenzini

1 0

New on RIPE Labs: Are All Addresses Equal? (by Stephane Bortzmeyer)
by Mirjam Kuehne 03 Jul '13

03 Jul '13

Dear colleagues, Stephane Bortzmeyer describes another use case for RIPE Atlas: Are IPv4 addresses in which the last byte is zero treated differently than other IPv4 addresses? See his study on RIPE Labs: https://labs.ripe.net/Members/stephane_bortzmeyer/all-ip-addresses-are-equa… Kind regards, Mirjam Kuehne RIPE NCC

1 0

RIPE Atlas Mid-summer community update
by Vesna Manojlovic 01 Jul '13

01 Jul '13

Der colleagues, RIPE Atlas community has been very active recently. I summerized it (ha! pun intended) in the RIPE Labs article, highlighting new community related features for RIPE Atlas anchor hosts, sponsors and "ambassadors". And the article has lots of pretty pictures! Share and enjoy! Warm regards, Vesna https://labs.ripe.net/Members/becha/ripe-atlas-midsummer-2013-community-upd…

1 0

New on RIPE Labs: RIPEstat's Multiple Widget and Resource Comparison
by Mirjam Kuehne 24 Jun '13

24 Jun '13

Dear colleagues, RIPEstat users can now compare results for multiple resources across multiple widgets in a new comparison page - and share the results with others using the permalink feature. In this new article on RIPE Labs we describe several use cases where this new functionality might come in handy: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripestats-multiple-widg… Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: Measuring IPv6 Capability of RIPE Atlas Probes
by Mirjam Kuehne 12 Jun '13

12 Jun '13

Dear colleagues, Please see a new article on RIPE Labs contributed by Stephane Bortzmeyer: How Many RIPE Atlas Probes Believe They Have IPv6 (But Are Wrong)? https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-atlas-probes-bel… Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: RIPEstat Demo Summary
by Mirjam Kuehne 21 May '13

21 May '13

Dear colleagues, For those of you who missed the RIPEstat demo at the recent RIPE 66 meeting, please find a summary on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripestat-demo-summary-r… Kind regards, Mirjam Kuehne RIPE NCC

1 0

[Fwd: Community suggestion for ATLAS spoof test]
by Vesna Manojlovic 21 May '13

21 May '13

Dear colleagues, please take a look at the suggestion from Alexander Isavnin. Since he is here in Dublin, we can talk about it during MAT-WG or, if there is not enough time, at the RIPE Atlas community BoF. However, the opinion of the rest of the community counts too, so I ask you to comment on the mailing list, if you are interested. Regards, Vesna -------- Original Message -------- Subject: Community suggestion for ATLAS spoof test Date: Wed, 15 May 2013 21:16:30 +0200 From: Alexander Isavnin <isavnin(a)netline.ru> To: Vesna Manojlovic <BECHA(a)ripe.net> Dear Vesna! Could you forward this suggestion to mat-wg mailing list (and other appropriate lists). Due to high requirements to mitigate spoofing there is need to detect one. RIPE community have great distributed networking tool - ATLAS. As first step i suggest to select address from RIPE NCC network and allow all probes (if probe is not behind NAT) to send spoofed packet with this address as source. As first and a half step - allow to send packets with source addresses of anchors (if anchor's host agrees) As second step - allow probe host to permit use his address as spoofed source. Best regards, Alexander Isavnin

6 5

Re: [mat-wg] [Fwd: Community suggestion for ATLAS spoof test]
by k claffy 20 May '13

20 May '13

From: Antoin Verschuren <antoin.verschuren(a)sidn.nl> If all we want to know is an oversight of the state of spoofing now, and in a year's time, can't we just ask the Atlas users (AKA the mailinglist) that want to know to do a 1 time spoofing test on http://spoofer.csail.mit.edu/summary.php from their atlas probe network? IMHO that is less work than to ask Atlas users for permission. Antoin, Thanks for suggesting that, we agree that Atlas nodes are a terrific way to increase the scope of visibility of spoofing. I should note that we have spent the last few months updating the 7-year old spoofer code and web site (btw, it's now at http://spoofer.cmand.org/ , jointly managed by Rob Beverly at nps.edu and CAIDA) including adding tests for IPv6 spoofing ability, making graphs on the summary page clearer, classifying spoofing-capable networks into types, and allowing probing to multiple (CAIDA Ark) destintations (which also increases visibility into spoofing, but not nearly as much as 1000+ Atlas nodes would..) we plan to deploy and announce an updated version by 1 June. so if you're going to encourage Atlas nodes to try our spoofer test, it would be ideal to have them do it shortly after 1 June. we will send an announcement to this list when we release the new version. after june we will still be working on better techniques to filter tests for representativeness, and other methodology improvements. please do send us requests for other changes/additions you would like to see. ( http://spoofer.cmand.org/contact.php ) thanks, k (and Rob Beverly and Ryan Koga, current team)

1 0

New on RIPE Labs: RIPE Atlas Code for Analysis and Statistics Reporting
by Mirjam Kuehne 13 May '13

13 May '13

Dear colleagues, We are releasing the code we use to analyse RIPE Atlas measurements and produce summary statistics. This will make processing these measurement results easier for the community. We're also inviting you to participate in improving this further. Please find more information on RIPE Labs: https://labs.ripe.net/Members/wilhelm/ripe-atlas-code-for-analysis-and-stat… Kind regards, Mirjam Kuehne RIPE NCC

1 0

[Fwd: [ipv6-wg] New on RIPE Labs: Implementing Fifth Start IPv6 RIPEness]
by Vesna Manojlovic 13 May '13

13 May '13

Sorry for the cross-posting -- I think the IPv6 measurements that we are doing for the 5th star in IPv6 RIPEness are of interest to MAT-WG. I'll be presenting about this at IPv6-WG in Dublin, and if there is interest & questions from this group I can mention it too. Regards, Vesna -------- Original Message -------- Subject: [ipv6-wg] New on RIPE Labs: Implementing Fifth Start IPv6 RIPEness Date: Mon, 13 May 2013 07:09:34 +0200 From: Mirjam Kuehne <mir(a)ripe.net> To: ipv6-wg(a)ripe.net Dear colleagues, In this new article on RIPE Labs we present the first results of a fifth star for IPv6 RIPEness. This is a way to measure real IPv6 deployment in the RIPE NCC service region: https://labs.ripe.net/Members/emileaben/ipv6-ripeness-implementing-the-5th-… We would like to receive your feedback on a number of open question raised in the article. We also hope to see many of you at the IPv6 WG meeting in Dublin later this week where these results will be presented. Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: BGPlay now integrated in RIPEstat
by Mirjam Kuehne 08 May '13

08 May '13

[apologies for duplicates] Dear colleagues, We are proud to present a newly revamped version of the well-known BGPlay tool. It is now integrated into RIPEstat and was developed in partnership with the Compunet Research Lab of Roma Tre University. Please find more information on RIPE Labs: https://labs.ripe.net/Members/vastur/bgplay-v2-integrated-in-ripestat Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: Introduction of RIPE Atlas Quick Looks
by Mirjam Kuehne 07 May '13

07 May '13

[apologies for duplicates] Dear colleagues, A new RIPE Atlas feature is now available to RIPE NCC members: Quick Look measurements. Members can use this service for a quick, real-time assessment of connectivity without hosting a RIPE Atlas probe. This feature is based on one-off measurements that are available to all RIPE Atlas probe hosts. Please find more information on RIPE Labs: https://labs.ripe.net/Members/kistel/ripe-atlas-quick-look-for-members Kind Regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: Releasing RIPE Atlas Measurements Source Code
by Mirjam Kuehne 06 May '13

06 May '13

Dear colleagues, This new article on RIPE Labs introduces the RIPE Atlas measurement source code. The measurement code is the part that runs on the RIPE Atlas probes to schedule and execute particular measurements, and thereby forms the core of the RIPE Atlas system. https://labs.ripe.net/Members/philip_homburg/ripe-atlas-measurements-source… Kind regards, Mirjam Kuehne RIPE NCC

1 0

More roadmaps added to RIPE NCC Roadmap
by Mirjam Kuehne 06 May '13

06 May '13

Dear colleagues, We added roadmaps for DNSMON and RIPEstat to the RIPE NCC Roadmap: htps://roadmap.ripe.net Please let us know if you find this useful or if you have any questions or suggestions. Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: Using RIPE Atlas to find most popular DNS anycast instances
by Mirjam Kuehne 03 May '13

03 May '13

Dear colleagues, Please find a new article on RIPE Labs, contributed by Stephane Bortzmeyer: Using RIPE Atlas User Defined Measurements to Find the Most Popular Instances of a DNS Anycast Name Server https://labs.ripe.net/Members/stephane_bortzmeyer/using-atlas-udm-to-find-t… Kind regards, Mirjam Kuehne RIPE NCC

1 0

Re: [mat-wg] Full BGP full view
by Pietro Marchetta 02 May '13

02 May '13

Dear, while a complete and exhaustive view of the BGP global routing would be a milestone for the whole networking research, all the available datasets provide just a partial view, since, as already pointed out by Sebastian Castro, the current datasets are typically obtanied through a set of vantage points with a limited visibility. You might find a recent and well-done analysis on the incompleteness of the BGP view as well as the root causes in this paper: Enrico Gregori, Alessandro Improta, Luciano Lenzini, Lorenzo Rossi, and Luca Sani. On the incompleteness of the AS-level graph: a novel methodology for BGP route collector placement. IMC 2012 At the same time, there several severe sources of inaccuracy to take into account when you use Traceroute to infer the AS level topology/transitions/neighborhood. A good starting reference in this case could be the following paper: Yu Zhang, Ricardo V. Oliveira, Hongli Zhang, Lixia Zhang. Quantifying the Pitfalls of Traceroute in AS Connectivity Inference. PAM 2010 Furthermore, we have recently demonstrated how Third-party addresses cause the inference of a significant percentage of false AS-level links and bogus AS-level loops when Traceroute is used to investigate the AS level connectivity. While this specific limitation has been largely ignored, you may find many more details in this paper: Pietro Marchetta, Walter de Donato, Antonio Pescapé. Detecting Third-party Addresses in Traceroute Traces with IP Timestamp Option. PAM 2013. I hope this helps. Best regards. Pietro Marchetta 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 -- Pietro Marchetta, PhD student Dipartimento di Ingegneria Elettrica e delle Tecnologie dell'Informazione University of Napoli ''Federico II'' Via Claudio, 21 - 80125, Napoli (Italy) WebSite: http://wpage.unina.it/pietro.marchetta Phone: +390817683821 - Fax: +390817683816

2 1

Full BGP full view
by Pavel V. Veselovskiy 30 Apr '13

30 Apr '13

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

2 1

New on RIPE Labs: New Dashboard View and More New Feature on RIPE Atlas
by Mirjam Kuehne 26 Apr '13

26 Apr '13

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

1 0

New on RIPE Labs: The BGP Visibility Scanner
by Mirjam Kuehne 24 Apr '13

24 Apr '13

[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

1 0

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

Phase 1 of RIPE Atlas Anchors pilot - report on RIPE Labs
by Vesna Manojlovic 15 Feb '13

15 Feb '13

Dear community, [apologies for the duplicates] we just published an article on RIPE Labs with the status & features available for the hosts of RIPE Atlas Anchor boxes after the Phase 1: https://labs.ripe.net/Members/becha/ripe-atlas-anchors-pilot-update-on-phas… Share and enjoy :) Vesna

1 0

New on RIPE Labs: Country Specific Graphs in RIPEstat
by Mirjam Kuehne 06 Feb '13

06 Feb '13

[apologies for duplicates] Dear colleagues, We developed additional functionality in RIPEstat that shows various datasets by country. A new widget called Country Routing Statistics is now available, along with the ability to compare the situation in different countries side by side. Please find more details on RIPE Labs: https://labs.ripe.net/Members/cteusche/country-specific-graphs-in-ripestat Kind regards, Mirjam Kuehne RIPE NCC

1 0

New RIPE Atlas features released in January, and other news
by Vesna Manojlovic 01 Feb '13

01 Feb '13

Dear colleagues, today's RIPE Labs article describes new release of RIPE Atlas, as well as other community news: https://labs.ripe.net/Members/becha/ripe-atlas-january-2013-achievements Looking forward to hear from you, regards, Vesna -- Vesna Manojlovic BECHA(a)ripe.net Senior Community Builder @Ms_Measurements for Measurements Tools RIPE NCC http://ripe.net

1 0

New on RIPE Labs: Access RIPE Atlas via LIR Portal
by Mirjam Kuehne 22 Jan '13

22 Jan '13

[apologies for duplicates] Dear colleagues, You can now access RIPE Atlas via the LIR Portal. Please find more information on RIPE Labs: https://labs.ripe.net/Members/becha/ripe-atlas-via-lir-portal Kind Regards, Mirjam Kuehne RIPE NCC

1 0

RIPE Atlas in 2012: achievements and acknowledgments
by Vesna Manojlovic 16 Jan '13

16 Jan '13

Dear colleagues, thanks to the involvement of RIPE Atlas community, we have reached many milestones this year, and enabled RIPE NCC membership, and Internet community to use RIPE Atlas in order to measure speed and performance of their networks, and to look at the "health of the Internet" in this eventful year. We are grateful to the members, hosts, sponsors and all users. Please see the story of the RIPE Atlas achievements in this RIPE Labs article: https://labs.ripe.net/Members/becha/ripe-atlas-2012-a-year-in-review Regards, Vesna -- Vesna Manojlovic BECHA(a)ripe.net Senior Community Builder @Ms_Measurements for Measurements Tools RIPE NCC http://ripe.net

1 0

New on RIPE Labs: RIPEstat 2012 Year in Review
by Suzanne Taylor Muzzin 07 Jan '13

07 Jan '13

Dear colleagues, Please find on RIPE Labs a review of all the developments that took place with RIPEstat during 2012: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripestat-2012-year-in-r… This includes new widgets developed, the new user interface, the new text service, better data integration, improved functionality and more. In addition, we give a sneak peak of the developments we'll be working on during 2013. Kind regards, Suzanne Taylor Muzzin RIPE NCC

1 0

Deadline Extension: TRAC 2013 4th International Workshop on Traffic Analysis and Classification
by Sandrine VATON 29 Dec '12

29 Dec '12

******************************************************************************* CALLFORPAPERS ******************************************************************************* TRAC2013 4th International Workshop on TRaffic Analysis and Classification IEEE sponsored July 1-5, 2013, Cagliari, Italy http://netgroup.iet.unipi.it/trac2013 co-located with IWCMC 2013 (http://iwcmc.org/2013/) CALLFORPAPERS Brief description ----------------- The evolution of the Internet in the last few years has been characterized by dramatic changes to the way users behave, interact and utilize the network. The rapid introduction of new categories of applications such as network games and peer-to-peer, the increasing presence of malicious traffic, and the widespread use of encryption techniques, make the measurement, analysis and classification of Internet traffic a challenging task. The research community and many network operators are responding to these changes by designing and deploying traffic measurement and classification architectures of increasing complexity. Such activities are pivotal for researchers, developers, service managers and providers, as well as for end users involved in the evolution of the networks. Traffic classification and analysis mechanisms belong to the wide set of tools that helps the allocation, control and management of resources in IP networks. Following the development and the evolution of Internet applications, new efficient classification techniques are highly desirable to support advanced capabilities as regards network monitoring, network resource management, anomaly detection, and network auditing. This workshop is intended to serve as a forum for scientists and engineers in academia and industry to exchange and discuss their experiences and research results about all aspects of traffic classification and analysis. Topics of interest ------------------ The workshop is soliciting high quality papers discussing original and innovative experimental activities, unpublished and not currently submitted for publication elsewhere, on topics, including but not limited to, the following: # Traffic classification algorithms and techniques # Detection, analysis, and classification of network anomalies # Distributed algorithms for anomaly detection # Platforms for on-line, real-time traffic classification # Comparisons among traffic classification techniques # Privacy-preserving classification techniques # Identification and classification of encrypted traffic # Classification algorithms for anomaly detection # Impact of sampling on network traffic classification # Applications of traffic classification # Data-reduction techniques for traffic traces # Anonymization tools and their effects on traffic classification # Traffic measurements, analysis and modeling # Packet classification at ultra-high link rates (terabits) # Fast table look-up # Internet measurements and accounting support in switches/routers # Advanced algorithms for deep packet inspection at high speed # High speed packet processing Important Dates --------------- Papers submission deadline: December 15, 2012 Notification of decision: March 15, 2013 Camera-ready deadline: April 1, 2013 Instructions for Authors ------------------------ Perspective authors are invited to submit using the EDAS system a full paper of not more than six (6) IEEE style pages including results, figures and references. Papers will be reviewed with the standard reviewing procedure. Accepted papers will be published on IEEE Digital Library. TRAC2013 co-Chairs -------------------------------------- Christian Callegari, University of Pisa, Italy (christian.callegari(a)iet.unipi.it <mailto:christian.callegari@iet.unipi.it>) Sandrine Vaton, Telecom Bretagne, France (Sandrine.Vaton(a)telecom-bretagne.eu <mailto:Sandrine.Vaton@telecom-bretagne.eu>) -- Dr Sandrine VATON Maître de Conférences (HDR) Institut Mines-Télécom, Télécom Bretagne Brest, France Téléphone: +33 2 29 00 10 29 http://perso.telecom-bretagne.eu/sandrinevaton

1 0