[141044] in North American Network Operators' Group
Re: Verisign Internet Defence Network
daemon@ATHENA.MIT.EDU (Joel Jaeggli)
Mon May 30 11:06:16 2011
From: Joel Jaeggli <joelja@bogus.com>
In-Reply-To: <BANLkTimQYR79rJvM0PHYk0=1nSqoCfxY-w@mail.gmail.com>
Date: Mon, 30 May 2011 08:05:19 -0700
To: Rubens Kuhl <rubensk@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
>>=20
>> 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."
>>=20
>> 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?
>=20
> 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.
>=20
> 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.
>=20
> (RPKI could also be a future challenge for such service, but one could
> previously sign ROAs to be used in an attack response)
>=20
> Rubens
>=20
