Vyatta as a BRAS

Sun Jul 18 02:47:26 UTC 2010

On Wed, 14 Jul 2010 14:12:07 +0000
"Dobbins, Roland" <rdobbins at arbor.net> wrote:

> 
> On Jul 14, 2010, at 8:48 PM, Florian Weimer wrote:
> 
> > From or to your customers?
> 
> Both.
> 
> > Stopping customer-sourced attacks is probably a good thing for the Internet at learge.
> 
> Concur 100%.
> 
> >  And you can't combat attacks targeted at customers within your own network unless you've got very large WAN
> > pipes, moving you into the realm of special-purpose hardware for other reasons.
> 
> Sure, you can, via S/RTBH, IDMS, et. al.  While DNS reflection/amplification attacks are used to create crushing volumes of attack traffic, and even smallish botnets can create high-volume attacks, most packet-flooding attacks are predicated on throughput - i.e., pps - rather than bandwidth, and tend to use small packets.  Of course, they can use *lots and lots* of small packets, and often do, but one can drop these packets via the various mechanisms one has available, then reach out to the global opsec community for filtering closer to the sources.
> 
> The thing is, with many DDoS attacks, the pps/bps/cps/tps required to disrupt the targets can be quite small, due to the unpreparedness of the defenders.  Many high-profile attacks discussed in the press such as the Mafiaboy attacks, the Estonian attacks, the Russian/Georgian/Azerbaijan attacks, the China DNS meltdown, and the RoK/USA DDoS attacks were all a) low-volume, b) low-throughput, c) exceedingly unsophisticated, and d) eminently avoidable via sound architecture, deployment of BCPs, and sound operational practices.
> 
> In fact, many DDoS attacks are quite simplistic in nature and many are low in bandwidth/throughput; the miscreants only use the resources necessary to achieve their goals, and due to the unpreparedness of defenders, they don't have a need to make use of overwhelming and/or complex attack methodologies.
> 
> This doesn't mean that high-bandwidth, high-throughput, and/or complex DDoS attacks don't occur, or that folks shouldn't be prepared to handle them; quite the opposite, we see a steady increase in attack volume, thoughput and sophistication at the high end.  But the fact of the matter is that many DDoS targets - and associated network infrastructure, and services such as DNS - are surprisingly fragile, and thus are vulnerable to surprisingly simple/small attacks, or even inadvertent/accidental attacks.
> 
> > Previously, this was really a no-brainer because you couldn't get PCI
> > cards with the required interfaces, but with Ethernet everywhere, the
> > bandwidths you can handle on commodity hardware will keep increasing.
> 
> Concur 100%.
> 
> > Eventually, you'll need special-purpose hardware only for a smallish
> > portion at the top of the router market, or if you can't get the
> > software with the required protocol support on other devices.
> 
> I believe that the days of software-based routers are numbered, period, due to the factors you describe.  Of course, the 'top of the router market' seems to keep moving upwards, despite many predictions to the contrary.
> 

Since specific routers have been mentioned, care to comment on the Cisco
ASR? If the days of software-based routers are numbered, I'm sure
Cisco would have recognised that, and not gone and developed it (or
rather, bought the company that did).

It seems to me that three key factors that haven't been discussed in
this thread are the chances of failure, types of failure triggers and
consequence of failure. It seems to have been a binary hardware = no
failure, software = failure.

If you put large amounts of traffic on a single router, you're likely
to need a hardware router, driving up the cost, sacrificing flexibility
and re-deployability, and impacting very large numbers of network users
if it fails. You may not be vulnerable or as vulnerable to a DoS
(software punt mentioned), but DoS's aren't the only type of failure you
can suffer from. Software faults on these high end platforms can be a
far more common issue within the first few years of release, because
they're less widely deployed. Hardware forwarding doesn't protect you
from protocol or protocol implementation vulnerabilities on the control
plane, and since these are big boxes with a big consequence if they
fail, they're a much larger target to aim for.

OTOH, if you have options to divide the traffic load across a number of
smaller routers, then you may gain the cost effectiveness of more
commodity platforms (with the ultimate commodity platform being a PC
acting as a router), more robustness because the platform is being used
by far more people in far more environments, and less of a consequence
when failures occur (DoS or not).

I don't think the hardware/software augment is as simple as it is being
made out to be. It is completely context dependent. Cost, availability,
scalability and flexibility all need to be considered. I personally put
a fair bit of weight on flexibility, because I can't tell the future,
and therefore a software upgrade to an existing platform is a useful
property compared to a fork lift replacement, and a box now sitting on
the floor that can't be re-deployed anywhere else in the network. As
long as you're aware of the associated limitations, you may be able to
engineer around them, or around them enough, depending on the context.

> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
> 
>     Injustice is relatively easy to bear; what stings is justice.
> 
>                         -- H.L. Mencken
> 
> 
> 
> 