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