TCP Middlebox Reflection: Coming to a DDoS Near You | Hacker News Reader

TCP Middlebox Reflection: Coming to a DDoS Near You

akamai.com

83 pointssohkamyung8 comments

> Another concerning finding by the original authors is the existence of boxes that do handle RST packets. These boxes, when receiving a RST packet, react by resending the data packet they’d already transmitted that triggered the RST in the first place; this will in turn result in another RST, and another data packet. This means that there are cases in which a box can and will end up in what amounts to an “infinite loop” of self-perpetuation amplification.

That's the crazy part here. Not only do you get amplification, but it keeps going on its own until a packet gets dropped. So you get an amplification of X times, times how many times the whole thing goes back and forth on its own.

I'm very surprised that source spoofing is still a problem. Fix your damn networks people...

Or maybe shady providers allow this on purpose to entice black-hats?

Strict URPF cannot be applied to any customer that might be multihomed, which rules out any BGP customer or peer.

The reason is that multi-homed networks are not required to, and often do not advertise the same routes to all of their BGP peers. This may be done for routing policy purposes, traffic engineering, or simply to mitigate a temporary performance problem/outage with one of your transit providers/peers.

This means that strict URPF has to be deployed on the many networks that are close to statically routed end users. However, even statically routed customers could be multihomed and send traffic asymmetrically. This is not common but could cause headaches for support - even if you make an exception it could get accidentally overridden in the future.

On my networks (data center/hosting) we configure strict URPF on statically routed customers by default but not for BGP customers.

How are transit providers supposed to do source filtering on each other?

Where Centurylink peers with Verizon, where is Centurylink supposed to get that source filtering table from? What if a Centurylink customer (who has their own AS) dumps them for Verizon?

This problem repeats with the Tier-2 transit carriers, and Tier-3, and so on.

You're expecting an exponential number of source filter updates every time somebody moves their route announcement from one provider to another. This does not scale.

Source filtering can only really be implemented when you're taking traffic from a network for which you are the only uplink. If El Badguy (tm) is on one of these networks there really isn't a practical place to source-filter them.

At least for connectionless protocols, just do harsh source filtering and blackhole packets that don't comply... that's possible these days, right?

Give the peers some time; 3 months should seem enough for all that can't explain why they need a 3 month extension. And yes, this of course relies on assumed symmetric paths (even if asymmetric ones may get chosen after prioritizing).

Is there an easy way to test if a middlebox is vulnerable to this so you know if you need to patch it / mitigate the issue?

Their source code is here: https://github.com/breakerspace/weaponizing-censors

Perhaps not dead-simple easy, but it's a modified zmap and a short python script that calls it, so not that hard. With a relatively straightforward README.

There's also a mitigation shown that you could probably translate to whatever router/middlebox you have. Just a rule to drop any SYN packets going to the middlebox with a packet length greater than 100.

The paper was briefly discussed at https://news.ycombinator.com/item?id=28546125

Reply on news.ycombinator.com