Re: automatic rtbh trigger using flow data

[Hugo Slabbert <hugo () slabnet com>]

On Sun 2018-Sep-02 00:39:40 +0000, Ryan Hamel <Ryan.Hamel () quadranet com> wrote:

> No ISP is in the business of filtering traffic unless the client pays the 
> hefty fee since someone still has to tank the attack.

If I can tag an RTBH community on a /32, what's the additional lost revenue 
in letting me be more granular and get down to the specific flows I want 
dropped?

"drop all traffic to x/32" would drop *more* traffic than "drop any traffic 
from address y to x/32, protocol TCP, port n".

> I also don’t think there is destination prefix IP filtering in flowspec, 
> which could seriously cause problems.

What now?  Unless I'm misunderstanding what you're saying, it's right in 
the spec[1]:

   A flow specification NLRI must be validated such that it is
   considered feasible if and only if:

   a) The originator of the flow specification matches the originator of
      the best-match unicast route for the destination prefix embedded
      in the flow specification.

   b) There are no more specific unicast routes, when compared with the
      flow destination prefix, that have been received from a different
      neighboring AS than the best-match unicast route, which has been
      determined in step a).

   By originator of a BGP route, we mean either the BGP originator path
   attribute, as used by route reflection, or the transport address of
   the BGP peer, if this path attribute is not present.

   The underlying concept is that the neighboring AS that advertises the
   best unicast route for a destination is allowed to advertise flow-
   spec information that conveys a more or equally specific destination
   prefix.  Thus, as long as there are no more specific unicast routes,
   received from a different neighboring AS, which would be affected by
   that filtering rule.

   The neighboring AS is the immediate destination of the traffic
   described by the flow specification.  If it requests these flows to
   be dropped, that request can be honored without concern that it
   represents a denial of service in itself.  Supposedly, the traffic is
   being dropped by the downstream autonomous system, and there is no
   added value in carrying the traffic to it.

--
Hugo Slabbert       | email, xmpp/jabber: hugo () slabnet com
pgp key: B178313E   | also on Signal

[1] https://tools.ietf.org/html/rfc5575

> From: NANOG <nanog-bounces () nanog org> On Behalf Of Baldur Norddahl
> Sent: Saturday, September 01, 2018 5:18 PM
> To: nanog () nanog org
> Subject: Re: automatic rtbh trigger using flow data
>
>
> fre. 31. aug. 2018 17.16 skrev Hugo Slabbert <hugo () slabnet com<mailto:hugo () slabnet com>>:
>
>
> I would love an upstream that accepts flowspec routes to get granular about
> drops and to basically push "stateless ACLs" upstream.
>
> _keeps dreaming_
>
>
> We just need a signal to drop UDP for a prefix. The same as RTBH but only for UDP. This would prevent all volumetric 
> attacks without the end user being cut off completely.
>
> Besides from some games, VPN and VoIP, they would have an almost completely normal internet experience. DNS would go 
> through the ISP servers and only be affected if the user is using a third party service.
>
> Regards
>
> Baldur

Attachment: signature.asc
Description: Digital signature