[191705] in North American Network Operators' Group
Re: Krebs on Security booted off Akamai network after DDoS attack
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sun Sep 25 20:48:16 2016
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <20160926003218.2F7075505E5D@rock.dv.isc.org>
Date: Sun, 25 Sep 2016 18:45:57 -0600
To: Mark Andrews <marka@isc.org>
Cc: John Levine <johnl@iecc.com>, nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
Assuming all transit providers your packets may traverse on the way to =
all of your
customers is the kind of thing that leads to me quoting Mr. Bush=E2=80=A6
=E2=80=9CI encourage my competitors to try this.=E2=80=9D
Owen
> On Sep 25, 2016, at 6:32 PM, Mark Andrews <marka@isc.org> wrote:
>=20
>=20
> In message <A3E266A0-2E94-4623-9300-2E15FE574BD6@delong.com>, Owen =
DeLong writes:
>>=20
>>> On Sep 24, 2016, at 8:47 AM, John Levine <johnl@iecc.com> wrote:
>>>=20
>>>>> Well...by anycast, I meant BGP anycast, spreading the "target"
>>>>> geographically to a dozen or more well connected/peered origins. =
At
>> that
>>>>> point, your ~600G DDoS might only be around
>>>>=20
>>>> anycast and tcp? the heck you say! :)
>>>=20
>>> People who've tried it say it works fine. Routes don't flap that =
often.
>>=20
>> It=E2=80=99s not just about route flap.
>>=20
>> Imagine the following. For any two any cast points A,B, one can draw =
a
>> simple Venn diagram of two circles with equal radii overlapping to =
form
>> an OGIVE.
>>=20
>> Consider that everyone in the nonintersecting portion of circle A =
will
>> reach server A without issue.
>> Likewise, everyone in the nonintersecting portion of circle B will =
reach
>> server B without issue.
>> However, for some subset of those within the OGIVE, it=E2=80=99s =
entirely likely
>> that they will, instead, be broken by ECMP to both A and B.
>>=20
>> Here=E2=80=99s where it gets tricky=E2=80=A6
>>=20
>> The people running A and B are unlikely to ever know because of the
>> layers between the end user trapped in the OGIVE and the people =
running A
>> and B. Most likely, the end users will suffer in silence or go to =
another
>> website for their needs. If this is a small enough fraction of users,
>> then it won=E2=80=99t be statistically noticeable drop in overall =
traffic and A,B
>> may never know. For those few end-users that may actually attempt to
>> resolve the issue in some meaningful way, most likely they will call
>> their ISP rather than the administrators of A,B and if their ISP does
>> anything, rather than bug A,B, they will most likely simple make =
routing
>> more deterministic for this site for this end-user.
>>=20
>> This is the nature of any cast and how any cast problems with TCP get
>> solved (or don=E2=80=99t in most cases).
>>=20
>> It=E2=80=99s safe to ignore the silent minority that cannot really =
tell what is
>> happening in most cases, but that doesn=E2=80=99t mean it =E2=80=9Cwork=
s=E2=80=9D for any
>> standard I would consider valid.
>>=20
>> Owen
>=20
> Which is why sane operators carefully choose where they deploy ECMP
> or include hashes of the source and destination addresses into the
> distribution of traffic over otherwise equal paths.
>=20
> Mark
> --=20
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
