automatic rtbh trigger using flow data
hugo at slabnet.com
Sun Sep 2 03:24:39 UTC 2018
On Sun 2018-Sep-02 00:39:40 +0000, Ryan Hamel <Ryan.Hamel at 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
"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
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 at slabnet.com
pgp key: B178313E | also on Signal
>From: NANOG <nanog-bounces at nanog.org> On Behalf Of Baldur Norddahl
>Sent: Saturday, September 01, 2018 5:18 PM
>To: nanog at nanog.org
>Subject: Re: automatic rtbh trigger using flow data
>fre. 31. aug. 2018 17.16 skrev Hugo Slabbert <hugo at slabnet.com<mailto:hugo at slabnet.com>>:
>I would love an upstream that accepts flowspec routes to get granular about
>drops and to basically push "stateless ACLs" upstream.
>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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: Digital signature
More information about the NANOG