[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

automatic rtbh trigger using flow data

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 
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 at slabnet.com
pgp key: B178313E   | also on Signal

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

>
>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.
>
>_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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20180901/c90280e3/attachment.sig>