Re: BCP 38 addendum (was: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

[Barry Raveendran Greene]

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  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  wrote:
>> 
>> On Tue, Feb 27, 2018 at 09:52:54PM +, Chip Marshall wrote:
>>> On 2018-02-27, Ca By  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
> 

Re: BCP 38 addendum (was: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

[Mike Hammett]

https://en.wikipedia.org/wiki/Reverse_path_forwarding#Loose_mode towards 
transit. 

https://en.wikipedia.org/wiki/Reverse_path_forwarding#Strict_mode towards 
customers. 

Peers... *shrugs*. 



- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Todd Crane"  
To: "NANOG list"  
Cc: "Job Snijders"  
Sent: Thursday, March 1, 2018 12:57:53 PM 
Subject: BCP 38 addendum (was: New Active Exploit: memcached on port 11211 UDP 
& TCP being exploited for reflection attacks) 

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  wrote: 
> 
> On Tue, Feb 27, 2018 at 09:52:54PM +, Chip Marshall wrote: 
>> On 2018-02-27, Ca By  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 

BCP 38 addendum (was: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

[Todd Crane]

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  wrote:
> 
> On Tue, Feb 27, 2018 at 09:52:54PM +, Chip Marshall wrote:
>> On 2018-02-27, Ca By  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



signature.asc
Description: Message signed with OpenPGP