- mat-wg - mailman.ripe.net

Traceroute visualisation
by Mike Hughes 18 Oct '13

18 Oct '13

Good talk by Emile on visualisation of traceroutes and the various sources of geo-loc that can be munged and derived to try and give more accurate info. While there was talk of commercial geo-loc such as Maxmind, what about mining the DNS for LOC records? Has there been any investigation of that? Or am I just an ossified dinosaur, talking about LOC records? :) Cheers, Mike

5 4

Ambient measurements
by Richard Barnes 18 Oct '13

18 Oct '13

Hey all, As a follow-up to Mikael's point in AOB at the MAT meeting today (that there are lots of statistics already being kept by hosts, e.g., in TCP stacks): I did a presentation at the IEPG back at the Beijing IETF about the idea of standardizing a "Network Measurement Reporting" language, so that things like ping and traceroute could share their results with the rest of the Internet. <http://iepg.org/2010-11-ietf79/NMR-IEPG.pdf> It's long enough ago that I don't remember precisely what the feedback was. But no further work got done, so it probably wasn't that positive :) Nonetheless, I continue to think that collecting ambient measurement data is a really interesting idea, so it would be cool to hear what others here think. Cheers, --Richard

2 1

Completed Migration of RIS Visualisation to RIPEstat
by Vesna Manojlovic 08 Oct '13

08 Oct '13

Completed Migration of Routing Information to RIPEstat Dear colleagues, We have now successfully completed the planned* migration of RIS data visualisation to RIPEstat: http://stat.ripe.net Our Routing Information Service (RIS) has been collecting global BGP routing information for over 12 years. During this period, many different interfaces to analyse and visualise accumulated data have been developed. Therefore, we have centralised access to the RIS interfaces and tools, and decommissioned some of the outdated interfaces and the old backend. This is in line with our long-term goal to provide more consolidated services, as communicated previously by our Chief Information Officer, Kaveh Ranjbar, in his article, "The Future of RIPE NCC Technical Services": https://labs.ripe.net/Members/kranjbar/future-of-ripe-ncc-technical-services More information about the migration of RIS data visualisation to RIPEstat is available on RIPELabs: https://labs.ripe.net/Members/fatemah_mafi/improved-routing-information-ava… Please submit any requests for additional features via email to stat(a)ripe.net so that we can add these to the RIPEstat Roadmap and include them in our planning: http://roadmap.ripe.net/ripe-stat/ We look forward to your feedback. Regards, Vesna * The original announcement and the reminder can be found at: http://www.ripe.net/ripe/mail/archives/mat-wg/2013-August/000323.html http://www.ripe.net/ripe/mail/archives/mat-wg/2013-September/000350.html

1 0

Announcing RIPE Atlas Service Terms Documentation for Anchor Hosts
by Vesna Manojlovic 03 Oct '13

03 Oct '13

Dear colleagues, In the process of transitioning RIPE Atlas anchors towards being a production service, we have developed two documents that describe the service terms: - Draft RIPE Atlas Service Terms and Conditions - Memorandum of Understanding - Hosting a RIPE Atlas Anchor Probe Please see the details in this RIPE Labs article: https://labs.ripe.net/Members/becha/ripe-atlas-anchors-terms-and-conditions If you are currently hosting an anchor, or if you are interested in hosting a RIPE Atlas anchor in the future, we would like to hear any feedback you have on these draft documents. Our goal is to finalise the documents by 11 October so that we can announce the production service at the upcoming RIPE 67 Meeting in Athens. 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: RIPE Atlas - Packet Size Matters
by Mirjam Kuehne 02 Oct '13

02 Oct '13

Dear colleagues, This new RIPE Labs article (contributed by Emile Aben) talks about trying to send large packets over the Internet. Above a certain size, these packets will have to be fragmented, which is known to cause problems. In both IPv4 and IPv6, we see approximately 10% of RIPE Atlas probes that are unsuccessful in pings with fragmented packets, while they don't encounter problems with smaller unfragmented packets. Please find the detailed results on RIPE Labs: https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: Recent Internet Disruptions in Sudan
by Mirjam Kuehne 26 Sep '13

26 Sep '13

Dear colleagues, Please see this new article on RIPE Labs showing the recent Internet disruption in Sudan as viewed in RIPEstat and RIPE Atlas: https://labs.ripe.net/Members/emileaben/sudan-internet-disruptions Kind regards, Mirjam Kuehne RIPE NCC

1 0

RIPE NCC is Migrating the RIS Dashboard to RIPEstat
by Vesna Manojlovic 25 Sep '13

25 Sep '13

Dear colleagues, I would like to remind you of our announcement, made last month. In the coming days, we will be migrating RIS data visualisation to RIPEstat: http://stat.ripe.net We will, therefore, be decommissioning some of the outdated RIS interfaces and tools, and the old backend. We still welcome your feedback, so please let us know your comments so that we can accommodate your needs. More information can be found in the original announcement, below. Regards, Vesna Manojlovic 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 at MAT-WG. Please submit any requests for additional features via email to stat(a)ripe.net so that we can implement these along with the planned migration of tools and features, or have them added to the RIPEstat Roadmap for later consideration: 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

