Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Owen DeLong <owen () delong com>]

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…

“I encourage my competitors to try this.”

Owen

> On Sep 25, 2016, at 6:32 PM, Mark Andrews <marka () isc org> wrote:
>
>
> In message <A3E266A0-2E94-4623-9300-2E15FE574BD6 () delong com>, Owen DeLong writes:
> > > On Sep 24, 2016, at 8:47 AM, John Levine <johnl () iecc com> wrote:
> > >
> > > > > 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
> > > >
> > > > anycast and tcp? the heck you say! :)
> > >
> > > People who've tried it say it works fine.  Routes don't flap that often.
> >
> > It’s not just about route flap.
> >
> > 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.
> >
> > 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’s entirely likely
> > that they will, instead, be broken by ECMP to both A and B.
> >
> > Here’s where it gets tricky…
> >
> > 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’t 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.
> >
> > This is the nature of any cast and how any cast problems with TCP get
> > solved (or don’t in most cases).
> >
> > It’s safe to ignore the silent minority that cannot really tell what is
> > happening in most cases, but that doesn’t mean it “works” for any
> > standard I would consider valid.
> >
> > Owen
>
> 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.
>
> Mark
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka () isc org