nanog mailing list archives
Re: BCP 38 addendum
From: joel jaeggli <joelja () bogus com>
Date: Fri, 2 Mar 2018 12:34:54 -0800
On 3/1/18 10:57 AM, Todd Crane wrote:
Question: Since we cannot count on everyone to follow BCP 38 or investigate their abuse@, I was thinking about the feasibility of using filtering to prevent spoofing from peers’ networks. With the exception of a few edge cases, would it be possible to filter inbound traffic allowing only packets with source addresses matching the peer’s BGP announcement? Theoretically it should be a two way street to any address I can receive from, thus if I can’t send to it, I shouldn't be receiving from it. I realize this is not currently a feature of any router (to my knowledge), but could it be implemented into some NOSs fairly easily and jerry-rigged into others for the time being.
you can build ACLs from IRR objects just like you can build prefix lists. for customers this is just as feasible as controlling what routes you accept from them. unlike URPF strict this will not cause an outage every time a prefix is withdrawn but traffic continues to flow (which is a normal and healthy part of doing maintenance). on the other hand it means your prefix lists will have to be rather up to date and your peers will likely have to be very up to date with their customers. since failures for inclusion will cause black holes. you can't do this on on and MLPE exchange where you export routes unless you want to cause an outage everytime a new peer is added. there is also the problem of the number of cam slots these IP acls chew up. bgpq3 -P AS-FOO
This would allow us to peer with OVH et al, and not worry as much. Furthermore, whereas BCP 38 is reliant upon everybody, this could significantly reduce amplification attacks with even just a handful of adopters.
The source addresses of attack traffic associated with for example memcached (and in fact virtually all reflection attacks) are not spoofed.
—ToddOn Feb 28, 2018, at 6:52 PM, Job Snijders <job () ntt net> wrote: On Tue, Feb 27, 2018 at 09:52:54PM +0000, Chip Marshall wrote:On 2018-02-27, Ca By <cb.list6 () gmail com> sent:Please do take a look at the cloudflare blog specifically as they name and shame OVH and Digital Ocean for being the primary sources of mega crap traffic https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ Also, policer all UDP all the time... UDP is unsafe at any speed.Hi, DigitalOcean here. We've taken steps to mitigate this attack on our network.NTT too has deployed rate limiters on all external facing interfaces on the GIN backbone - for UDP/11211 traffic - to dampen the negative impact of open memcached instances on peers and customers. The toxic combination of 'one spoofed packet can yield multiple reponse packets' and 'one small packet can yield a very big response' makes the memcached UDP protocol a fine example of double trouble with potential for severe operational impact. Kind regards, Job
Attachment:
signature.asc
Description: OpenPGP digital signature
Current thread:
- BCP 38 addendum (was: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) Todd Crane (Mar 02)
- Re: BCP 38 addendum (was: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) Mike Hammett (Mar 02)
- Re: BCP 38 addendum joel jaeggli (Mar 02)
- Re: BCP 38 addendum (was: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks) Barry Raveendran Greene (Mar 02)
- Re: BCP 38 addendum Fabien VINCENT (NaNOG) (Mar 04)
- Message not available
- Re: BCP 38 addendum Fabien VINCENT (NaNOG) (Mar 07)
- Re: BCP 38 addendum Saku Ytti (Mar 07)
- Re: BCP 38 addendum Fabien VINCENT (NaNOG) (Mar 09)
- Re: BCP 38 addendum Saku Ytti (Mar 07)
- Re: BCP 38 addendum Baldur Norddahl (Mar 11)
- Re: BCP 38 addendum Fabien VINCENT (NaNOG) (Mar 04)