Why was this modded down instead of up?

-----

1. There are three generally agreed-upon planes, not two - control, management, and data.

2. The described methodology isn't novel. Observing the effects of attacks is something attackers do routinely, as is attack selectivity in order to garner maximum impact. This goes back a couple of decades with regards to DDoS attacks in particular.

3. Routers will continue to forward and process priority 6/7 traffic - i.e., control-plane traffic like BGP - whilst dropping enough data-plane traffic to ensure sufficient link bandwidth & RP/LC CPU overhead to keep routing sessions up and process routing updates. This undercuts the central thesis of the paper.

4. Re-marking all priority 6/7 traffic at the edge is a best current practice (BCP) for network operators; this prevents attackers from sending floods of priority 6/7 traffic in order to force punts.

5. iACLs and GTSM, two more BCPs, protect BGP sessions against direct attack via SYN-flooding, et. al.

6. Control-plane policing (CoPP) is yet another BCP which indirectly limits the number of updates/sec via rate-limiting control-plane traffic exchanged between routers.

So, the assertions of novelty in the paper aren't really justified, nor are all the assumptions and assertions regarding the way routers work and the way they handle control-plane traffic. Also, standard BCPs to protect control-plane traffic aren't taken into account. Nor are routine defensive BCPs discussed and taken into account.

Finally, there are other mechanisms which are considerably more effective in disrupting control-plane communication due to high RP CPU which aren't touched upon in the paper, nor are they cited in references. Though there are defenses against those attack mechanisms, as well, they aren't as well-known.

It's generally a good idea for researchers to consult with members of the global operational security (opsec) community while looking for topics and methodologies which are truly unique. This saves a lot of time and effort in duplicating existing work and going down paths which don't lead to truly novel research and results.

It's also a good idea for researchers investigating routing resilience to launch real attacks (in a lab environment) on real routers, rather than just theorizing and simulating, in order to gain an understanding of how they actually behave under attack, and how the various BCPs and other defensive mechanisms come into play.

This .pdf presentation may be of interest, as well.

You're right that the article doesn't delve into the technical specifics - but the report the article is describing, available via this link provides more details.

The essence of the issue is that DDoS attacks are attacks against capacity and/or state. Even the largest firewalls commercially available or that one can build have limited state-table sizes.

Placing stateful firewalls in front of client access networks makes sense - when your Web browser requests the TCP/IP stack on your client device to set up a three-way TCP handshake with example.com, there's an outgoing SYN request which traverses the stateful firewall, and the stateful firewall makes a note of this in its state table. When the SYN-ACK response comes back from the example.com server, the stateful firewall checks to see if there's a corresponding outbound request and that the incoming response conforms with the firewall policies - if the answers to both questions is 'yes', then the firewall passes the server response packets. If the answer to either question is 'no', the stateful firewall drops the inappropriate server response.

When we're talking about Web servers, DNS servers, et. al., however, basically every incoming request is unsolicited - therefore, there is no state to inspect. This is why it makes zero sense to put a stateful firewall in front of servers.

Instead, the server OS and apps (Apache, BIND, sendmail, whatever) should be hardened, tcpwrappers should be deployed on the server to provide onboard stateless policy filtering, and stateless Access Control Lists (ACLs) should be implemented on your hardware-based routers and/or layer-3 switches in order to enforce network access policy - e.g., allow TCP/80 and TCP/443 for a standard SSL-enabled Web server, allow UDP/53 and TCP/53 for a DNS server, etc., and then disallow anything else from the outside.

Here's a .pdf presentation from a recent NANOG conference which makes the same point.

When stateful firewalls are used to enforce these polices which ought to be enforced by stateless ACLs per the above, the state-table limitations of even the largest firewalls form a significant DDoS chokepoint. Attackers can craft well-formed attack traffic which will conform to the firewall rules, but which will 'crowd out' legitimate requests from users, and which in many cases causes an error condition on the stateful firewall which causes it to stop forwarding packets altogether. This leads to a DoS of the firewall itself and all the servers behind it.

I've seen this over and over and over again, even with very large firewalls. It's far easier to DoS the largest firewall in existence than it is to DoS well-tuned, hardened server TCP/IP stacks.

Servers should be protected from DDoS attacks via source-based remotely-triggered blackholes (S/RTBH), flowspec, and/or intelligent DDoS mitigation systems (IDMS) specifically designed for this application.

Load-balancers are also a DDoS state vector, but in many environments are a necessary evil. When they must be used (note that there are many ways to achieve clustering/load-balancing without making use of single-point load-balancers), they must be protected by the same stateless ACLs in terms of enforcing network access policy, and must furthermore be protected from DDoS by S/RTBH, flowspec, and/or IDMS.

