Le 2018-03-02 22:07, Barry Raveendran Greene a écrit : > Hi Todd, > > What you are describing is uRPF VRF mode. This was phase 3 of the uRPF work. > Russ White and I worked on it while at Cisco. > > Given that you are setting up prefix filters with your peers, you can add to > the peering agreement that you will only accept packets whose source > addresses matches the prefixes sent. > > You then take that BGP session, feed that into a VRF on the interface, and > run uRPF against that VRF. If a source address does not match, drop. > > If the BGP session adds more routes, those automatically update the VRF > "white list" for the uRPF. > > It was build to scale. Not sure where it is at in the code or the hardware. > Ask Cisco. > > Barry > > PS - So yes, you can do uRPF on your peering sessions. It was coded and > deployed back in 2006. > > On Mar 1, 2018, at 13:57, Todd Crane <t...@toddcrane.com> 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. > > 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. > > --Todd > > On Feb 28, 2018, at 6:52 PM, Job Snijders <j...@ntt.net> wrote: > > On Tue, Feb 27, 2018 at 09:52:54PM +0000, Chip Marshall wrote: On 2018-02-27, > Ca By <cb.li...@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 Hope one day the 3rd mode of uRPF will be something else than a plan ... uRPF is not very usefull when multi homed. And as far as I know, multi homed networks are increasing as fast as PNI development ;) -- FABIEN VINCENT _@beufanet_
