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

[David Freedman]

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.
> _______________________________________________