'Application-layer firewalls', with their 'protocol inspectors', and so-called 'IPSes' are even worse. They carry even more state, and the protocol inspectors offer a broadened attack surface for exploitation and device compromise (you can find numerous examples of publicly-acknowledge buffer overflows, etc. which comprise security vulnerabilities in the inspectors of both commercial and open-source firewalls and 'IPSes'). Consequently, they fall over during even a moderate DDoS attack even more quickly than the equivalent basic stateful firewall.

To comply with the poorly-crafted PCI DSS standard, on-server 'application firewalls' like mod_security fulfill the firewall requirement.

If you're forced by poorly-thought-out policies/regulations to put a hardware-based stateful firewall in front of your servers, you should go ahead and enforce network access policies in the form of stateless ACLs on the hardware-based routers/layer-3 switches which are northbound of the firewall, and then protect the firewall against DDoS via S/RTBH, flowspec, and/or IDMS.

None of the popular sites/servers you make use of on a daily basis have stateful firewalls in front of them - at least, the ones that stay up, heh. Here's a link to a .pdf presentation which makes note of many of the above points, and points out that firewalls were the first thing to fail in the RoK/USA DDoS attacks in 2009, by way of a high-profile example (these failures happen daily, this is just one notorious example; also note that the RoK/USA DDoS attacks were neither high-volume nor sophisticated).

Actually he's got a point. Nobody arguse about it is using the right numbers for the right purpose. It has been going on for ages on this site.

Next thing you know, he'll be posting about the lulz on 4chan & his Facebook page. ;>

This is good advice, and gives me an opportunity to speak to the community at large: some of us who go to cons and are in a position to shake tons of hands politely decline. It's not because we're being dicks, it's because we know it's a good way to substantially decrease our chances of catching and spreading any germs.

I played the PAX Pandemic game, where the Enforcers handed out stickers to attendees that read [Carrier] [Infected] or [Immune] (There was also a [Patient Zero].

I got the [Immune] sticker, and by the time I got home on Monday, it was clear that I had the flu. I've had a fever between 100 and 104 all week that finally broke last night, but I'm going to the doctor today because I think whatever I had settled into my lungs. I'll tell him about the H1N1 outbreak and get tested if he wants to run the test, but at this point I think it's safe to assume that I was [Immune] to the Pig Plague, but definitely [Infected] with the damn PAX pox.

Even though it's been a week of misery, it was entirely worth it, and I don't regret going to PAX for a single second.

> Guess why Ron Paul ran for the Republicans? Because he knew that as a third party/independent he wouldn't even get on the ballets

You have to admit, the thought of Ron Paul en pointe in tights is a pretty powerful argument for censorship, in and of itself.

This is why my motto (and fundamental rule for life) is Don't be a dick: it's simple to understand, and reasonable people can agree on what it means.

Yes, but the thing is, *we know how to do all that*, we've done it before. Far better and easier and cheaper, IMHO, than this Ares nonsense with SRBs ready to kill the crew during launch.

Hell, we could take the Saturn Vs lying on the ground (3-4) of them, the unflown CMs and LMs lying around, and refurbish them, for starters!

What's maddening is that nobody involved in this debate seems to realize that:

1. We solved resonance and pogoing issues in the 1960s vis-a-vis the Saturn V stack.

2. We can simply dust off the Apollo 18-20 J-series mission plans and the Apollo X/ALSS/AES/LESA studies, and execute them.

3. All we need to actually get back to the Moon is a Saturn V stack updated with newer materials and automation technologies.

4. SRBs are insanely dangerous due to their non-throttalability, and should not be man-rated beyond the poorly-designed Shuttle stack.

We knew all this *more than 40 years ago* (we ignored the SRB issue back then, which led directly to Challenger); how can these people be so ignorant?!

Here's a link to just a few of the studies which were done of follow-on missions. Here are links to Apollo X, ALSS, AES, and LESA.

Stephen Baxter's Voyage is an interesting alternate history based upon some of these mission plans (although he's way too hard on the Germans, IMHO).

The bottom line - if NASA want to go back to the Moon (far better to offer a $20B X-Prize for the first organization to put 30 men on the Moon for a year and a day, and return them safely to Earth), all they have to do is to start building modernized Saturn Vs, Apollo CMs, SMs, & LMs.

+1. So many people fail to understand the purpose of the Second Amendment.

As I have told countless friends through the years: the Second Amendment is not about duck hunting.