Apologies if this has already been discussed enlist -- I took a quick look though the archives and didn't see it. I believe that the reason for not allowing things like tests that send spoofed packets is that it might violate the AUP that participants have with their ISPs / be viewed by participants ISPs as an attack. So, what about having a checkbox in the Probe Settings that says something like: "I have no AUP with my ISP or I'm fine to violate my AUP. Run intrusive or dangerous tests on this probe" ? This would create a subset of probes that could be used for more interesting tests, an d would allow for greater visibility into things. W --- It is a mistake to think you can solve any major problem just with potatoes. --Douglas Adams
On Sat, Sep 07, 2013 at 01:24:12PM -0400, Warren Kumari wrote:
Apologies if this has already been discussed enlist -- I took a quick look though the archives and didn't see it.
See thread "Spoofing the source IP address from a probe?" from around RIPE66.
I believe that the reason for not allowing things like tests that send spoofed packets is that it might violate the AUP that participants have with their ISPs / be viewed by participants ISPs as an attack.
So, what about having a checkbox in the Probe Settings that says something like: "I have no AUP with my ISP or I'm fine to violate my AUP. Run intrusive or dangerous tests on this probe" ? This would create a subset of probes that could be used for more interesting tests, an d would allow for greater visibility into things.
There was traffic seeming to support the idea of a properly opted-in method (as recently as 30 July) but there hadn't been specifics regarding the implementation nor commitment that it would get to such a one. :-) -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG
On 07.09.2013, at 19:39 , Joe Provo <jzp-ripe@rsuc.gweep.net> wrote:
There was traffic seeming to support the idea of a properly opted-in method (as recently as 30 July) but there hadn't been specifics regarding the implementation nor commitment that it would get to such a one. :-)
And there was traffic clearly opposed to the idea as well. I cannot see any consensus there yet, one way or the other. And then there is the question of cost to implement and priorities ... Daniel
On Sep 7, 2013, at 12:39 PM, Joe Provo <jzp-ripe@rsuc.gweep.net> wrote:
There was traffic seeming to support the idea of a properly opted-in method (as recently as 30 July) but there hadn't been specifics regarding the implementation nor commitment that it would get to such a one. :-)
My personal opinion is that I have no issue with _RIPE_ conducting a spoofing test using my probes, but I have an objection to letting a random person conduct a spoofing test. With the former I have confidence it won't be used for evil in any way, with the latter I can see cases where my values and the probe creators values don't completely overlap. I would like to see RIPE try and spoof a RIPE IP from all the probes, and report on the results, at least once. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On 15.9.2013 3:19, Leo Bicknell wrote:
I would like to see RIPE try and spoof a RIPE IP from all the probes, and report on the results, at least once.
A big plus one to this suggestion. A big chunk of today's common ddos attack methods would simply disappear if all networks prevented source address spoofing. And for the rest of the attacks finding and eliminating the sources (or at least the middle men being abused for generating the traffic) would be a bit easier. A concrete demonstration on the prevalence(?) of networks allowing source address spoofing would help in getting this hole plugged, I would think. Publishing specific details about which ASes let spoofed packets out might be problematic, but publishing percentages and following how the percentage develops over time should not hurt. Tapio
A concrete demonstration on the prevalence(?) of networks allowing source address spoofing would help in getting this hole plugged
a jillion spoofed botnets did not make the point pretty clearly? hypothesis: atlas probes show a bias toward clueful locations. unless there is a calibration set with a different, or better yet known, bias, what useful is actually being measured? unless it's a name and shame game. and then you will want to know if things 'improve' over time, which means it is not a one-shot. randy
On Sep 14, 2013, at 9:16 PM, Randy Bush <randy@psg.com> wrote:
hypothesis: atlas probes show a bias toward clueful locations. unless there is a calibration set with a different, or better yet known, bias, what useful is actually being measured? unless it's a name and shame game. and then you will want to know if things 'improve' over time, which means it is not a one-shot.
I do not think RIPE probes are representative of the larger Internet, because they are generally run by more clueful individuals. In that sense, they represent an "ideal situation". People who know and more often than not care. If the results from this ideal situation are that a majority of probes can spoof, we might as well give up on source address validation, and move on to some other techniques to mitigate the problem. On the other side, if nearly zero probes can spoof addresses it is proof-by-example that if you care to implement BCP38, it can work and can help. That data may help convince those who don't care today that caring can result in a good outcome. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
i am not against this in principle. but i want to see a hypothesis and an experimental design which can produce something real.
hypothesis: atlas probes show a bias toward clueful locations. unless there is a calibration set with a different, or better yet known, bias, what useful is actually being measured? unless it's a name and shame game. and then you will want to know if things 'improve' over time, which means it is not a one-shot. I do not think RIPE probes are representative of the larger Internet, because they are generally run by more clueful individuals.
my point. i have been calling route views "feeds from the 'clue core'."
In that sense, they represent an "ideal situation".
it may be a bit of a stretch from 'bias' to 'ideal'.
People who know and more often than not care.
some months ago, the ncc said over half the probes were behind nats. i.e. clue core folk took them home, where they are likely behind someone else's broadband network. 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? as i said, a real hypothesis and an experimental design to test it. i guess i am still stuck in middle school science class.
If the results from this ideal situation are that a majority of probes can spoof, we might as well give up on source address validation
ok, i give. with an already flawed measure, how did you decide on the majority of probes? and, if the majority of probes are behind nats, and you can not figure out how to spoof from behind a nat, then you can declare victory, such as it is. as i have said many times, i do not think ranting has done much in recent years. and having some data ain't gonna help. randy
On 15.09.2013, at 4:57 , Randy Bush <randy@psg.com> wrote:
i am not against this in principle. but i want to see a hypothesis and an experimental design which can produce something real.
I find myself agreeing with Randy. I also would like to hear an argument about what specific information and knowledge this experiment will generate over and above what is already known and measured by http://spoofer.cmand.org/ and similar experiments as well as why this experiment cannot be achieved without using RIPE Atlas. Once we have such a proposal we can have a discussion whether it is worth both the effort and the risk to RIPE Atlas. If we are going in the direction of naming and shaming I would want to hear from the RIPE community beyond the MAT WG that this is what they want; best venue for this probably is http://www.ripe.net/ripe/mail/ripe-mailing-lists/ncc-services-wg . I do not want the RIPE NCC to be criticised for spending effort here and for naming and shaming. In this discussion I will bring up http://www.ripe.net/ripe/docs/ripe-379 and my assessment of why it was not as successful as we anticipated and caution against expecting too much from additional efforts in this area. Once we have community consensus about these things and if it is to go ahead, we need to discuss relative priorities in the MAT WG, using http://roadmap.ripe.net/ripe-atlas/ . Finally: The community discussion should happen on this closed list but on http://www.ripe.net/ripe/groups/wg/mat . Daniel
Small remark: Regarding concern that many probes are behind NAT and outcome of Spoofing check will not be so effective. In future perspective: in IPv6 world none or maybe only few probes should stay behind NAT so, in case of IPv6 this spoofing check should be very effective. Regards. /Alex Saroyan On 09/16/2013 04:06 PM, Daniel Karrenberg wrote:
On 15.09.2013, at 4:57 , Randy Bush <randy@psg.com> wrote:
i am not against this in principle. but i want to see a hypothesis and an experimental design which can produce something real. I find myself agreeing with Randy. I also would like to hear an argument about what specific information and knowledge this experiment will generate over and above what is already known and measured by http://spoofer.cmand.org/ and similar experiments as well as why this experiment cannot be achieved without using RIPE Atlas. Once we have such a proposal we can have a discussion whether it is worth both the effort and the risk to RIPE Atlas.
If we are going in the direction of naming and shaming I would want to hear from the RIPE community beyond the MAT WG that this is what they want; best venue for this probably is http://www.ripe.net/ripe/mail/ripe-mailing-lists/ncc-services-wg . I do not want the RIPE NCC to be criticised for spending effort here and for naming and shaming. In this discussion I will bring up http://www.ripe.net/ripe/docs/ripe-379 and my assessment of why it was not as successful as we anticipated and caution against expecting too much from additional efforts in this area.
Once we have community consensus about these things and if it is to go ahead, we need to discuss relative priorities in the MAT WG, using http://roadmap.ripe.net/ripe-atlas/ .
Finally: The community discussion should happen on this closed list but on http://www.ripe.net/ripe/groups/wg/mat .
Daniel
On Sun, Sep 15, 2013 at 11:57 AM, Randy Bush <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? Cool, don't have to NAT! Just pass it along." :-)
[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@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
On 15.9.2013 5:16, Randy Bush wrote:
A concrete demonstration on the prevalence(?) of networks allowing source address spoofing would help in getting this hole plugged
a jillion spoofed botnets did not make the point pretty clearly?
Yes, but because they are spoofed, it's not easy to determine which networks are the ones that allow spoofing.
what useful is actually being measured? unless it's a name and shame game. and then you will want to know if things 'improve' over time, which means it is not a one-shot.
Name and shame can work in some cases. And yes, I'd like to see a trend, i.e. not making this a one-shot deal. Even if there is a bias towards probes being in networks that care, the way the figures change over time (derivative) should be less biased. Tapio
Tapio Sokura wrote on 9/15/13 5:08 AM:
what useful is actually being measured? unless it's a name and shame game. and then you will want to know if things 'improve' over time, which means it is not a one-shot.
Name and shame can work in some cases.
It can be a "name and shame" with a positive spin - an "anti-spoofing" movement I mentioned before. A network can get and stay on a list if (until) they pass a spoofer or atlas test. I think it can help raise awareness and attention to this issue, at least. Andrei
On 15 Sep 2013, at 04:16, Randy Bush <randy@psg.com> wrote:
hypothesis: atlas probes show a bias toward clueful locations. unless there is a calibration set with a different, or better yet known, bias, what useful is actually being measured? unless it's a name and shame game. and then you will want to know if things 'improve' over time, which means it is not a one-shot.
Even clueful individuals have broadband connections at home, creating a network over which they do not have much control. Especially those networks are of interest regarding the (non-)filtering of spoofed packets. Jeroen.
I think that would be one way to alleviate the concerns, yes. Also note that we are talking about special category of users who have somewhat more control over their network - not a typical BB user sitting behind a NAT. Another important question IMO is how these data is going to be used. Several people I talked to were supporting of the idea of instigating an "anti-spoofing" movement among the ISPs, where in order to get (and stay) on a public list of networks who care one needs to pass anti-spoofing tests. Atlas and Spoofer would be instrumental in this effort. Andrei Warren Kumari wrote on 9/7/13 7:24 PM:
Apologies if this has already been discussed enlist -- I took a quick look though the archives and didn't see it.
I believe that the reason for not allowing things like tests that send spoofed packets is that it might violate the AUP that participants have with their ISPs / be viewed by participants ISPs as an attack.
So, what about having a checkbox in the Probe Settings that says something like: "I have no AUP with my ISP or I'm fine to violate my AUP. Run intrusive or dangerous tests on this probe" ? This would create a subset of probes that could be used for more interesting tests, an d would allow for greater visibility into things.
W
--- It is a mistake to think you can solve any major problem just with potatoes. --Douglas Adams
On Sep 9, 2013, at 3:33 AM, Andrei Robachevsky <robachevsky@isoc.org> wrote:
I think that would be one way to alleviate the concerns, yes. Also note that we are talking about special category of users who have somewhat more control over their network - not a typical BB user sitting behind a NAT.
Yup. Although if some BB users behind NATs did check the box, I'm sure that they would still be useful for some tests, just not spoofing ones. Actually, that's still not true -- I came across a number of CPE devices that seem to use the following logic: 1: If the source IP is on my "internal" network perform the NAT function (rewrite, install session in NAT table, etc) 2: If the source IP is *not* on the "internal" network simply pass the packet unaltered. IIRC it was some d-link devices that that did this, I wonder how common it is…
Another important question IMO is how these data is going to be used. Several people I talked to were supporting of the idea of instigating an "anti-spoofing" movement among the ISPs, where in order to get (and stay) on a public list of networks who care one needs to pass anti-spoofing tests. Atlas and Spoofer would be instrumental in this effort.
Yes -- the issue that I see with things like the Spoofer project is that they require someone to download and run a client app -- this limits the number and scope of test that they see and also creates selection bias. Yes, there is even more selection bias with Atlas probes, but Atlas seems to have a fairly wide spread these days. If even a fraction of users clicked the button… Trying to push BCP38 these days may be tilting at windmills, but can't hurt. I'm sure that a bunch of other uses could also be found for probes that are AUP free…. W
Andrei
Warren Kumari wrote on 9/7/13 7:24 PM:
Apologies if this has already been discussed enlist -- I took a quick look though the archives and didn't see it.
I believe that the reason for not allowing things like tests that send spoofed packets is that it might violate the AUP that participants have with their ISPs / be viewed by participants ISPs as an attack.
So, what about having a checkbox in the Probe Settings that says something like: "I have no AUP with my ISP or I'm fine to violate my AUP. Run intrusive or dangerous tests on this probe" ? This would create a subset of probes that could be used for more interesting tests, an d would allow for greater visibility into things.
W
--- It is a mistake to think you can solve any major problem just with potatoes. --Douglas Adams
-- The above email is neither interesting or relevant, but at least it provided no new information.
On Mon, Sep 09, 2013 at 02:03:17PM -0400, Warren Kumari wrote:
I'm sure that a bunch of other uses could also be found for probes that are AUP free?.
sure. Why not have another checkbox [ ] I consent to the probe hosted by me participating in online protest campaigns -Peter
participants (11)
-
Alex Saroyan -
Andrei Robachevsky -
Daniel Karrenberg -
Jeroen van der Ham -
Joe Provo -
Leo Bicknell -
Lorenzo Colitti -
Peter Koch -
Randy Bush -
Tapio Sokura -
Warren Kumari