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

[Smith, Donald]

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:(

Would be much more interested in Flow spec like rules src_ip, src_port, dst_ip, dst_por protocol type filtering.

More surgical, site stays up udp123 dst port towards victim gets dropped (maybe with src port of udp 80:)

I applaud this effort. I think we probably will want to enable the capability but would rather see this a bit more surgical :(


(coffee != sleep) & (!coffee == sleep)
 Donald.Smith at centurylink.com



From: nsp-security [nsp-security-bounces at puck.nether.net] on behalf of John Kristoff [jtk at cymru.com]
Sent: Saturday, May 17, 2014 8:43 AM
To: Marc Kneppers
Cc: nsp-security at puck.nether.net
Subject: Re: [nsp-sec] CUTRS: Community Unwanted Traffic Removal Service


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

On Fri, 16 May 2014 15:13:28 -0600
Marc Kneppers <Marc.Kneppers at TELUS.COM> wrote:

> The issue of trust always comes up. Do we trust the input feed enough
> to assume that there will be minimal false-positives so that we¹d
> implement it at a larger-scale peering level.

This is of course of primary concern to us as well.  This will not be
an open system where just anyone can submit an address or prefix they
wish to see black holed.  It will need to come from a verified
originating ASN operator or IP address block admin and be further
verified by us.

> How are you addressing questions like that? I¹m assuming that this
> feed has a higher chance of false positives given that DDoS has so
> much spoofing. (you¹re going after the DDoS data plane now, not just
> the signalling plane :)

In there was any confusion, this is mitigating the attack towards a
victim by black holing the target IP address/prefix.

> (I¹m a supporter of your efforts, here, though - don¹t get me wrong -
> just asking the questions that will come)

Did I answer them sufficiently?  What else should we be doing to make
this as convenient, safe and usable as possible?  Want to be part of an
admin team that helps obtain and vets submissions?

John



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