Heyo,
So, I asked to look into the viability and usefullness of the "Verisign
Internet Defence Network" service.
I don't claim to be any kind of expert in DDoS mitigation, but some of the
claims made by the product descriptions seem suspect to me.
it claims to be "Carrier-agnostic and ISP-neutral", yet "When an event is
detected, Verisign will work with the customer to redirect Internet traffic
destined for the protected service to a Verisign Internet Defense Network
site."
anyone here have any comments on how this works, and how effective it will be
vs. dealing directly with your upstream providers and getting them to assist
in shutting down the attack?
ms made by the product descriptions seem suspect to me.
it claims to be "Carrier-agnostic and ISP-neutral", yet "When an event is
detected, Verisign will work with the customer to redirect Internet traffic
destined for the protected service to a Verisign Internet Defense Network
site."
anyone here have any comments on how this works, and how effective it will be
vs. dealing directly with your upstream providers and getting them to assist
in shutting down the attack?
Anyone willing to announce your IP blocks under attack, receive the
traffic and then tunnel the non-attack traffic back to you can provide
such services without cooperation from your upstreams. I don't know
the details about this particular provider, such as if they announce
your blocks from yours or theirs ASN, if they use more specifics,
communities or is simply very well connected, but as BGP on the DFZ
goes, it can work.
You might need to get your upstreams to not filter announcements from
your IP block they receive, because that would prevent mitigation for
attack traffic from inside your upstream AS.
(RPKI could also be a future challenge for such service, but one could
previously sign ROAs to be used in an attack response)
Rubens
It's really very simple. Verisign advertises your netblock to the Internet
at whole while at the same time you cease to advertise your route to your
ISPs. Traffic gets redirected into VIDN scrubbing center where the bad
traffic is removed. The resulting clean traffic is sent via GRE tunnel back
to customer CPE router.
Regarding how effective it will be vs. getting your upstream to assist
really depends on how many upstream providers you have and what their
capabilities are. Certainly dealing with one company (Verisign) is going to
be a lot easier than dealing with many upstream providers which are likely
to not have uniform offerings and services. Most providers that are going
to be willing to assist you are only going to null-route traffic towards the
destination netblock thereby completing the DoS attack. Those that do have
mitigation offerings are going to charge you for it, and then again, it's
not a uniform offering across all your upstream providers.
I personally think the "cloud-based" approach offered by Verisign makes a
whole heckuva lot more sense than trying to deal with heterogeneous
offerings from many disparate providers, much less having to open tickets
with each provider, having to deal with typical response times, etc. In my
experience, reducing the number of cogs usually results in dramatically
lower mitigation times, which is certainly the end goal in dealing with
these types of attacks.
Stefan Fouant
JNCIE-M #513, JNCIE-ER #70, JNCI
GPG Key ID: 0xB4C956EC
Normally when mitigation is put in place, they advertise a more specific prefix from as26415, scrub the traffic and hand it back to you over a gre tunnel...
Obviously some design consideration goes into having services in prefixes you're willing to de-agg in such a fashion... I'd also recommend advertising the more specific out your own ingress paths before they pull your route otherwise the churn while various ASes grind through their longer backup routes takes a while.
Let's not ignore the value of DNS with a short ttl time. It may not be "as quick" as a BGP adjustment, but serves to provide a buttressed front-end IP that can restore service "instantly" [faster than getting someone on the phone to coordinate the change, etc].
Disclaimer: We provide a service for our customers that does substantially this sort of DDOS mitigation.
DJ
Let's not ignore the value of DNS with a short ttl time. It may not be "as quick" as a BGP adjustment, but serves to provide a buttressed front-end IP that can restore service "instantly" [faster than getting someone on the phone to coordinate the change, etc].
Disclaimer: We provide a service for our customers that does substantially this sort of DDOS mitigation.
also, note that VerizonBusiness ddos-mitigation service was
no-call-required, just send the right community on a configured
session ... and 'cheap'.
-chris
Heck, if it's good enough for fast-flux, it's good enough for me 
Stefan Fouant
JNCIE-M #513, JNCIE-ER #70, JNCI
GPG Key ID: 0xB4C956EC
The downside to their approach is that it only works for sites you actually
have connected to VzB's network. They could just as easily offer the
service to off-net customers similar to what Verisign and Prolexic do, but
for some reason we could never convince the marketing folks to do just
that...
Agreed though, it is super-easy to use and competitively priced.
Stefan Fouant
JNCIE-M #513, JNCIE-ER #70, JNCI
GPG Key ID: 0xB4C956EC
My knowledge is from 1.5 years ago when I compared Verisign, Prolexic, Akamai and others so things may have changed since then.
VeriSign claim that they are servicing their own network globally which has performed with zero down time over the last decade. Verisign have 2 offerings - one over BGP and the other over GRE/SSL VPNs. The BGP solution would be faster to turn on but will require more configuration set-up. Interestingly, their mitigation service is not 'always-on' (they sell their monitoring and mitigation services seperately). On detection of an attack, they contact the customer and only once the customer acknowledges that they want their services "redirected" do they turn on the filtering.
My biggest gripe was their SLA - or lack of one. Back in Dec 2009 I forced them to start writing an SLA which they had not thought of, which back then showed an immaturity of service. Things might be different now. Verisign then took the view that the SLA should be based on *their* mitigation platform availability ("our scrubbing center has 100% SLA") and not on the customer site availability (all great and wonderful that your scrubbing center is up and running - but my site is down). They were willing to give service credits if their scrubbing center was down but not if the customer site was down.
I found they had a well established customer portal and ample reporting facilities.
Just make sure they have improved on their SLA before buying.
Regards,
Hank
Sounds like a catch-22 though; if it's not always on and only starts
scrubbing after an attack begins (pending activation approval from the
customer which may take time), then the customer site is quite possibly
already down when they start doing their thing to make it come back up.
~Seth
Well that's exactly how it works in most cases. Customers don't usually avail of these types of services until there is a problem, which usually means their site is down in most cases. This is why having proper visibility is key as they can serve as an early warning system giving indication of an impending attack prior to it becoming big enough to bring the site down (usually it takes several minutes to ramp up the attack during the time the bots receive instruction-set from the bot herder).
The problem with an always-on mitigation service is that there are additional latencies involved in the redirection (assuming it's not in-line), not to mention the inspections/proxying/filtering that the mitigation devices perform. Note that these latencies will be substantially less on an on-net service offering like Verizon's whereas they can be substantially higher on an off-net service offering from folks like Verisign/Prolexic, etc. These latencies are generally acceptable when a site is under attack, but not desired under normal circumstances.
Stefan Fouant
JNCIE-M #513, JNCIE-ER #70, JNCI
GPG Key ID: 0xB4C956EC