Re: [atlas] Spoofing measurenments
Thanks! Will read it deeply. On Wed, Nov 18, 2015 at 3:36 PM, Stephane Bortzmeyer wrote: > On Wed, Nov 18, 2015 at 03:23:33PM +0300, > Pavel Odintsov wrote > a message of 83 lines which said: > >> Could somebody share link to archives with previous discussion of this >> ethical question? > > https://www.ripe.net/ripe/mail/archives/ripe-atlas/2013-September/001005.html > https://www.ripe.net/ripe/mail/archives/ripe-atlas/2013-June/000838.html > > See also the roadmap <https://atlas.ripe.net/docs/roadmap/>, section > "Measurements to detect BCP38 compliance" > -- Sincerely yours, Pavel Odintsov
Re: [atlas] Spoofing measurenments
Hello! Could somebody share link to archives with previous discussion of this ethical question? On Wed, Nov 18, 2015 at 3:18 PM, Jen Linkova wrote: > On Wed, Nov 18, 2015 at 12:57 PM, Alexander Lyamin wrote: >> Do we have a statistics on what percentage of probes operate behind NAT? > > There is a tag "IPv4 RFC1918" so you can select all probes with that > tag to get that number. > >> On Tue, Nov 17, 2015 at 7:03 PM, Pavel Odintsov >> wrote: >>> >>> Hello! >>> >>> Thanks for answer! >>> >>> But actually we have huge issues with IPv4. Could we collect this >>> stats with full anonymous approach for bitting ethical problem here? >>> >>> So we definitely need number of networks who ignore this rules. >>> >>> On Tue, Nov 17, 2015 at 8:00 PM, Jen Linkova wrote: >>> > On Tue, Nov 17, 2015 at 5:50 PM, Pavel Odintsov >>> > wrote: >>> >> I'm writing from RIPE71 / Anti spoofing BoF. So I want to ask for some >>> >> difficult ethical question. >>> >> >>> >> Could we detect probe hosts who do not deploy outgoing filtering and >>> >> accept spoofed traffic? >>> >> >>> >> We need to know amount of they. It's really important for solving >>> >> spoofing issue in Internet scale. >>> > >>> > It's been discussed before and some ethical concerns have been raised >>> > by RIPE NCC. >>> > >>> > From pure technical point of view I think it might be possible some >>> > data for Ipv6 (with some false negatives): >>> > >>> > - a probe could generate ULA prefix for itself and send traffic from >>> > that ULA source to, let's say, some anchors (or some other pre-defined >>> > target which is known for allowing packets from ULA sources). >>> > Receiving such packet from a probe would prove tat there is no BCP38 >>> > filtering on the path (however blocking packets proves only the fact >>> > that ULAs are being blocked, not real spoofed packets). Or maybe a >>> > probe might get a GUA IP address from RIPE prefix and use it as a >>> > source.. >>> > As bi-directional communication is not necessary, any source address >>> > would work. >>> > >>> >> >>> >> -- >>> >> Sincerely yours, Pavel Odintsov >>> >> >>> > >>> > >>> > >>> > -- >>> > SY, Jen Linkova aka Furry >>> >>> >>> >>> -- >>> Sincerely yours, Pavel Odintsov >> >> >> >> >> -- >> connecting the dots > > > > -- > SY, Jen Linkova aka Furry -- Sincerely yours, Pavel Odintsov
Re: [atlas] Spoofing measurenments
Hello! Thanks for answer! But actually we have huge issues with IPv4. Could we collect this stats with full anonymous approach for bitting ethical problem here? So we definitely need number of networks who ignore this rules. On Tue, Nov 17, 2015 at 8:00 PM, Jen Linkova wrote: > On Tue, Nov 17, 2015 at 5:50 PM, Pavel Odintsov > wrote: >> I'm writing from RIPE71 / Anti spoofing BoF. So I want to ask for some >> difficult ethical question. >> >> Could we detect probe hosts who do not deploy outgoing filtering and >> accept spoofed traffic? >> >> We need to know amount of they. It's really important for solving >> spoofing issue in Internet scale. > > It's been discussed before and some ethical concerns have been raised > by RIPE NCC. > > From pure technical point of view I think it might be possible some > data for Ipv6 (with some false negatives): > > - a probe could generate ULA prefix for itself and send traffic from > that ULA source to, let's say, some anchors (or some other pre-defined > target which is known for allowing packets from ULA sources). > Receiving such packet from a probe would prove tat there is no BCP38 > filtering on the path (however blocking packets proves only the fact > that ULAs are being blocked, not real spoofed packets). Or maybe a > probe might get a GUA IP address from RIPE prefix and use it as a > source.. > As bi-directional communication is not necessary, any source address would > work. > >> >> -- >> Sincerely yours, Pavel Odintsov >> > > > > -- > SY, Jen Linkova aka Furry -- Sincerely yours, Pavel Odintsov
[atlas] Spoofing measurenments
Hello, Community! I'm writing from RIPE71 / Anti spoofing BoF. So I want to ask for some difficult ethical question. Could we detect probe hosts who do not deploy outgoing filtering and accept spoofed traffic? We need to know amount of they. It's really important for solving spoofing issue in Internet scale. -- Sincerely yours, Pavel Odintsov
Re: [atlas] Feature request for IP record route feature in RIPE Atlas
Thanks! I will try to run it on CentOS VirtualBox vm. On Mon, Nov 9, 2015 at 4:10 PM, Philip Homburg wrote: > On 2015/11/09 10:04 , Pavel Odintsov wrote: >> But RIPE Atlas offer really huge coverage over the World and we could >> reach really any host with <7 hops. But we haven't this feature in >> RIPE Atlas. >> >> Finally with this feature we could build full adjacently map over all the >> World. >> >> I have checked implementation details here >> https://labs.ripe.net/Members/philip_homburg/ripe-atlas-measurements-source-code >> >> Looks like we need to build separate libevent based toolkit for this >> task or add this feature to ping tool. But unfortunately I could not >> find any docs about deploy of RIPE source code for development. Could >> you share some information? > > Hi, > > I use a vm running debian wheezy for development. The anchors run CentOS > 6. So the code should run there. If it doesn't run on other Linux > versions then please let me know and I'll see what I can do. > > The INSTALL file in the source code has specific instructions on how to > build. > > I would advice against just writing some code and asking it to be > merged. Instead coordinate with me what you want to change. > > Philip > -- Sincerely yours, Pavel Odintsov
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
Hello! Maybe we could fix import issues with some vendor? We have really huge and good shop of network hardware here: http://shop.nag.ru If they could offer Soekris platform could be fine. On Tue, Nov 10, 2015 at 1:30 PM, Daniel Karrenberg wrote: > Pavel, > > it appears that my information is out-dated. You are right one needs to > import them these days. I realise that this is awkward and expensive, > but it appears to be possible. > > Maybe rather than wasting time on VMs we should consider a new type of > anchor which is more readily available everywhere than the Soekris. > Personally I would go in the direction of Ubiquity Edge Routers or > Mikrotik routers which I know for sure are available in Russia and also > widely available around the world. Do you have suggestions? > > Daniel > > On 10.11.15 10:49 , Pavel Odintsov wrote: >> Hello! >> >> Awesome! Could you share where we could bought it? I will share this >> information with local community. >> >> On Tue, Nov 10, 2015 at 12:36 PM, Daniel Karrenberg >> wrote: >>> At this time are 485 connected probes and two connected anchors in >>> Russia. As far as I know Soekris boxes can be bought in Russia. >>> >>> Daniel >>> >>> On 10.11.15 10:07 , Pavel Odintsov wrote: >>>> Hello, Community! >>>> >>>> I like idea about VM based Anchor's. >>>> >>>> For example in Russia we have so much companies who really want to >>>> host RIPE Anchor hosting but it's really hard due to so much >>>> bureaucracy for computer hardware import. It's really sophisticated >>>> and long task. >>>> >>>> VM based Anchors could help in this case. But they should be >>>> designated as "second-rate monitoring". So somebody who interested in >>>> monitoring over non-so-reliable-vm's could use they. Actually, this >>>> VM's should "mine" less points than full-size-Anchor. >>>> >>>> We could select some unified way to run VM's. I prefer VmWare because it's: >>>> 1) Free >>>> 2) Simple to deploy >>>> 3) Mature >>>> 4) Very simple VM deploy >>>> >>>> Xen, KVM are pretty too but they are based on non standard linux >>>> distributions and it could be a configuration issue. OpenVZ/Docker and >>>> LXC should be avoided because (actually I have so much experience with >>>> they and I'm not a technology hater) they are not offer dedicated >>>> service and not isolated perfectly from each other processes. >>>> >>>> >>>> >>>> On Tue, Nov 10, 2015 at 11:56 AM, Gert Doering wrote: >>>>> Hi, >>>>> >>>>> On Tue, Nov 10, 2015 at 09:33:01AM +0100, Daniel Karrenberg wrote: >>>>>> >From my personal, informal assessment I advise against supporting VMs. I >>>>>> recommend a thorough assessment of the data quality, the costs and the >>>>>> effects on RIPE Atlas as a whole before diving into soloutioneering. >>>>> >>>>> From experience running a recursive DNS on a VM platform, I'd also speak >>>>> against supporting VMs. Unpredictable load elsewhere on the same host >>>>> can (and does) lead to UDP/ICMP packet loss, which the "Atlas VM" won't >>>>> be able to differenciate from "something on the path is broken/lossy". >>>>> >>>>> Gert Doering >>>>> -- NetMaster >>>>> -- >>>>> have you enabled IPv6 on something today...? >>>>> >>>>> SpaceNet AGVorstand: Sebastian v. Bomhard >>>>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >>>>> Grundner-Culemann >>>>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>>>> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >>>> >>>> >>>> >> >> >> -- Sincerely yours, Pavel Odintsov
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
Hello! Awesome! Could you share where we could bought it? I will share this information with local community. On Tue, Nov 10, 2015 at 12:36 PM, Daniel Karrenberg wrote: > At this time are 485 connected probes and two connected anchors in > Russia. As far as I know Soekris boxes can be bought in Russia. > > Daniel > > On 10.11.15 10:07 , Pavel Odintsov wrote: >> Hello, Community! >> >> I like idea about VM based Anchor's. >> >> For example in Russia we have so much companies who really want to >> host RIPE Anchor hosting but it's really hard due to so much >> bureaucracy for computer hardware import. It's really sophisticated >> and long task. >> >> VM based Anchors could help in this case. But they should be >> designated as "second-rate monitoring". So somebody who interested in >> monitoring over non-so-reliable-vm's could use they. Actually, this >> VM's should "mine" less points than full-size-Anchor. >> >> We could select some unified way to run VM's. I prefer VmWare because it's: >> 1) Free >> 2) Simple to deploy >> 3) Mature >> 4) Very simple VM deploy >> >> Xen, KVM are pretty too but they are based on non standard linux >> distributions and it could be a configuration issue. OpenVZ/Docker and >> LXC should be avoided because (actually I have so much experience with >> they and I'm not a technology hater) they are not offer dedicated >> service and not isolated perfectly from each other processes. >> >> >> >> On Tue, Nov 10, 2015 at 11:56 AM, Gert Doering wrote: >>> Hi, >>> >>> On Tue, Nov 10, 2015 at 09:33:01AM +0100, Daniel Karrenberg wrote: >>>> >From my personal, informal assessment I advise against supporting VMs. I >>>> recommend a thorough assessment of the data quality, the costs and the >>>> effects on RIPE Atlas as a whole before diving into soloutioneering. >>> >>> From experience running a recursive DNS on a VM platform, I'd also speak >>> against supporting VMs. Unpredictable load elsewhere on the same host >>> can (and does) lead to UDP/ICMP packet loss, which the "Atlas VM" won't >>> be able to differenciate from "something on the path is broken/lossy". >>> >>> Gert Doering >>> -- NetMaster >>> -- >>> have you enabled IPv6 on something today...? >>> >>> SpaceNet AGVorstand: Sebastian v. Bomhard >>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >> >> >> -- Sincerely yours, Pavel Odintsov
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
Hello, Community! I like idea about VM based Anchor's. For example in Russia we have so much companies who really want to host RIPE Anchor hosting but it's really hard due to so much bureaucracy for computer hardware import. It's really sophisticated and long task. VM based Anchors could help in this case. But they should be designated as "second-rate monitoring". So somebody who interested in monitoring over non-so-reliable-vm's could use they. Actually, this VM's should "mine" less points than full-size-Anchor. We could select some unified way to run VM's. I prefer VmWare because it's: 1) Free 2) Simple to deploy 3) Mature 4) Very simple VM deploy Xen, KVM are pretty too but they are based on non standard linux distributions and it could be a configuration issue. OpenVZ/Docker and LXC should be avoided because (actually I have so much experience with they and I'm not a technology hater) they are not offer dedicated service and not isolated perfectly from each other processes. On Tue, Nov 10, 2015 at 11:56 AM, Gert Doering wrote: > Hi, > > On Tue, Nov 10, 2015 at 09:33:01AM +0100, Daniel Karrenberg wrote: >> >From my personal, informal assessment I advise against supporting VMs. I >> recommend a thorough assessment of the data quality, the costs and the >> effects on RIPE Atlas as a whole before diving into soloutioneering. > > From experience running a recursive DNS on a VM platform, I'd also speak > against supporting VMs. Unpredictable load elsewhere on the same host > can (and does) lead to UDP/ICMP packet loss, which the "Atlas VM" won't > be able to differenciate from "something on the path is broken/lossy". > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AGVorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -- Sincerely yours, Pavel Odintsov
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
Hello, Robert! I completely agree with you. I'm thinking from developer point of view. I want to hack evtraceroute/evping. But I could not compile they on my Linux box. So I'm looking for some way to build / check RIPE Atlas environment on my machine. So I definitely could install it manually into VirtualBox appliance. On Mon, Nov 9, 2015 at 3:43 PM, Robert Kisteleki wrote: > Dear All, > > At the risk of assigning more work to myself than I anticipate: there's an > action item on me to come up with some thoughts and questions to the > community about the VM probes. For example: what virtualisation technology > would people prefer (as we cannot support all of them)? How would we manage > these (think of field-upgrades) and how to administer them (at the moment > it's easy, since we supply the whole device with keys and firmware). > > Regards, > Robert > > > On 2015-11-09 13:34, Stephan Wolf wrote: >> +2 for VM probe > -- Sincerely yours, Pavel Odintsov
Re: [atlas] Feature request for IP record route feature in RIPE Atlas
+1 for VM probe :) On Mon, Nov 9, 2015 at 1:16 PM, Colin Johnston wrote: > virtual vm probe would be great as well :) ask for this before > > Colin > >> On 9 Nov 2015, at 09:04, Pavel Odintsov wrote: >> >> Hello, dear Atlas Team! >> >> As host of RIPE Anchor #6111 I have some feedback about your awesome service! >> >> Thanks for your Great Job in measuring Internet! >> >> I would like to ask very important feature for measuring reverse trace >> route. I'm speaking about IP record route option which could track up >> to 9 hops of reverse path. >> >> I want to know path to my hosts from networks who haven't RIPE Atlas. >> Actually I could not implement this feature due to 9 hop restriction >> in IP header. >> >> But RIPE Atlas offer really huge coverage over the World and we could >> reach really any host with <7 hops. But we haven't this feature in >> RIPE Atlas. >> >> Finally with this feature we could build full adjacently map over all the >> World. >> >> I have checked implementation details here >> https://labs.ripe.net/Members/philip_homburg/ripe-atlas-measurements-source-code >> >> Looks like we need to build separate libevent based toolkit for this >> task or add this feature to ping tool. But unfortunately I could not >> find any docs about deploy of RIPE source code for development. Could >> you share some information? >> >> -- >> Sincerely yours, Pavel Odintsov >> > -- Sincerely yours, Pavel Odintsov
[atlas] Feature request for IP record route feature in RIPE Atlas
Hello, dear Atlas Team! As host of RIPE Anchor #6111 I have some feedback about your awesome service! Thanks for your Great Job in measuring Internet! I would like to ask very important feature for measuring reverse trace route. I'm speaking about IP record route option which could track up to 9 hops of reverse path. I want to know path to my hosts from networks who haven't RIPE Atlas. Actually I could not implement this feature due to 9 hop restriction in IP header. But RIPE Atlas offer really huge coverage over the World and we could reach really any host with <7 hops. But we haven't this feature in RIPE Atlas. Finally with this feature we could build full adjacently map over all the World. I have checked implementation details here https://labs.ripe.net/Members/philip_homburg/ripe-atlas-measurements-source-code Looks like we need to build separate libevent based toolkit for this task or add this feature to ping tool. But unfortunately I could not find any docs about deploy of RIPE source code for development. Could you share some information? -- Sincerely yours, Pavel Odintsov