Re: [mat-wg] [atlas] "Spoofing" tests.
by Andrei Robachevsky 18 Sep '13

18 Sep '13

[copying mat-wg, since it is about measureents] Lorenzo Colitti wrote on 9/18/13 6:42 AM: > On Sun, Sep 15, 2013 at 11:57 AM, Randy Bush <randy(a)psg.com > <mailto:randy@psg.com>> wrote: > > then again, if you think most of the botnets are behind broadband home > networks, it makes an interesting sample. compare spoof density of > natted vs un-natted. but then, how you gonna spoof from behind a nat? > > > Just send the packet? > > I expect a nontrivial proportion of NATs will just say "Source address > not in 192.168.1.0/24 <http://192.168.1.0/24>? Cool, don't have to NAT! > Just pass it along." :-) If only we had data ;). It would be interesting, indeed, to see how feasible spoofing is in a natted environment, broadband access networks in particular. It seems that this is the case where spoofing may cause serious problems to the provider itself, as opposed to someone else in the Internet. So, one could assume that even if there are NATs that allow this stupid thing, there maybe DOCSIS SAV and other safeguards in the BB provider provisioning system. Andrei

1 0

New on RIPE Labs: RIPE Atlas Anchors: Summary and Next Steps
by Mirjam Kuehne 16 Sep '13

16 Sep '13

Dear colleagues, This new RIPE Labs article summarises the findings from the pilot phase of the RIPE Atlas anchors project, and gives details about the decision to move to production using a one-service, smaller box for RIPE Atlas anchors: https://labs.ripe.net/Members/becha/ripe-atlas-anchors-pilot-summary-and-ne… Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: Further Virtualisation Testing for RIPE Atlas Anchor
by Mirjam Kuehne 16 Sep '13

16 Sep '13

Dear colleagues, Please find a new article on RIPE Labs: "Further Virtualisation Testing for the RIPE Atlas Anchor" https://labs.ripe.net/Members/romeo_zwart/further-virtualisation-testing-fo… This report is a follow up to an earlier article, in which we detailed our investigations into the use of virtualisation technology as a suitable means to provide other services via the RIPE Atlas anchor hardware, beyond its primary anchor function. Kind regards, Mirjam Kuehne RIPE NCC

3 4

Draft agenda for MAT @ RIPE67
by Christian Kaufmann 13 Sep '13

13 Sep '13

Hello All, This is the draft agenda for the MAT - Measurement, Analysis and Tools Working Group session at RIPE67: A. Introduction Welcome, Scribe, Jabber, Agenda B. Luciano Lenzini: Mobile network measurement app for Android (20min) C. Vesna Manojlovic: RIPEstat update (10min) D. Robert Kisteleki: Infrastructure geolocation using RIPE NCC data sets (15min) E. Razvan Oprea: Mapping Dutch critical infrastructure (20min) F. Vesna Manojlovic: RIPE Atlas update (RIPE NCC) (20min) Z. AOB Timings are approximate. The session will take place at 16:00 local time on Thursday 17th October. See you in Dublin! Richard & Christian

1 0

Using Atlas for commercial services
by Stephane Bortzmeyer 12 Sep '13

12 Sep '13

[Originally discussed on the RIPE Atlas users mailing list and forwarded here per suggestion of Daniel Karrenberg, to be sure the proper WG has a say.] After reading the Atlas ToS <https://atlas.ripe.net/service-rules/> and checking the FAQ <https://atlas.ripe.net/about/faq/>, I still have a question: Can I use Atlas as a basis for commercial services? The ToS is silent about it. The list in <https://labs.ripe.net/Members/kranjbar/future-of-ripe-ncc-technical-services> gives interesting ideas about new uses of Atlas (specially the part about using Atlas to monitor reachability from Nagios, which could become a service sold to people). Of course, Atlas is "best effort", so one cannot sue the RIPE-NCC if it breaks and stops the commercial service. But it still can be an interesting platform. Today, most Atlas uses seem to be for public research, or for "selfish" measurements (checking my network), including by commercial organisations. But I see nothing forbidding people to sell services (monitoring, quality assessment) to other people, based on Atlas. Is it a good idea to explicitely allow or disallow such services?

7 12

New on RIPE Labs: Visualising Bandwidth Capacity and Network Activity in RIPEstat Using M-Lab Data
by Mirjam Kuehne 09 Sep '13

09 Sep '13

Dear colleagues, As a result of the cooperation between the RIPE NCC and Measurement Lab, you can now visualise the bandwidth profiles and network activity of IP prefixes and individual countries in RIPEstat. For more details, please refer to this new article on RIPE Labs: https://labs.ripe.net/Members/vastur/visualising-bandwidth-capacity-in-ripe… Kind regards, Mirjam Kuehne RIPE NCC

1 0

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