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? -- Jim Mercer jim@reptiles.org +1 416 410-5633 You are more likely to be arrested as a terrorist than you are to be blown up by one. -- Dianora
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
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. On May 30, 2011, at 7:43 AM, Rubens Kuhl wrote:
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
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
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.
On May 30, 2011, at 7:43 AM, Rubens Kuhl wrote:
ms made by the product descriptions seem suspect to me.
it claims to be "Carrier-agnostic and ISP-neutral", yet "When an
detected, Verisign will work with the customer to redirect Internet
event is 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
On Tue, May 31, 2011 at 3:06 PM, Deepak Jain <deepak@ai.net> wrote:
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
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.
On May 30, 2011, at 7:43 AM, Rubens Kuhl wrote:
ms made by the product descriptions seem suspect to me.
it claims to be "Carrier-agnostic and ISP-neutral", yet "When an
detected, Verisign will work with the customer to redirect Internet
event is 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
-----Original Message----- From: Christopher Morrow [mailto:morrowc.lists@gmail.com] Sent: Tuesday, May 31, 2011 3:31 PM Subject: Re: VeriSign Internet Defense Network
also, note that VerizonBusiness ddos-mitigation service was no-call-required, just send the right community on a configured session ... and 'cheap'.
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
-----Original Message----- From: Deepak Jain [mailto:deepak@ai.net] Sent: Tuesday, May 31, 2011 3:07 PM Subject: RE: VeriSign Internet Defense Network
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].
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
-----Original Message----- From: Jim Mercer [mailto:jim@reptiles.org] Sent: Monday, May 30, 2011 10:26 AM To: nanog@nanog.org Subject: Verisign Internet Defence Network
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?
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
At 10:25 30/05/2011 -0400, Jim Mercer wrote: 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
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?
-- Jim Mercer jim@reptiles.org +1 416 410-5633 You are more likely to be arrested as a terrorist than you are to be blown up by one. -- Dianora
On 5/31/11 10:26 PM, Hank Nussbacher wrote:
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.
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
-----Original Message----- From: Seth Mattinen [mailto:sethm@rollernet.us] Sent: Wednesday, June 01, 2011 2:44 AM To: nanog@nanog.org Subject: Re: Verisign Internet Defence Network
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.
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
participants (8)
-
Christopher Morrow -
Deepak Jain -
Hank Nussbacher -
Jim Mercer -
Joel Jaeggli -
Rubens Kuhl -
Seth Mattinen -
Stefan Fouant