[nsp-sec] CUTRS: Community Unwanted Traffic Removal Service

[Smith, Donald]

I hope you mean DBRBHF (Destination Based Remote Black Hole Filtering).



"It is assumed that all peers will drop any traffic to the advertised prefix by configuring the next-hop address to point to a black hole (.e.g. null0 interface). Except for extenuating circumstances, all IPv4 prefix announcements will be no less specific than a /32. "



That says drop traffic TO the advertised prefix. Thus completing the DDOS on that /32.



Cymru one of the things I will be asked as I discuss this internally is "how many routes".

We would probably prefix filter this to a specific small number (50 100?)











(coffee != sleep) & (!coffee == sleep)
 Donald.Smith at centurylink.com<mailto:Donald.Smith at centurylink.com>
________________________________
From: nsp-security [nsp-security-bounces at puck.nether.net] on behalf of David Freedman [david.freedman at uk.clara.net]
Sent: Monday, May 19, 2014 4:45 PM
To: Justin M. Streiner
Cc: nsp-security at puck.nether.net
Subject: Re: [nsp-sec] CUTRS: Community Unwanted Traffic Removal Service

----------- nsp-security Confidential --------

I would be interested in just receiving the raw data and turning it into announcements (then I can choose which should be S/RBTH and which should be flowspec etc..)

The current systems using BGP are great, but I almost never let them get
propagated in the network directly, instead I capture, parse/vet  and re-advertise if it looks safe to do so.

Would just receiving the data (including. a reason) be an option here?

Dave




> On 19 May 2014, at 17:47, "Justin M. Streiner" <streiner at cluebyfour.org> wrote:
>
> ----------- nsp-security Confidential --------
>
>> On Sat, 17 May 2014, Smith, Donald wrote:
>>
>> ----------- nsp-security Confidential --------
>>
>> Can we get Flow-spec rules instead of just BGP RTBH?
>> Possibly. The effect will be largely the same. We have found that support for flow-spec in the community is limited and thus do not currently utilize any of its extended capabilities. We have the capability and will consider enabling it if there is sufficient demand.
>>
>> RTDBBHFing :) Remote Triggered Destination based BHFing.
>>
>> While this stops the attack traffic it also kills the victim ip:(
>
> I agree with Donald.  If flowspec is a workable option, that would be worth looking into.  Cisco is coming around and beginning to support flowspec.  There was some discussion about this in NANOG or cisco-nsp recently - I can dig up specifics if there is interest.
>
> I am willing to help vet stuff before it goes into the feed.
>
> Realizing that IPv6 might still be a road map item, it presents some interesting challenges that currently don't have easy answers, or could impose compromises that might not be palatable for some operators.
>
> Would routes be for single /128s, or something larger, like a /64?  If /128, stomping on the offending machine could turn into an ugly game of whack-a-mole, or could result in a case where traffic to $BAD_HOST's known address gets dropped by providers who get the CUTRS feed, but $BAD_HOST could still possibly communicate with bots if it has privacy extensions enabled.
>
> With /64, that risk is still there, but the risk of collateral damage goes up as well.
>
> jms
>
>
> _______________________________________________
> nsp-security mailing list
> nsp-security at puck.nether.net
> https://puck.nether.net/mailman/listinfo/nsp-security
>
> Please do not Forward, CC, or BCC this E-mail outside of the nsp-security
> community. Confidentiality is essential for effective Internet security counter-measures.
> _______________________________________________



_______________________________________________
nsp-security mailing list
nsp-security at puck.nether.net
https://puck.nether.net/mailman/listinfo/nsp-security

Please do not Forward, CC, or BCC this E-mail outside of the nsp-security
community. Confidentiality is essential for effective Internet security counter-measures.
_______________________________________________