On 05/10/14 18:44, Jimmy Hess wrote:
> On Thu, Oct 2, 2014 at 10:54 AM, wrote:
>> The *real* problem isn't the testing.
>> It's the assumption that you can actually *do* anything useful with this
>> data.
>> Name-n-shame probably won't get us far - and the way the US works, if
>> there's a
>
>
- Original Message -
> From: "Alain Hebert"
> > Gee, Alain...
> >
> > where would people find a wiki like that?
>
> On google maybe...
>
> I see someone is already squatting http://www.bcp38.info :(
> ( /end_of_friday_silliness )
[ For those who were not playing the home game, Alain an
On 10/03/14 19:36, Jay Ashworth wrote:
> - Original Message -
>> From: "Alain Hebert"
>> PS: About that uRPF Convo, we could dump all that knowledges into
>> lets say... some comprehensive wiki page maybe =D That way when the
>> topic arise we could just link to it.
> Gee, Alain...
>
> whe
On Thu, Oct 2, 2014 at 10:54 AM, wrote:
> The *real* problem isn't the testing.
> It's the assumption that you can actually *do* anything useful with this data.
> Name-n-shame probably won't get us far - and the way the US works, if there's
> a
At least "name and shame" is something more usefu
On Fri, Oct 03, 2014 at 03:20:58PM -0400, Alain Hebert wrote:
> On the 1st of January 2015:
That's quite short notice. Perhaps we could delay it by exactly three
months?
- Matt
- Original Message -
> From: "Alain Hebert"
> PS: About that uRPF Convo, we could dump all that knowledges into
> lets say... some comprehensive wiki page maybe =D That way when the
> topic arise we could just link to it.
Gee, Alain...
where would people find a wiki like that?
Cheers,
Well (beware it is friday),
On the 1st of January 2015:
. Refuse every routes;
. Start accepting only those passing some sort of BCP38 specs
performed by some QSA =D;
. ???
. Profit;
On 10/03/14 15:03, Mikael Abrahamsson wrote:
> On Fri, 3 Oct 2014, Ric
On Fri, 3 Oct 2014, Rich Kulawiec wrote:
The same thing applies here: persistent, systemic sources of large-scale
abuse via BCP-38 noncompliance are either:
1. Being operated by clueless, negligent, incompetent people
or
2. Being operated by deliberately abusive people
There ar
On Fri, Oct 03, 2014 at 08:54:32AM +1000, Mark Andrews wrote:
> Or it will require legislation and I will assure that whatever is
> written not be liked. On the other hand everyone one in the country
> will be in the same boat.
I concur with you -- strongly. Legislation is not the answer, becaus
Rich Kulawiec wrote on 03/10/14 00:47:
> We've been down this road before. Unless there is prompt, concerted,
> collective action (as there was AGIS) then there is zero reason for those
> behind such operations to do anything but keep collecting dirty money.
There is, please join:
http://www.rou
In message <20141002224754.ga7...@gsp.org>, Rich Kulawiec writes:
> On Thu, Oct 02, 2014 at 02:24:18PM -0400, Brian Rak wrote:
> > What about providers who knowingly allow IP spoofing, because it's
> > profitable?
>
> What about providers who knowingly host massive spam operations, because
> it's
On Thu, Oct 02, 2014 at 02:24:18PM -0400, Brian Rak wrote:
> What about providers who knowingly allow IP spoofing, because it's
> profitable?
What about providers who knowingly host massive spam operations, because
it's profitable? As in:
http://www.spamhaus.org/statistics/networks/
We'
On Oct 3, 2014, at 1:24 AM, Brian Rak wrote:
> What about providers who knowingly allow IP spoofing, because it's profitable?
Ultimately, the only way to even possibly try to get a handle on this facet of
the problem may be via lawsuits; in many jurisdictions, the burden of proof is
lower for
On 10/2/2014 6:10 AM, Mikael Abrahamsson wrote:
Hi,
To fix a lot of the DDOS attacks going on, we need to make sure BCP38
compliance goes up. Only way to do this I can think of, is large scale
BCP38 testing. One way of doing this, is to have large projects such
as OpenWRT, RIPE Atlas project
> On Oct 2, 2014, at 8:37 AM, Roland Dobbins wrote:
>
> So, the problem is that those networks which are likely to implement the
> various topologically-appropriate at the various edges of their network are
> likely to have done so. And by definition, the endpoint networks where the
> spoofe
On Oct 2, 2014, at 10:54 PM, valdis.kletni...@vt.edu wrote:
> you might encounter an offender that finds it cheaper to send a lawyer
> chanting 'restraint of trade!' or similar rather than actually fixing their
> problem
In several jurisdictions in APAC, at least, truth is not a defense ag
On Thu, 02 Oct 2014 12:10:39 +0200, Mikael Abrahamsson said:
> I have been getting pushback from people that this might be "illegal".
> Could anyone please tell me what's illegal about trying to send a packet
> with a random source address?
The *real* problem isn't the testing.
It's the assumpti
Nick Hilliard wrote on 02/10/14 12:28:
> This shouldn't stop us from finding, then naming and shaming operators
> who don't use bcp38, but we also need to maintain realistic expectations
> about how successful it's going to be.
This feels indeed like boiling the ocean, but what are the alternative
On Oct 2, 2014, at 7:54 PM, Alain Hebert wrote:
>My mindset was set on DDoS and not C&C/SPAM/etc.
My point is that the ability to launch reflection/amplification DDoS attacks
(as well as spoofed SYN-floods, and so forth) is dependent upon the ability to
spoof packets, and that my hunch is
On 10/02/14 08:37, Roland Dobbins wrote:
> On Oct 2, 2014, at 7:16 PM, Alain Hebert wrote:
>
>>BCP38 compliance is the exception not the norm.
> I'm not sure that's actually the case, practically-speaking.
>
> NAT is an awful thing for many reasons, and it's negative in terms of its
> overall
On Oct 2, 2014, at 7:16 PM, Alain Hebert wrote:
>BCP38 compliance is the exception not the norm.
I'm not sure that's actually the case, practically-speaking.
NAT is an awful thing for many reasons, and it's negative in terms of its
overall impact on security, but there's one actual benefi
On 10/02/14 06:10, Mikael Abrahamsson wrote:
>
> Hi,
>
> To fix a lot of the DDOS attacks going on, we need to make sure BCP38
> compliance goes up. Only way to do this I can think of, is large scale
> BCP38 testing. One way of doing this, is to have large projects such
> as OpenWRT, RIPE Atlas pro
On 02/10/2014 12:23, Jérôme Nicolle wrote:
This. But let me ask you, how many transit provider actually implement
strict prefix-filtering ? I've seen many using a max-prefix as their
sole defense.
Plenty do and have no back-end capability to handle this, other than email
updates.
Now, let's
On Oct 2, 2014, at 6:23 PM, Jérôme Nicolle wrote:
>
>
> Le 02/10/2014 12:28, Nick Hilliard a écrit :
>> It would probably be more productive to pressurise transit providers to
>> enforce bcp38 on their customer links.
>
> This. But let me ask you, how many transit provider actually implement
Le 02/10/2014 12:28, Nick Hilliard a écrit :
> It would probably be more productive to pressurise transit providers to
> enforce bcp38 on their customer links.
This. But let me ask you, how many transit provider actually implement
strict prefix-filtering ? I've seen many using a max-prefix as th
On 02/10/2014 11:10, Mikael Abrahamsson wrote:
Why isn't this being done? Why are we complaining about 300 gigabit/s DDOS
attacks, asking people to fix their open resolvers, NTP servers etc, when
the actual culprit is that some networks in the world don't implement BCP38?
ntp monlist / dnssec a
On Thu, 2 Oct 2014, Mikael Abrahamsson wrote:
these tests are anonymous" checkbox during the initial install, or
something like this.
After posting this, I was pointed to http://spoofer.cmand.org . This seems
like the exact thing I would like to test.
--
Mikael Abrahamssonemail: swm...@
Hi,
To fix a lot of the DDOS attacks going on, we need to make sure BCP38
compliance goes up. Only way to do this I can think of, is large scale
BCP38 testing. One way of doing this, is to have large projects such as
OpenWRT, RIPE Atlas project, perhaps even CPE vendors, implement something
28 matches
Mail list logo
