Re: "Defensive" BGP hijacking?

[Bryant Townsend]

Hello,

We wanted to clarify that we are not the ones behind these attacks and we
were not the ones behind the previous hijackings. We have also been the
targets of DDoS attacks reaching up to 200+ Gbps (~20 times a day), every
day since Krebs' original article that included our name. We believe these
attacks are coming from vDOS past customers and other botnets that used the
vDOS service for launching and selling attacks. We have also been targeted
with what seems to be multiple e-mail list bombs in attempts to delay our
response time. As I mentioned before, NANOG's trust means everything in
this industry and we want to be able to answer as much as we can.

Sincerely,
Bryant Townsend

On Tue, Sep 20, 2016 at 8:28 PM, Tom Beecher  wrote:

> Brian Krebs tweeted out that Prolexic reported a 665Gbps attack directed at
> his site.
>
> https://twitter.com/briankrebs/status/778398865619836928
>
> On Tue, Sep 20, 2016 at 11:21 PM, Mel Beckman  wrote:
>
> > While I was reading the krebsonsecurity.com article cited below, the
> > site, hosted at Akamai address 72.52.7.144, became non responsive and now
> > appears to be offline. Traceroutes stop before the Akamai-SWIPed border
> > within Telia, as if blackholed (but adjacent IPs pass through to Akamai):
> >
> > traceroute to krebsonsecurity.com (72.52.7.144), 64 hops max, 40 byte
> > packets
> >  1  router1.sb.becknet.com (206.83.0.1)  0.771 ms  0.580 ms  0.342 ms
> >  2  206-190-77-9.static.twtelecom.net (206.190.77.9)  0.715 ms  1.026 ms
> > 0.744 ms
> >  3  ae1-90g.ar7.lax1.gblx.net (67.17.75.18)  9.532 ms  6.567 ms  2.912
> ms
> >  4  ae10.edge1.losangeles9.level3.net (4.68.111.21)  2.919 ms  2.925 ms
> > 2.904 ms
> >  5  telia-level3-4x10g.losangeles.level3.net (4.68.70.130)  3.981 ms
> > 3.567 ms  3.401 ms
> >  6  sjo-b21-link.telia.net (62.115.116.40)  11.209 ms  11.140 ms  11.161
> > ms
> >  7  * * *
> >  8  * * *
> >  9  * * *
> > 10  * * *
> >
> > Weird coincidence?
> >
> >  -mel beckman
> >
> > > On Sep 20, 2016, at 6:46 PM, Hugo Slabbert  wrote:
> > >
> > > Lucy, you got some (*serious*) 'splainin to do...
> > >
> > > http://research.dyn.com/2016/09/backconnects-suspicious-bgp-hijacks/
> > > http://krebsonsecurity.com/2016/09/ddos-mitigation-firm-
> > has-history-of-hijacks/
> > >
> > > --
> > > Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> > > pgp key: B178313E   | also on Signal
> > >
> > >> On Sun 2016-Sep-18 22:25:44 -0400, Tom Beecher 
> > wrote:
> > >>
> > >> So after reading your explanation of things...
> > >>
> > >> Your technical protections for your client proved sufficient to handle
> > the
> > >> attack. You took OFFENSIVE action by hijacking the IP space. By your
> own
> > >> statements, it was only in response to threats against your company.
> You
> > >> were no longer providing DDoS protection to a client. You were
> exacting
> > a
> > >> vendetta against someone who was being MEAN to you. Even if that
> person
> > >> probably deserved it, you still cannot do what was done.
> > >>
> > >> I appreciate the desire to want to protect friends and family from
> > >> anonymous threats, and also realize how ill equipped law enforcement
> > >> usually is while something like this is occurring.
> > >>
> > >> However, in my view, by taking the action you did, you have shown your
> > >> company isn't ready to be operating in the security space. Being
> > threatened
> > >> by bad actors is a nominal part of doing business in the security
> space.
> > >> Unfortunately you didn't handle it well, and I think that will stick
> to
> > you
> > >> for a long time.
> > >>
> > >> On Tue, Sep 13, 2016 at 3:29 PM, Bryant Townsend <
> > bry...@backconnect.com>
> > >> wrote:
> > >>
> > >>> @ca & Matt - No, we do not plan to ever intentionally perform a
> > >>> non-authorized BGP hijack in the future.
> > >>>
> > >>> @Steve - Correct, the attack had already been mitigated. The decision
> > to
> > >>> hijack the attackers IP space was to deal with their threats, which
> if
> > >>> carried through could have potentially lead to physical harm.
> Although
> > the
> > >>> hijack gave us a unique insight into the attackers services, it was
> > not a
> > >>> factor that influenced my decision.
> > >>>
> > >>> @Blake & Mel - We will likely cover some of these questions in a
> future
> > >>> blog post.
> > >>>
> >
>

Re: "Defensive" BGP hijacking?

[Tom Beecher]

Brian Krebs tweeted out that Prolexic reported a 665Gbps attack directed at
his site.

https://twitter.com/briankrebs/status/778398865619836928

On Tue, Sep 20, 2016 at 11:21 PM, Mel Beckman  wrote:

> While I was reading the krebsonsecurity.com article cited below, the
> site, hosted at Akamai address 72.52.7.144, became non responsive and now
> appears to be offline. Traceroutes stop before the Akamai-SWIPed border
> within Telia, as if blackholed (but adjacent IPs pass through to Akamai):
>
> traceroute to krebsonsecurity.com (72.52.7.144), 64 hops max, 40 byte
> packets
>  1  router1.sb.becknet.com (206.83.0.1)  0.771 ms  0.580 ms  0.342 ms
>  2  206-190-77-9.static.twtelecom.net (206.190.77.9)  0.715 ms  1.026 ms
> 0.744 ms
>  3  ae1-90g.ar7.lax1.gblx.net (67.17.75.18)  9.532 ms  6.567 ms  2.912 ms
>  4  ae10.edge1.losangeles9.level3.net (4.68.111.21)  2.919 ms  2.925 ms
> 2.904 ms
>  5  telia-level3-4x10g.losangeles.level3.net (4.68.70.130)  3.981 ms
> 3.567 ms  3.401 ms
>  6  sjo-b21-link.telia.net (62.115.116.40)  11.209 ms  11.140 ms  11.161
> ms
>  7  * * *
>  8  * * *
>  9  * * *
> 10  * * *
>
> Weird coincidence?
>
>  -mel beckman
>
> > On Sep 20, 2016, at 6:46 PM, Hugo Slabbert  wrote:
> >
> > Lucy, you got some (*serious*) 'splainin to do...
> >
> > http://research.dyn.com/2016/09/backconnects-suspicious-bgp-hijacks/
> > http://krebsonsecurity.com/2016/09/ddos-mitigation-firm-
> has-history-of-hijacks/
> >
> > --
> > Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> > pgp key: B178313E   | also on Signal
> >
> >> On Sun 2016-Sep-18 22:25:44 -0400, Tom Beecher 
> wrote:
> >>
> >> So after reading your explanation of things...
> >>
> >> Your technical protections for your client proved sufficient to handle
> the
> >> attack. You took OFFENSIVE action by hijacking the IP space. By your own
> >> statements, it was only in response to threats against your company. You
> >> were no longer providing DDoS protection to a client. You were exacting
> a
> >> vendetta against someone who was being MEAN to you. Even if that person
> >> probably deserved it, you still cannot do what was done.
> >>
> >> I appreciate the desire to want to protect friends and family from
> >> anonymous threats, and also realize how ill equipped law enforcement
> >> usually is while something like this is occurring.
> >>
> >> However, in my view, by taking the action you did, you have shown your
> >> company isn't ready to be operating in the security space. Being
> threatened
> >> by bad actors is a nominal part of doing business in the security space.
> >> Unfortunately you didn't handle it well, and I think that will stick to
> you
> >> for a long time.
> >>
> >> On Tue, Sep 13, 2016 at 3:29 PM, Bryant Townsend <
> bry...@backconnect.com>
> >> wrote:
> >>
> >>> @ca & Matt - No, we do not plan to ever intentionally perform a
> >>> non-authorized BGP hijack in the future.
> >>>
> >>> @Steve - Correct, the attack had already been mitigated. The decision
> to
> >>> hijack the attackers IP space was to deal with their threats, which if
> >>> carried through could have potentially lead to physical harm. Although
> the
> >>> hijack gave us a unique insight into the attackers services, it was
> not a
> >>> factor that influenced my decision.
> >>>
> >>> @Blake & Mel - We will likely cover some of these questions in a future
> >>> blog post.
> >>>
>

Re: "Defensive" BGP hijacking?

[Justin Paine via NANOG]

earlier on Twitter Krebs said he was hit by 665Gbps attack (so says
Prolexic/Akamai). Could be ongoing/related.


Justin Paine
Head of Trust & Safety
CloudFlare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Tue, Sep 20, 2016 at 8:21 PM, Mel Beckman  wrote:
> While I was reading the krebsonsecurity.com article cited below, the site, 
> hosted at Akamai address 72.52.7.144, became non responsive and now appears 
> to be offline. Traceroutes stop before the Akamai-SWIPed border within Telia, 
> as if blackholed (but adjacent IPs pass through to Akamai):
>
> traceroute to krebsonsecurity.com (72.52.7.144), 64 hops max, 40 byte packets
>  1  router1.sb.becknet.com (206.83.0.1)  0.771 ms  0.580 ms  0.342 ms
>  2  206-190-77-9.static.twtelecom.net (206.190.77.9)  0.715 ms  1.026 ms  
> 0.744 ms
>  3  ae1-90g.ar7.lax1.gblx.net (67.17.75.18)  9.532 ms  6.567 ms  2.912 ms
>  4  ae10.edge1.losangeles9.level3.net (4.68.111.21)  2.919 ms  2.925 ms  
> 2.904 ms
>  5  telia-level3-4x10g.losangeles.level3.net (4.68.70.130)  3.981 ms  3.567 
> ms  3.401 ms
>  6  sjo-b21-link.telia.net (62.115.116.40)  11.209 ms  11.140 ms  11.161 ms
>  7  * * *
>  8  * * *
>  9  * * *
> 10  * * *
>
> Weird coincidence?
>
>  -mel beckman
>
>> On Sep 20, 2016, at 6:46 PM, Hugo Slabbert  wrote:
>>
>> Lucy, you got some (*serious*) 'splainin to do...
>>
>> http://research.dyn.com/2016/09/backconnects-suspicious-bgp-hijacks/
>> http://krebsonsecurity.com/2016/09/ddos-mitigation-firm-has-history-of-hijacks/
>>
>> --
>> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
>> pgp key: B178313E   | also on Signal
>>
>>> On Sun 2016-Sep-18 22:25:44 -0400, Tom Beecher  wrote:
>>>
>>> So after reading your explanation of things...
>>>
>>> Your technical protections for your client proved sufficient to handle the
>>> attack. You took OFFENSIVE action by hijacking the IP space. By your own
>>> statements, it was only in response to threats against your company. You
>>> were no longer providing DDoS protection to a client. You were exacting a
>>> vendetta against someone who was being MEAN to you. Even if that person
>>> probably deserved it, you still cannot do what was done.
>>>
>>> I appreciate the desire to want to protect friends and family from
>>> anonymous threats, and also realize how ill equipped law enforcement
>>> usually is while something like this is occurring.
>>>
>>> However, in my view, by taking the action you did, you have shown your
>>> company isn't ready to be operating in the security space. Being threatened
>>> by bad actors is a nominal part of doing business in the security space.
>>> Unfortunately you didn't handle it well, and I think that will stick to you
>>> for a long time.
>>>
>>> On Tue, Sep 13, 2016 at 3:29 PM, Bryant Townsend 
>>> wrote:
>>>
 @ca & Matt - No, we do not plan to ever intentionally perform a
 non-authorized BGP hijack in the future.

 @Steve - Correct, the attack had already been mitigated. The decision to
 hijack the attackers IP space was to deal with their threats, which if
 carried through could have potentially lead to physical harm. Although the
 hijack gave us a unique insight into the attackers services, it was not a
 factor that influenced my decision.

 @Blake & Mel - We will likely cover some of these questions in a future
 blog post.

Re: "Defensive" BGP hijacking?

[Mel Beckman]

While I was reading the krebsonsecurity.com article cited below, the site, 
hosted at Akamai address 72.52.7.144, became non responsive and now appears to 
be offline. Traceroutes stop before the Akamai-SWIPed border within Telia, as 
if blackholed (but adjacent IPs pass through to Akamai):

traceroute to krebsonsecurity.com (72.52.7.144), 64 hops max, 40 byte packets
 1  router1.sb.becknet.com (206.83.0.1)  0.771 ms  0.580 ms  0.342 ms
 2  206-190-77-9.static.twtelecom.net (206.190.77.9)  0.715 ms  1.026 ms  0.744 
ms
 3  ae1-90g.ar7.lax1.gblx.net (67.17.75.18)  9.532 ms  6.567 ms  2.912 ms
 4  ae10.edge1.losangeles9.level3.net (4.68.111.21)  2.919 ms  2.925 ms  2.904 
ms
 5  telia-level3-4x10g.losangeles.level3.net (4.68.70.130)  3.981 ms  3.567 ms  
3.401 ms
 6  sjo-b21-link.telia.net (62.115.116.40)  11.209 ms  11.140 ms  11.161 ms
 7  * * *
 8  * * *
 9  * * *
10  * * *

Weird coincidence?

 -mel beckman

> On Sep 20, 2016, at 6:46 PM, Hugo Slabbert  wrote:
> 
> Lucy, you got some (*serious*) 'splainin to do...
> 
> http://research.dyn.com/2016/09/backconnects-suspicious-bgp-hijacks/
> http://krebsonsecurity.com/2016/09/ddos-mitigation-firm-has-history-of-hijacks/
> 
> -- 
> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> pgp key: B178313E   | also on Signal
> 
>> On Sun 2016-Sep-18 22:25:44 -0400, Tom Beecher  wrote:
>> 
>> So after reading your explanation of things...
>> 
>> Your technical protections for your client proved sufficient to handle the
>> attack. You took OFFENSIVE action by hijacking the IP space. By your own
>> statements, it was only in response to threats against your company. You
>> were no longer providing DDoS protection to a client. You were exacting a
>> vendetta against someone who was being MEAN to you. Even if that person
>> probably deserved it, you still cannot do what was done.
>> 
>> I appreciate the desire to want to protect friends and family from
>> anonymous threats, and also realize how ill equipped law enforcement
>> usually is while something like this is occurring.
>> 
>> However, in my view, by taking the action you did, you have shown your
>> company isn't ready to be operating in the security space. Being threatened
>> by bad actors is a nominal part of doing business in the security space.
>> Unfortunately you didn't handle it well, and I think that will stick to you
>> for a long time.
>> 
>> On Tue, Sep 13, 2016 at 3:29 PM, Bryant Townsend 
>> wrote:
>> 
>>> @ca & Matt - No, we do not plan to ever intentionally perform a
>>> non-authorized BGP hijack in the future.
>>> 
>>> @Steve - Correct, the attack had already been mitigated. The decision to
>>> hijack the attackers IP space was to deal with their threats, which if
>>> carried through could have potentially lead to physical harm. Although the
>>> hijack gave us a unique insight into the attackers services, it was not a
>>> factor that influenced my decision.
>>> 
>>> @Blake & Mel - We will likely cover some of these questions in a future
>>> blog post.
>>> 

Re: "Defensive" BGP hijacking?

[Hugo Slabbert]

Lucy, you got some (*serious*) 'splainin to do...

http://research.dyn.com/2016/09/backconnects-suspicious-bgp-hijacks/
http://krebsonsecurity.com/2016/09/ddos-mitigation-firm-has-history-of-hijacks/

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

On Sun 2016-Sep-18 22:25:44 -0400, Tom Beecher  wrote:


So after reading your explanation of things...

Your technical protections for your client proved sufficient to handle the
attack. You took OFFENSIVE action by hijacking the IP space. By your own
statements, it was only in response to threats against your company. You
were no longer providing DDoS protection to a client. You were exacting a
vendetta against someone who was being MEAN to you. Even if that person
probably deserved it, you still cannot do what was done.

I appreciate the desire to want to protect friends and family from
anonymous threats, and also realize how ill equipped law enforcement
usually is while something like this is occurring.

However, in my view, by taking the action you did, you have shown your
company isn't ready to be operating in the security space. Being threatened
by bad actors is a nominal part of doing business in the security space.
Unfortunately you didn't handle it well, and I think that will stick to you
for a long time.

On Tue, Sep 13, 2016 at 3:29 PM, Bryant Townsend 
wrote:


@ca & Matt - No, we do not plan to ever intentionally perform a
non-authorized BGP hijack in the future.

@Steve - Correct, the attack had already been mitigated. The decision to
hijack the attackers IP space was to deal with their threats, which if
carried through could have potentially lead to physical harm. Although the
hijack gave us a unique insight into the attackers services, it was not a
factor that influenced my decision.

@Blake & Mel - We will likely cover some of these questions in a future
blog post.



signature.asc
Description: PGP signature

Re: "Defensive" BGP hijacking?

[John Curran]

On Sep 20, 2016, at 10:48 AM, Christopher Morrow 
mailto:morrowc.li...@gmail.com>> wrote:
On Tue, Sep 20, 2016 at 8:05 AM, John Curran 
mailto:jcur...@arin.net>> wrote:
...
If you want to just use your legacy address block (wth the same services that
where in place at ARIN's formation), then you don't need to enter into an LRSA -
but please do still update your registration in the ARIN registry to have 
current
contact data, as this helps deter potential hijackers.   If you want to have 
those
services that were developed since ARIN's formation, then I'd suggest reviewing
the actual current LRSA agreement, as it is significantly improved over earlier
versions.


and probably: "If you think there are still improvements, show up at arin 
meetings and lobby for change"

yes?

Absolutely.
/John

Re: "Defensive" BGP hijacking?

[Christopher Morrow]

On Tue, Sep 20, 2016 at 8:05 AM, John Curran  wrote:

> On Sep 19, 2016, at 11:58 PM, Christopher Morrow 
> wrote:
> >
> > (caution! I don't really think arin is evil!)
>
> Nor do I…  (but I will remind folks that organizations evolve based on
> participation,
> so ongoing diligence and involvement is definitely warranted.)
>
> > On Mon, Sep 19, 2016 at 1:16 PM, John Curran  wrote:
> >
> >> To be clear, he would still end up bound to an agreement which provides
> >> that they
> >> indemnify the RIR regarding their RPKI usage (which was the complaint
> >> expressed
> >> in the NANOG community regarding ARIN’s RPKI terms and conditions) -
> >>
> >>
> > maybe, but his point was that the evil (evile?) arin would not be putting
> > their clutches on his ip-address-spaces... Sure he's trading ARIN for
> RIPE
> > here, but I diidn't think the RPA bit was his concern as much as the LRSA
> > and 'now that you agree these are ip blocks are subject to the legacy
> > registry services agreement, we (arin - with twisty mustasche) might
> decide
> > to wrest them away from you!!!’
>
> A distinct possibly, but much improved in the current LRSA (and RSA, which
> are the same document at this point.)   Unless he’s planning to not pay the
> annual maintenance fee and ignore the notices and letters that follow over
> the next 120 days, or if going to make a serious misrepresentation in the
> process of claiming the rights to the address block, he’s fairly safe...
> for
> example,  ARIN now specifically disclaims revocation for lack of
> utilization.
> (Furthermore, if ARIN breaches its obligations, the status of the address
> block reverts to the same prior to entry the LRSA – this is definitely less
> than RIPE provides, which is effectively exit at any time, but far better
> than
> the original LRSA.)
>
> If you want to just use your legacy address block (wth the same services
> that
> where in place at ARIN’s formation), then you don’t need to enter into an
> LRSA –
> but please do still update your registration in the ARIN registry to have
> current
> contact data, as this helps deter potential hijackers.   If you want to
> have those
> services that were developed since ARIN’s formation, then I’d suggest
> reviewing
> the actual current LRSA agreement, as it is significantly improved over
> earlier
> versions.
>
>
and probably: "If you think there are still improvements, show up at arin
meetings and lobby for change"

yes?


> Thanks!
> /John
>
> John Curran
> President and CEO
> [Evil?] ARIN
>
>
>
>

Re: "Defensive" BGP hijacking?

[John Curran]

On Sep 19, 2016, at 11:58 PM, Christopher Morrow  
wrote:
> 
> (caution! I don't really think arin is evil!)

Nor do I…  (but I will remind folks that organizations evolve based on 
participation, 
so ongoing diligence and involvement is definitely warranted.) 

> On Mon, Sep 19, 2016 at 1:16 PM, John Curran  wrote:
> 
>> To be clear, he would still end up bound to an agreement which provides
>> that they
>> indemnify the RIR regarding their RPKI usage (which was the complaint
>> expressed
>> in the NANOG community regarding ARIN’s RPKI terms and conditions) -
>> 
>> 
> maybe, but his point was that the evil (evile?) arin would not be putting
> their clutches on his ip-address-spaces... Sure he's trading ARIN for RIPE
> here, but I diidn't think the RPA bit was his concern as much as the LRSA
> and 'now that you agree these are ip blocks are subject to the legacy
> registry services agreement, we (arin - with twisty mustasche) might decide
> to wrest them away from you!!!’

A distinct possibly, but much improved in the current LRSA (and RSA, which
are the same document at this point.)   Unless he’s planning to not pay the 
annual maintenance fee and ignore the notices and letters that follow over
the next 120 days, or if going to make a serious misrepresentation in the 
process of claiming the rights to the address block, he’s fairly safe... for 
example,  ARIN now specifically disclaims revocation for lack of utilization.
(Furthermore, if ARIN breaches its obligations, the status of the address 
block reverts to the same prior to entry the LRSA – this is definitely less 
than RIPE provides, which is effectively exit at any time, but far better than 
the original LRSA.)

If you want to just use your legacy address block (wth the same services that
where in place at ARIN’s formation), then you don’t need to enter into an LRSA –
but please do still update your registration in the ARIN registry to have 
current 
contact data, as this helps deter potential hijackers.   If you want to have 
those
services that were developed since ARIN’s formation, then I’d suggest reviewing 
the actual current LRSA agreement, as it is significantly improved over earlier
versions.

Thanks!
/John

John Curran
President and CEO
[Evil?] ARIN

Re: "Defensive" BGP hijacking?

[Christopher Morrow]

(caution! I don't really think arin is evil!)

On Mon, Sep 19, 2016 at 1:16 PM, John Curran  wrote:

> On Sep 14, 2016, at 4:59 PM, Christopher Morrow 
> wrote:
> >
> > On Wed, Sep 14, 2016 at 4:04 PM, Bryan Fields 
> wrote:
> >
> >> On 9/14/16 3:09 AM, Scott Weeks wrote:
> >>>
> >>> Yes, RPKI.  That's what I was waiting for.  Now we can get to
> >>> a real discussion
> >> ...
> >> sure as heck not going to sign a legally binding contract saying they
> do :)
> >>
> > don't have to... see press.
>
> Chris -
>
> To be clear, he would still end up bound to an agreement which provides
> that they
> indemnify the RIR regarding their RPKI usage (which was the complaint
> expressed
> in the NANOG community regarding ARIN’s RPKI terms and conditions) -
>
>
maybe, but his point was that the evil (evile?) arin would not be putting
their clutches on his ip-address-spaces... Sure he's trading ARIN for RIPE
here, but I diidn't think the RPA bit was his concern as much as the LRSA
and 'now that you agree these are ip blocks are subject to the legacy
registry services agreement, we (arin - with twisty mustasche) might decide
to wrest them away from you!!!'

I may have misinterpreted his issue, or not completed his unwritten thought
about the RPA.

 legal/ripe-ncc-certification-service-terms-and-conditions>
> "The Member shall indemnify the RIPE NCC against any and all third party
> claims filed against the RIPE NCC in relation to the Member’s use of the
> RIPE NCC Certification Service or the Certificate.”
>
> FYI,
> /John
>
> John Curran
> President and CEO
> ARIN
>
>
>
>
>
>

Re: "Defensive" BGP hijacking?

[John Curran]

On Sep 14, 2016, at 4:59 PM, Christopher Morrow  wrote:
> 
> On Wed, Sep 14, 2016 at 4:04 PM, Bryan Fields  wrote:
> 
>> On 9/14/16 3:09 AM, Scott Weeks wrote:
>>> 
>>> Yes, RPKI.  That's what I was waiting for.  Now we can get to
>>> a real discussion
>> ...
>> sure as heck not going to sign a legally binding contract saying they do :)
>> 
> don't have to... see press.

Chris - 

To be clear, he would still end up bound to an agreement which provides that 
they
indemnify the RIR regarding their RPKI usage (which was the complaint expressed 
in the NANOG community regarding ARIN’s RPKI terms and conditions) -


"The Member shall indemnify the RIPE NCC against any and all third party claims 
filed against the RIPE NCC in relation to the Member’s use of the RIPE NCC 
Certification Service or the Certificate.”

FYI,
/John

John Curran
President and CEO
ARIN

Re: "Defensive" BGP hijacking?

[Sean Rose]

And here's the final bit. I'd like to think that is 100% conclusive proof
of what happened.

The IP range hijacked by backconnect.net, 72.20.0.0/24 returns interesting
results on google:

https://staminus.thecthulhu.com/zine.txt

## Global allows
ALLOW_MAIN=""
ALLOW_MAIN="$ALLOW_MAIN $RFC1918 $LOCAL"
ALLOW_MAIN="$ALLOW_MAIN 72.20.1.2 72.20.0.0/24 69.197.1.0/24"   # Internal


Backconnect.net hijacked Staminus's internal management range 72.20.0.0/24
and used that to gain further access to Staminus's systems.

On Sat, Sep 17, 2016 at 11:32 PM, Sean Rose 
wrote:

> I know Bryant Townsend (ex staminus employee), Marshal Webb (aka m_nerva,
> lulzsec informant) and others from backconnect.net performed a similar
> BGP hijacking against staminus earlier this year.
>
> https://bgpstream.com/event/21051
>
> Shortly afterwards, on 10th of march a zine is released leaking the
> Staminus user database and contents of several customer servers.
>
> The times aren't the only interesting factor here, even the format of the
> release just screams m_nerva. Zines are very rare these days. So rare in
> fact that the last similar zine before the staminus hack was released in
> 2013 by HTP, a hacker group m_nerva was loosely affiliated with during it's
> early days.
>
> I *strongly* believe Bryant Townsend and Marshal Webb hacked Staminus and
> produced the "Fuck 'em all." zine
>
>
> Sean Rose
>

Re: "Defensive" BGP hijacking?

[Sean Rose]

I know Bryant Townsend (ex staminus employee), Marshal Webb (aka m_nerva,
lulzsec informant) and others from backconnect.net performed a similar BGP
hijacking against staminus earlier this year.

https://bgpstream.com/event/21051

Shortly afterwards, on 10th of march a zine is released leaking the
Staminus user database and contents of several customer servers.

The times aren't the only interesting factor here, even the format of the
release just screams m_nerva. Zines are very rare these days. So rare in
fact that the last similar zine before the staminus hack was released in
2013 by HTP, a hacker group m_nerva was loosely affiliated with during it's
early days.

I *strongly* believe Bryant Townsend and Marshal Webb hacked Staminus and
produced the "Fuck 'em all." zine


Sean Rose

Re: "Defensive" BGP hijacking?

[Tom Beecher]

So after reading your explanation of things...

Your technical protections for your client proved sufficient to handle the
attack. You took OFFENSIVE action by hijacking the IP space. By your own
statements, it was only in response to threats against your company. You
were no longer providing DDoS protection to a client. You were exacting a
vendetta against someone who was being MEAN to you. Even if that person
probably deserved it, you still cannot do what was done.

I appreciate the desire to want to protect friends and family from
anonymous threats, and also realize how ill equipped law enforcement
usually is while something like this is occurring.

However, in my view, by taking the action you did, you have shown your
company isn't ready to be operating in the security space. Being threatened
by bad actors is a nominal part of doing business in the security space.
Unfortunately you didn't handle it well, and I think that will stick to you
for a long time.

On Tue, Sep 13, 2016 at 3:29 PM, Bryant Townsend 
wrote:

> @ca & Matt - No, we do not plan to ever intentionally perform a
> non-authorized BGP hijack in the future.
>
> @Steve - Correct, the attack had already been mitigated. The decision to
> hijack the attackers IP space was to deal with their threats, which if
> carried through could have potentially lead to physical harm. Although the
> hijack gave us a unique insight into the attackers services, it was not a
> factor that influenced my decision.
>
> @Blake & Mel - We will likely cover some of these questions in a future
> blog post.
>

Re: "Defensive" BGP hijacking?

[Christopher Morrow]

On Fri, Sep 16, 2016 at 12:06 PM, Mel Beckman  wrote:

>
> Preventing government manhandling needs to be a design goal.
>

Can you proffer some potential solutions or directions to look?

At the end of the day the ISP or DNS operator or Enterprise is subject to
local law enforcement action(s), so I'm not sure there's a remedy to your
design goal.

Re: "Defensive" BGP hijacking?

[Mel Beckman]

Doug,

Although RPKI is voluntary and decisions are local, those decisions are also 
automated. DNS is voluntary, and decisions are local as well, yet the 
government has been able to leverage DNS to unilaterally seize domain names 
without due process. Like Maxwell's Demons, it's theoretically possible for 
ISPs everywhere to notice government malfeasance and rush to a unified decision 
to counter it. But in practice this never happens.

Preventing government manhandling needs to be a design goal.

 -mel beckman

On Sep 16, 2016, at 8:32 AM, Doug Montgomery 
mailto:dougm.w...@gmail.com>> wrote:

Ah, the global system I was referring to was the RPKI as distributed repository 
of routing information.  With consistent properties (data formats, security 
models, data validation techniques, etc) across all 5 RIRs.

What an ISP does with the RPKI data, interns of route filtering, is always a 
local policy decision.Somehow "global enforcement system" sounded like a 
vision where ISPs don't have a choice of how and where to use the system.  
Maybe I read too much into the phrasing.

In the end, I think the issues boils down to if the community has the desire 
and will to address the route hijack issue.If the answer is no, then no 
further discussion is needed.  If the answer is yes, then it is best to discuss 
and compare real proposals / mechanisms to address the issue at scale.

I am still interested in some detail on the "tyranny implications".  We can't 
address them until we know what they are and how they compare to any other 
solution that tries to address the same problem.

dougm

On Wed, Sep 14, 2016 at 6:04 PM, Mel Beckman 
mailto:m...@beckman.org>> wrote:
Doug,

I was basing my comments on your statement "If only there were a global 
system.."  However you slice or dice it, the tyranny implications have not yet 
been addressed. That certainly needs to be in front of any technical idea such 
as RPKI.

Although I haven't participated in the OT&E, nothing I've read in RFC 6810 
talks about these issues. It talks about authentication and transport security, 
but doesn't talk about the potential for government interference.

 -mel beckman

On Sep 14, 2016, at 8:22 AM, Doug Montgomery 
mailto:dougm.w...@gmail.com>> wrote:

Mel,

If you are speaking of RPKI based origin validation, I am not sure "automated / 
global enforcement system" is a useful description.   It does provide a 
consistent means for address holders to declare AS's authorized to announce 
prefixes, and a means for remote ASs to compare received updates vs such 
declarations.   What the receiving AS does with the validation information is 
strictly a local policy matter.

Frankly, this is no more a "new automated enforcement system" than IRR-based 
route filtering has been for 20 years.  The only difference is that there is a 
consistent security model across all 5 RIRs as to who can make such 
declarations and it is tightly tied to the address allocation business process.

I have seen a lot of FUD about the specter of interference, but not a lot of 
serious thought / discussion.  Having a serious technical discussion of 
potential risks and mitigations in the system would be useful.

dougm

On Wed, Sep 14, 2016 at 10:51 AM, Mel Beckman 
mailto:m...@beckman.org>> wrote:
Scott and Doug,

The problem with a new automated enforcement system is that it hobbles both 
agility and innovation. ISPs have enjoyed simple BGP management, entirely 
self-regulated, for decades. A global enforcement system, besides being dang 
hard to do correctly, brings the specter of government interference, since such 
a system could be overtaken by government entities to manhandle free speech.

In my opinion, the community hasn't spent nearly enough time discussing the 
danger aspect. Being engineers, we focus on technical means, ignoring the fact 
that we're designing our own guillotine.

 -mel beckman

> On Sep 14, 2016, at 12:10 AM, Scott Weeks 
> mailto:sur...@mauigateway.com>> wrote:
>
>
>
> --- dougm.w...@gmail.com wrote:
> From: Doug Montgomery mailto:dougm.w...@gmail.com>>
>
> If only there were a global system, with consistent and verifiable security
> properties, to permit address holders to declare the set of AS's authorized
> to announce their prefixes, and routers anywhere on the Internet to
> independently verify the corresponding validity of received announcements.
>
> *cough  https://www.nanog.org/meetings/abstract?id=2846 cough*
> 
>
>
> Yes, RPKI.  That's what I was waiting for.  Now we can get to
> a real discussion... ;-)
>
> scott



--
DougM at Work



--
DougM at Work

Re: "Defensive" BGP hijacking?

[Doug Montgomery]

Ah, the global system I was referring to was the RPKI as distributed
repository of routing information.  With consistent properties (data
formats, security models, data validation techniques, etc) across all 5
RIRs.

What an ISP does with the RPKI data, interns of route filtering, is always
a local policy decision.Somehow "global enforcement system" sounded
like a vision where ISPs don't have a choice of how and where to use the
system.  Maybe I read too much into the phrasing.

In the end, I think the issues boils down to if the community has the
desire and will to address the route hijack issue.If the answer is no,
then no further discussion is needed.  If the answer is yes, then it is
best to discuss and compare real proposals / mechanisms to address the
issue at scale.

I am still interested in some detail on the "tyranny implications".  We
can't address them until we know what they are and how they compare to any
other solution that tries to address the same problem.

dougm

On Wed, Sep 14, 2016 at 6:04 PM, Mel Beckman  wrote:

> Doug,
>
> I was basing my comments on your statement "If only there were a global
> system.."  However you slice or dice it, the tyranny implications have not
> yet been addressed. That certainly needs to be in front of any technical
> idea such as RPKI.
>
> Although I haven't participated in the OT&E, nothing I've read in RFC 6810
> talks about these issues. It talks about authentication and transport
> security, but doesn't talk about the potential for government interference.
>
>  -mel beckman
>
> On Sep 14, 2016, at 8:22 AM, Doug Montgomery  wrote:
>
> Mel,
>
> If you are speaking of RPKI based origin validation, I am not sure
> "automated / global enforcement system" is a useful description.   It does
> provide a consistent means for address holders to declare AS's authorized
> to announce prefixes, and a means for remote ASs to compare received
> updates vs such declarations.   What the receiving AS does with the
> validation information is strictly a local policy matter.
>
> Frankly, this is no more a "new automated enforcement system" than
> IRR-based route filtering has been for 20 years.  The only difference is
> that there is a consistent security model across all 5 RIRs as to who can
> make such declarations and it is tightly tied to the address allocation
> business process.
>
> I have seen a lot of FUD about the specter of interference, but not a lot
> of serious thought / discussion.  Having a serious technical discussion of
> potential risks and mitigations in the system would be useful.
>
> dougm
>
> On Wed, Sep 14, 2016 at 10:51 AM, Mel Beckman  wrote:
>
>> Scott and Doug,
>>
>> The problem with a new automated enforcement system is that it hobbles
>> both agility and innovation. ISPs have enjoyed simple BGP management,
>> entirely self-regulated, for decades. A global enforcement system, besides
>> being dang hard to do correctly, brings the specter of government
>> interference, since such a system could be overtaken by government entities
>> to manhandle free speech.
>>
>> In my opinion, the community hasn't spent nearly enough time discussing
>> the danger aspect. Being engineers, we focus on technical means, ignoring
>> the fact that we're designing our own guillotine.
>>
>>  -mel beckman
>>
>> > On Sep 14, 2016, at 12:10 AM, Scott Weeks 
>> wrote:
>> >
>> >
>> >
>> > --- dougm.w...@gmail.com wrote:
>> > From: Doug Montgomery 
>> >
>> > If only there were a global system, with consistent and verifiable
>> security
>> > properties, to permit address holders to declare the set of AS's
>> authorized
>> > to announce their prefixes, and routers anywhere on the Internet to
>> > independently verify the corresponding validity of received
>> announcements.
>> >
>> > *cough  https://www.nanog.org/meetings/abstract?id=2846 cough*
>> > 
>> >
>> >
>> > Yes, RPKI.  That's what I was waiting for.  Now we can get to
>> > a real discussion... ;-)
>> >
>> > scott
>>
>
>
>
> --
> DougM at Work
>
>


-- 
DougM at Work

Re: "Defensive" BGP hijacking?

[Doug Montgomery]

Mel,

If you are speaking of RPKI based origin validation, I am not sure
"automated / global enforcement system" is a useful description.   It does
provide a consistent means for address holders to declare AS's authorized
to announce prefixes, and a means for remote ASs to compare received
updates vs such declarations.   What the receiving AS does with the
validation information is strictly a local policy matter.

Frankly, this is no more a "new automated enforcement system" than
IRR-based route filtering has been for 20 years.  The only difference is
that there is a consistent security model across all 5 RIRs as to who can
make such declarations and it is tightly tied to the address allocation
business process.

I have seen a lot of FUD about the specter of interference, but not a lot
of serious thought / discussion.  Having a serious technical discussion of
potential risks and mitigations in the system would be useful.

dougm

On Wed, Sep 14, 2016 at 10:51 AM, Mel Beckman  wrote:

> Scott and Doug,
>
> The problem with a new automated enforcement system is that it hobbles
> both agility and innovation. ISPs have enjoyed simple BGP management,
> entirely self-regulated, for decades. A global enforcement system, besides
> being dang hard to do correctly, brings the specter of government
> interference, since such a system could be overtaken by government entities
> to manhandle free speech.
>
> In my opinion, the community hasn't spent nearly enough time discussing
> the danger aspect. Being engineers, we focus on technical means, ignoring
> the fact that we're designing our own guillotine.
>
>  -mel beckman
>
> > On Sep 14, 2016, at 12:10 AM, Scott Weeks 
> wrote:
> >
> >
> >
> > --- dougm.w...@gmail.com wrote:
> > From: Doug Montgomery 
> >
> > If only there were a global system, with consistent and verifiable
> security
> > properties, to permit address holders to declare the set of AS's
> authorized
> > to announce their prefixes, and routers anywhere on the Internet to
> > independently verify the corresponding validity of received
> announcements.
> >
> > *cough  https://www.nanog.org/meetings/abstract?id=2846 cough*
> > 
> >
> >
> > Yes, RPKI.  That's what I was waiting for.  Now we can get to
> > a real discussion... ;-)
> >
> > scott
>



-- 
DougM at Work

Re: "Defensive" BGP hijacking?

[Rich Kulawiec]

On Wed, Sep 14, 2016 at 04:04:43PM -0400, Bryan Fields wrote:
> I'm a bit ambivalent about BGP hijacking as a DDOS mitigation strategy.
> Really there is no authority to say it's wrong.  If your peers are cool with
> it, and their peers are cool with it who's to say it's wrong?

Meeting abuse with abuse never works out.  It's tempting (and even
trendy these days in portions of the security world which advocate
striking back at putative attackers, never mind that attack attribution
is almost entirely an unsolved problem in computing).  It's emotionally
satisfying.  It's sometimes momentarily effective.

But all it really does it open up still more attack vectors and accelerate
the spiral to the bottom.   Object lesson: Verizon's deployment of SAV
as an alleged anti-spam measure ~15 years ago.  It didn't take long for
attackers to figure out how to leverage it to their advantage, which of
course they did.

So don't do it.  It may take 5 minutes or 5 years, but it will eventually
become apparent that it's a really bad idea.  And when it does, you won't
be able to get those 5 minutes or 5 years back, nor will you be able to
undo the damage.

---rsk

Re: "Defensive" BGP hijacking?

[Mel Beckman]

Doug,

I was basing my comments on your statement "If only there were a global 
system.."  However you slice or dice it, the tyranny implications have not yet 
been addressed. That certainly needs to be in front of any technical idea such 
as RPKI.

Although I haven't participated in the OT&E, nothing I've read in RFC 6810 
talks about these issues. It talks about authentication and transport security, 
but doesn't talk about the potential for government interference.

 -mel beckman

On Sep 14, 2016, at 8:22 AM, Doug Montgomery 
mailto:dougm.w...@gmail.com>> wrote:

Mel,

If you are speaking of RPKI based origin validation, I am not sure "automated / 
global enforcement system" is a useful description.   It does provide a 
consistent means for address holders to declare AS's authorized to announce 
prefixes, and a means for remote ASs to compare received updates vs such 
declarations.   What the receiving AS does with the validation information is 
strictly a local policy matter.

Frankly, this is no more a "new automated enforcement system" than IRR-based 
route filtering has been for 20 years.  The only difference is that there is a 
consistent security model across all 5 RIRs as to who can make such 
declarations and it is tightly tied to the address allocation business process.

I have seen a lot of FUD about the specter of interference, but not a lot of 
serious thought / discussion.  Having a serious technical discussion of 
potential risks and mitigations in the system would be useful.

dougm

On Wed, Sep 14, 2016 at 10:51 AM, Mel Beckman 
mailto:m...@beckman.org>> wrote:
Scott and Doug,

The problem with a new automated enforcement system is that it hobbles both 
agility and innovation. ISPs have enjoyed simple BGP management, entirely 
self-regulated, for decades. A global enforcement system, besides being dang 
hard to do correctly, brings the specter of government interference, since such 
a system could be overtaken by government entities to manhandle free speech.

In my opinion, the community hasn't spent nearly enough time discussing the 
danger aspect. Being engineers, we focus on technical means, ignoring the fact 
that we're designing our own guillotine.

 -mel beckman

> On Sep 14, 2016, at 12:10 AM, Scott Weeks 
> mailto:sur...@mauigateway.com>> wrote:
>
>
>
> --- dougm.w...@gmail.com wrote:
> From: Doug Montgomery mailto:dougm.w...@gmail.com>>
>
> If only there were a global system, with consistent and verifiable security
> properties, to permit address holders to declare the set of AS's authorized
> to announce their prefixes, and routers anywhere on the Internet to
> independently verify the corresponding validity of received announcements.
>
> *cough  https://www.nanog.org/meetings/abstract?id=2846 cough*
> 
>
>
> Yes, RPKI.  That's what I was waiting for.  Now we can get to
> a real discussion... ;-)
>
> scott



--
DougM at Work

Re: "Defensive" BGP hijacking?

[Sandra Murphy]

> On Sep 13, 2016, at 8:08 PM, Ca By  wrote:
> 
> On Tuesday, September 13, 2016, Doug Montgomery 
> wrote:
> 
>> If only there were a global system, with consistent and verifiable security
>> properties, to permit address holders to declare the set of AS's authorized
>> to announce their prefixes, and routers anywhere on the Internet to
>> independently verify the corresponding validity of received announcements.
>> 
>> *cough  https://www.nanog.org/meetings/abstract?id=2846 cough*
>> 
>> I now return us to our discussion of network police, questionnaires for
>> network security, and the use of beer as a motivating force.
>> 
>> dougm
>> 
>> 
> Interesting that backconnect has invalid ROA issued
> 
> http://bgp.he.net/AS203959#_prefixes

Well, no, that’s not what the bgp.he.net (live long and prosper!) icons mean.

There is nothing invalid about the ROA.  And BackConnect did not issue it.

The red key means that AS203959 BackConnect Security LLC is announcing routes 
for 181.215.239.0/24, 191.96.128.0/24. etc that are invalid according to the 
RPKI.  Someone else with the right to use 181.215.239.0/24, 191.96.128.0/24. 
etc, created ROAs authorizing some other AS(s) to originate the route.

You can look at the ROAs for those prefixes with red keys in 
http://rpki-browser.realmv6.org (and with the RPKIviz and EOM tools from 
www.securerouting.net).  You can see that there are ROAs for 181.214.0.0/15 for 
AS50673, AS60458, AS61440.  and ROAs for 191.96.0.0/16 for AS61440, AS60458, 
AS29073, AS33182, AS37692.  and ROAs for 191.101.0.0/16 for AS60458, AS37692, 
AS61440.

Except.

It looks like, maybe, BackConnect was re-allocated the four prefixes with red 
keys, and whoever reallocated the prefixes to them created ROAs for their 
aggregate — but not for their customers.  See for example 
http://bgp.he.net/net/191.96.128.0/24 (and 
http://bgp.he.net/net/191.101.191.0/24)

This can occurred as the world backfills the existing allocations and the 
customers don’t keep up and their providers aren’t careful.  Some RPKI 
implementations will warn you that the ROA you are about to create will make 
existing routes appear invalid to the RPKI.

Just for fun, take a look at the IRR entries for the four prefixes with red key 
icons:

route:  191.96.128.0/24
descr:  Clan Servers
origin: AS20473
notify: net-supp...@ap.equinix.com
notify: n...@ap.equinix.com
mnt-by: MAINT-EQUINIXPAC
changed:mvillalo...@ap.equinix.com 20151229
source: NTTCOM

route:  191.96.129.0/24
descr:  Clan Servers
origin: AS20473
notify: net-supp...@ap.equinix.com
notify: n...@ap.equinix.com
mnt-by: MAINT-EQUINIXPAC
changed:mvillalo...@ap.equinix.com 20151229
source: NTTCOM

route:  191.101.191.0/24
descr:  Clan Servers
origin: AS20473
notify: net-supp...@ap.equinix.com
notify: ap-...@ap.equinix.com
mnt-by: MAINT-EQUINIXPAC
changed:mporq...@ap.equinix.com 20151227
source: NTTCOM

route:  181.215.239.0/24
descr:  Proxy route object registered by AS2764
origin: AS45177
remarks:This route object was created by AAPT on behalf of a customer.
remarks:As some of AAPTs upstream networks filter based on IRR objects,
remarks:this route object has been created to ensure that the advertisement
remarks:of this prefix is not rejected.
notify: routing.sha...@aapt.com.au
mnt-by: MAINT-AS2764
changed:nob...@aapt.com.au 20160106
source: RADB

(like the “nobody” part???)


At least the aggregate announcements aren’t proxies.

route:  181.214.0.0/19
descr:  Digital Energy Technologies LTD.
origin: AS61440
mnt-by: MAINT-AS61440
changed:modes...@host1plus.com 20140814  #13:04:53Z
source: RADB

route:  191.101.0.0/21
descr:  Digital Energy Technologies LTD.
origin: AS25761
mnt-by: MAINT-AS61440
changed:modes...@host1plus.com 20150610  #08:53:38Z
source: RADB

—Sandy

(Since bgp.he.net changes as the routing world changes, the red keys could be 
gone by the time anyone looks, of course.)



> 
> On Tue, Sep 13, 2016 at 2:51 PM, Mel Beckman >
>> wrote:
>> 
>>> Blake,
>>> 
>>> I concur that these are key questions. Probably _the_ key questions. The
>>> fabric of the Internet is today based on trust, and BGP's integrity is
>> the
>>> core of that trust.
>>> 
>>> I realize that BGP hijacking is not uncommon. However, this is the first
>>> time I've seen in it used defensively. I don't see a way to ever bless
>> this
>>> kind of defensive use without compromising that core trust. If Internet
>>> reachability depends on individual providers believing that they are
>>> justified in violating that trust when they are attacked, how can the
>>> Internet stand?
>>> 
>>> In addition to the question posed to Bryant about whether he would take
>>> this action again, I would like to add: what about the innocent parties
>>> impacted by your actions? Or do you take the position there were no
>>> i

Re: "Defensive" BGP hijacking?

[Scott Weeks]

--- br...@bryanfields.net wrote:
From: Bryan Fields 

I'm a bit ambivalent about BGP hijacking as a DDOS mitigation 
strategy.  Really there is no authority to say it's wrong.  If 
your peers are cool with it, and their peers are cool with it 
who's to say it's wrong?
---


Pretty much the entire BGP speaking world.

scott

Re: "Defensive" BGP hijacking?

[Scott Weeks]

--- jfmezei_na...@vaxination.ca wrote:
From: Jean-Francois Mezei 

I got to think about this (dangerous thing :-(

Ideally, law enforcement should have the smarts and tools 
to get involved in DDoS and other similar situations and 
have the power to compell upstream provider(s) to shut 
service to a suspect.
-


Yes, getting law enforcement involved in BGP and network
engineering in any way is a dangerous thing.  I agree 100%.

scott

Re: "Defensive" BGP hijacking?

[Christopher Morrow]

On Wed, Sep 14, 2016 at 4:04 PM, Bryan Fields  wrote:

> On 9/14/16 3:09 AM, Scott Weeks wrote:
> >
> > Yes, RPKI.  That's what I was waiting for.  Now we can get to
> > a real discussion
>
> Problem is, RPKI does not work for people with legacy blocks who will not
> sign
> a Legacy RSA.  ARIN doesn't own or have any say on how we use it, and we're
>

sure it does, move your registration to ripe.


(this was also given at nanog or ripe or something, I couldn't remember
which was the right one)



> sure as heck not going to sign a legally binding contract saying they do :)
>
>
don't have to... see preso.


> I'm a bit ambivalent about BGP hijacking as a DDOS mitigation strategy.
> Really there is no authority to say it's wrong.  If your peers are cool
> with
> it, and their peers are cool with it who's to say it's wrong?
>
> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>

Re: "Defensive" BGP hijacking?

[Bryan Fields]

On 9/14/16 3:09 AM, Scott Weeks wrote:
> 
> Yes, RPKI.  That's what I was waiting for.  Now we can get to
> a real discussion

Problem is, RPKI does not work for people with legacy blocks who will not sign
a Legacy RSA.  ARIN doesn't own or have any say on how we use it, and we're
sure as heck not going to sign a legally binding contract saying they do :)

I'm a bit ambivalent about BGP hijacking as a DDOS mitigation strategy.
Really there is no authority to say it's wrong.  If your peers are cool with
it, and their peers are cool with it who's to say it's wrong?

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: "Defensive" BGP hijacking?

[Jean-Francois Mezei]

I got to think about this (dangerous thing :-(

Ideally, law enforcement should have the smarts and tools to get
involved in DDoS and other similar situations and have the power to
compell upstream provider(s) to shut service to a suspect.

The current situation appears to be more of a wild-west situation where
everyone takes the law into their own hands. It sort of works but
everyone knows this lead lead to abuses.

If you start to tolerate falsifying BGP, it will likely lead to regular
abuses (including intelligence agencies who stad to gain by redirecting
traffic to their servers) as well as corporate spies etc. So mechanisms
to enforce 0 tolerance are perhaps necessary, even if this means that a
few legitimate BGP tricks to save customers from a failing ISP will no
longer work.



Falsifying BGP can be done by one person without any sanity checks.
There is no check for evidence or whether this action is warranted. On
the other hand, there is a sanity check if you have to convince an
upstream provider to cut access to one of their customers.

Re: "Defensive" BGP hijacking?

[Mel Beckman]

Scott and Doug,

The problem with a new automated enforcement system is that it hobbles both 
agility and innovation. ISPs have enjoyed simple BGP management, entirely 
self-regulated, for decades. A global enforcement system, besides being dang 
hard to do correctly, brings the specter of government interference, since such 
a system could be overtaken by government entities to manhandle free speech. 

In my opinion, the community hasn't spent nearly enough time discussing the 
danger aspect. Being engineers, we focus on technical means, ignoring the fact 
that we're designing our own guillotine. 

 -mel beckman

> On Sep 14, 2016, at 12:10 AM, Scott Weeks  wrote:
> 
> 
> 
> --- dougm.w...@gmail.com wrote:
> From: Doug Montgomery 
> 
> If only there were a global system, with consistent and verifiable security
> properties, to permit address holders to declare the set of AS's authorized
> to announce their prefixes, and routers anywhere on the Internet to
> independently verify the corresponding validity of received announcements.
> 
> *cough  https://www.nanog.org/meetings/abstract?id=2846 cough*
> 
> 
> 
> Yes, RPKI.  That's what I was waiting for.  Now we can get to
> a real discussion... ;-)
> 
> scott

Re: "Defensive" BGP hijacking?

[Scott Weeks]

--- dougm.w...@gmail.com wrote:
From: Doug Montgomery 

If only there were a global system, with consistent and verifiable security
properties, to permit address holders to declare the set of AS's authorized
to announce their prefixes, and routers anywhere on the Internet to
independently verify the corresponding validity of received announcements.

*cough  https://www.nanog.org/meetings/abstract?id=2846 cough*



Yes, RPKI.  That's what I was waiting for.  Now we can get to
a real discussion... ;-)

scott

Re: "Defensive" BGP hijacking?

[Hank Nussbacher]

On 13/09/2016 23:22, Blake Hudson wrote:
> Ca By wrote on 9/13/2016 2:53 PM:
>> On Tuesday, September 13, 2016, Bryant Townsend 
>> wrote:
>>
>> Tip to the RIR policy folks, you may want to make this point very
>> crisp. A
>> BGP ASN is the fundamental accountability control in a inter-domain
>> routing. Organizations with repeated offensense need to have their ASN
>> revoked, and further there should be controls in places so bad actors
>> cannot acquire "burner" ASNs.

The RIRs have made it very clear that they will not get involved.  Period.

-Hank

Re: "Defensive" BGP hijacking?

[Ca By]

On Tuesday, September 13, 2016, Doug Montgomery 
wrote:

> If only there were a global system, with consistent and verifiable security
> properties, to permit address holders to declare the set of AS's authorized
> to announce their prefixes, and routers anywhere on the Internet to
> independently verify the corresponding validity of received announcements.
>
> *cough  https://www.nanog.org/meetings/abstract?id=2846 cough*
>
> I now return us to our discussion of network police, questionnaires for
> network security, and the use of beer as a motivating force.
>
> dougm
>
>
Interesting that backconnect has invalid ROA issued

http://bgp.he.net/AS203959#_prefixes

On Tue, Sep 13, 2016 at 2:51 PM, Mel Beckman >
> wrote:
>
> > Blake,
> >
> > I concur that these are key questions. Probably _the_ key questions. The
> > fabric of the Internet is today based on trust, and BGP's integrity is
> the
> > core of that trust.
> >
> > I realize that BGP hijacking is not uncommon. However, this is the first
> > time I've seen in it used defensively. I don't see a way to ever bless
> this
> > kind of defensive use without compromising that core trust. If Internet
> > reachability depends on individual providers believing that they are
> > justified in violating that trust when they are attacked, how can the
> > Internet stand?
> >
> > In addition to the question posed to Bryant about whether he would take
> > this action again, I would like to add: what about the innocent parties
> > impacted by your actions? Or do you take the position there were no
> > innocent parties in the hijacked prefixes?
> >
> > -mel via cell
> >
> > > On Sep 13, 2016, at 11:40 AM, Blake Hudson  > wrote:
> > >
> > >
> > >
> > > Bryant Townsend wrote on 9/13/2016 2:22 AM:
> > >> This was the point where I decided
> > >> I needed to go on the offensive to protect myself, my partner,
> visiting
> > >> family, and my employees. The actions proved to be extremely
> effective,
> > as
> > >> all forms of harassment and threats from the attackers immediately
> > stopped.
> > >
> > >
> > > Bryant, what actions, exactly, did you take? This topic seems
> > intentionally glossed over while you spend a much larger amount of time
> > explaining the back story and your motivations rather than your actions.
> > >
> > > Questions I was left with:
> > >
> > > 1. What prefixes have you announced without permission (not just this
> > >   event)?
> > > 2. How did you identify these prefixes?
> > > 3. Did you attempt to contact the owner of these prefixes?
> > > 4. Did you attempt to contact the origin or transit AS of these
> prefixes?
> > > 5. What was the process to get your upstream AS to accept these prefix
> > >   announcements?
> > > 6. Was your upstream AS complicit in allowing you to announce prefixes
> > >   you did not have authorization to announce?
> > >
> >
>
>
>
> --
> DougM at Work
>

Re: "Defensive" BGP hijacking?

[Doug Montgomery]

If only there were a global system, with consistent and verifiable security
properties, to permit address holders to declare the set of AS's authorized
to announce their prefixes, and routers anywhere on the Internet to
independently verify the corresponding validity of received announcements.

*cough  https://www.nanog.org/meetings/abstract?id=2846 cough*

I now return us to our discussion of network police, questionnaires for
network security, and the use of beer as a motivating force.

dougm

On Tue, Sep 13, 2016 at 2:51 PM, Mel Beckman  wrote:

> Blake,
>
> I concur that these are key questions. Probably _the_ key questions. The
> fabric of the Internet is today based on trust, and BGP's integrity is the
> core of that trust.
>
> I realize that BGP hijacking is not uncommon. However, this is the first
> time I've seen in it used defensively. I don't see a way to ever bless this
> kind of defensive use without compromising that core trust. If Internet
> reachability depends on individual providers believing that they are
> justified in violating that trust when they are attacked, how can the
> Internet stand?
>
> In addition to the question posed to Bryant about whether he would take
> this action again, I would like to add: what about the innocent parties
> impacted by your actions? Or do you take the position there were no
> innocent parties in the hijacked prefixes?
>
> -mel via cell
>
> > On Sep 13, 2016, at 11:40 AM, Blake Hudson  wrote:
> >
> >
> >
> > Bryant Townsend wrote on 9/13/2016 2:22 AM:
> >> This was the point where I decided
> >> I needed to go on the offensive to protect myself, my partner, visiting
> >> family, and my employees. The actions proved to be extremely effective,
> as
> >> all forms of harassment and threats from the attackers immediately
> stopped.
> >
> >
> > Bryant, what actions, exactly, did you take? This topic seems
> intentionally glossed over while you spend a much larger amount of time
> explaining the back story and your motivations rather than your actions.
> >
> > Questions I was left with:
> >
> > 1. What prefixes have you announced without permission (not just this
> >   event)?
> > 2. How did you identify these prefixes?
> > 3. Did you attempt to contact the owner of these prefixes?
> > 4. Did you attempt to contact the origin or transit AS of these prefixes?
> > 5. What was the process to get your upstream AS to accept these prefix
> >   announcements?
> > 6. Was your upstream AS complicit in allowing you to announce prefixes
> >   you did not have authorization to announce?
> >
>



-- 
DougM at Work

Re: "Defensive" BGP hijacking?

[Bryant Townsend]

@Blake - I think you misinterpreted my remarks of how this experience will
shape the future company policy. I meant to portray that the company will
not use these tactics again and that any future threats will be handled
differently.

Re: "Defensive" BGP hijacking?

[Scott Weeks]

--- h...@slabnet.com wrote:
On Tue 2016-Sep-13 13:32:56 -0700, Scott Weeks  wrote:
>--- bry...@backconnect.com wrote:
>From: Bryant Townsend 


>@ca & Matt - No, we do not plan to ever intentionally perform a
>non-authorized BGP hijack in the future.
>

>
>Who was the upstream provider?

3223 / VOXILITY
https://bgpstream.com/event/54711
---



Oops, I just realized that was mentioned earlier.  Apologies
for the noise.

scott

Re: "Defensive" BGP hijacking?

[Hugo Slabbert]

On Tue 2016-Sep-13 13:32:56 -0700, Scott Weeks  wrote:




--- bry...@backconnect.com wrote:
From: Bryant Townsend 

@ca & Matt - No, we do not plan to ever intentionally perform a
non-authorized BGP hijack in the future.



Bryant,

Who was the upstream provider?


3223 / VOXILITY
https://bgpstream.com/event/54711


scott


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature

Re: "Defensive" BGP hijacking?

[Scott Weeks]

--- bry...@backconnect.com wrote:
From: Bryant Townsend 

@ca & Matt - No, we do not plan to ever intentionally perform a
non-authorized BGP hijack in the future.



Bryant,

Who was the upstream provider?

scott

Re: "Defensive" BGP hijacking?

[Blake Hudson]

Ca By wrote on 9/13/2016 2:53 PM:

On Tuesday, September 13, 2016, Bryant Townsend 
wrote:


@ca & Matt - No, we do not plan to ever intentionally perform a
non-authorized BGP hijack in the future.

Great answer.  Thanks.

Committing to pursuing a policy of weaponizing BGP would have triggered a
serious "terms of service" violations that would have effectively ended
your business swiftly and permanently.

Tip to the RIR policy folks, you may want to make this point very crisp. A
BGP ASN is the fundamental accountability control in a inter-domain
routing. Organizations with repeated offensense need to have their ASN
revoked, and further there should be controls in places so bad actors
cannot acquire "burner" ASNs.


@Steve - Correct, the attack had already been mitigated. The decision to
hijack the attackers IP space was to deal with their threats, which if
carried through could have potentially lead to physical harm. Although the
hijack gave us a unique insight into the attackers services, it was not a
factor that influenced my decision.

@Blake & Mel - We will likely cover some of these questions in a future
blog post.



Ca, and the community, I don't make the leap. How does attacking someone 
by hijacking their IP space mitigate a physical threat? How does 
impeding someone's access to the internet access prevent them from 
performing an act of physical violence against you? If a party threatens 
me, would I be justified in attacking him or her? In my experience, 
attacking someone is more likely to escalate a situation - not 
deescalate it.


Bryant did weaponize BGP and stated he stands by his actions and further 
indicated that he will use what he learned here to shape handling of 
future situations:

I have spent a
long time reflecting on my decision and how it may negatively impact the
company and myself in some people’s eyes, but ultimately I stand by it. The
experience and feedback I have gained from these events has proven
invaluable and will be used to shape the policies surrounding the future
handling of similar situations.


When I read Bryant's comments, I see justification and excuses for his 
behavior. I do not see an apology nor admission of wrongdoing. I believe 
what Bryant did was wrong and I would hate for others to be allowed to 
act similarly without consequence.

Re: "Defensive" BGP hijacking?

[Ca By]

On Tuesday, September 13, 2016, Bryant Townsend 
wrote:

> @ca & Matt - No, we do not plan to ever intentionally perform a
> non-authorized BGP hijack in the future.
>
>
Great answer.  Thanks.

Committing to pursuing a policy of weaponizing BGP would have triggered a
serious "terms of service" violations that would have effectively ended
your business swiftly and permanently.

Tip to the RIR policy folks, you may want to make this point very crisp. A
BGP ASN is the fundamental accountability control in a inter-domain
routing. Organizations with repeated offensense need to have their ASN
revoked, and further there should be controls in places so bad actors
cannot acquire "burner" ASNs.


@Steve - Correct, the attack had already been mitigated. The decision to
> hijack the attackers IP space was to deal with their threats, which if
> carried through could have potentially lead to physical harm. Although the
> hijack gave us a unique insight into the attackers services, it was not a
> factor that influenced my decision.
>
> @Blake & Mel - We will likely cover some of these questions in a future
> blog post.
>

Re: "Defensive" BGP hijacking?

[Bryant Townsend]

@ca & Matt - No, we do not plan to ever intentionally perform a
non-authorized BGP hijack in the future.

@Steve - Correct, the attack had already been mitigated. The decision to
hijack the attackers IP space was to deal with their threats, which if
carried through could have potentially lead to physical harm. Although the
hijack gave us a unique insight into the attackers services, it was not a
factor that influenced my decision.

@Blake & Mel - We will likely cover some of these questions in a future
blog post.

Re: "Defensive" BGP hijacking?

[Hunter Fuller]

On Tue, Sep 13, 2016 at 10:25 AM Bryant Townsend 
wrote:

> I also wanted to let Hugo (who started the thread) know
> that we harbor no hard feelings about bringing this topic up, as it is
> relevant to the community and does warrant discussion. Hugo, you may owe me
> a beer the next time we meet. :)
>

Wait, so if I hijack someone else's prefix, someone ends up buying me a
beer?

Let me fire up my terminal...

Re: "Defensive" BGP hijacking?

[Mel Beckman]

Blake,

I concur that these are key questions. Probably _the_ key questions. The fabric 
of the Internet is today based on trust, and BGP's integrity is the core of 
that trust. 

I realize that BGP hijacking is not uncommon. However, this is the first time 
I've seen in it used defensively. I don't see a way to ever bless this kind of 
defensive use without compromising that core trust. If Internet reachability 
depends on individual providers believing that they are justified in violating 
that trust when they are attacked, how can the Internet stand?

In addition to the question posed to Bryant about whether he would take this 
action again, I would like to add: what about the innocent parties impacted by 
your actions? Or do you take the position there were no innocent parties in the 
hijacked prefixes?

-mel via cell

> On Sep 13, 2016, at 11:40 AM, Blake Hudson  wrote:
> 
> 
> 
> Bryant Townsend wrote on 9/13/2016 2:22 AM:
>> This was the point where I decided
>> I needed to go on the offensive to protect myself, my partner, visiting
>> family, and my employees. The actions proved to be extremely effective, as
>> all forms of harassment and threats from the attackers immediately stopped.
> 
> 
> Bryant, what actions, exactly, did you take? This topic seems intentionally 
> glossed over while you spend a much larger amount of time explaining the back 
> story and your motivations rather than your actions.
> 
> Questions I was left with:
> 
> 1. What prefixes have you announced without permission (not just this
>   event)?
> 2. How did you identify these prefixes?
> 3. Did you attempt to contact the owner of these prefixes?
> 4. Did you attempt to contact the origin or transit AS of these prefixes?
> 5. What was the process to get your upstream AS to accept these prefix
>   announcements?
> 6. Was your upstream AS complicit in allowing you to announce prefixes
>   you did not have authorization to announce?
> 

Re: "Defensive" BGP hijacking?

[Steve Atkins]

> On Sep 13, 2016, at 12:22 AM, Bryant Townsend  wrote:
> 
> *Events that caused us to perform the BGP hijack*: After the DDoS attacks
> subsided, the attackers started to harass us by calling in using spoofed
> phone numbers. Curious to what this was all about, we fielded various calls
> which allowed us to ascertain who was behind the attacks by correlating
> e-mails with the information they provided over the phone. Throughout the
> day and late into the night, these calls and threats continued to increase
> in number. Throughout these calls we noticed an increasing trend of them
> bringing up personal information of myself and employees. At this point I
> personally filled a police report in preparation to a possible SWATing
> attempt.  As they continued to harass our company, more and more red flags
> indicated that I would soon be targeted. This was the point where I decided
> I needed to go on the offensive to protect myself, my partner, visiting
> family, and my employees. 

I think you're saying that the BGP hijack wasn't done in as part of an attempt 
to
mitigate a DDoS, rather that you used the tools you had available
to go on the offensive in response to phone calls you received. Am I reading
that right?

Cheers,
  Steve

Re: "Defensive" BGP hijacking?

[Blake Hudson]

Bryant Townsend wrote on 9/13/2016 2:22 AM:

This was the point where I decided
I needed to go on the offensive to protect myself, my partner, visiting
family, and my employees. The actions proved to be extremely effective, as
all forms of harassment and threats from the attackers immediately stopped.



Bryant, what actions, exactly, did you take? This topic seems 
intentionally glossed over while you spend a much larger amount of time 
explaining the back story and your motivations rather than your actions.


Questions I was left with:

1. What prefixes have you announced without permission (not just this
   event)?
2. How did you identify these prefixes?
3. Did you attempt to contact the owner of these prefixes?
4. Did you attempt to contact the origin or transit AS of these prefixes?
5. What was the process to get your upstream AS to accept these prefix
   announcements?
6. Was your upstream AS complicit in allowing you to announce prefixes
   you did not have authorization to announce?

Re: "Defensive" BGP hijacking?

[Ryan, Spencer]

What would you have done if the personal harassment didn't stop? What would you 
have done if they simply switched to a new source range/different set of bots?


Seems like a very slippery slope to me.


Spencer Ryan | Senior Systems Administrator | 
sr...@arbor.net<mailto:sr...@arbor.net>
Arbor Networks
+1.734.794.5033 (d) | +1.734.846.2053 (m)
www.arbornetworks.com<http://www.arbornetworks.com/>



From: NANOG  on behalf of Bryant Townsend 

Sent: Tuesday, September 13, 2016 3:22:43 AM
To: nanog@nanog.org
Subject: Re: "Defensive" BGP hijacking?

Hello Everyone,


I would like to give as much insight as I can in regards to the BGP hijack
being discussed in this thread. I won’t be going into specific details of
the attack, but we do plan to release more information on our website when
we are able to. I also wanted to let Hugo (who started the thread) know
that we harbor no hard feelings about bringing this topic up, as it is
relevant to the community and does warrant discussion. Hugo, you may owe me
a beer the next time we meet. :)



We agree with others that NANOG is the most appropriate venue to answer any
questions and discuss the topic at hand. I have been attending NANOG for
the past 3-4 years, and I can assure you that it is of the utmost
importance to me how the community views my company, my employees, and
myself. There are many people in this community that I personally have the
upmost respect for, and it would sadden me If I were to lose the respect of
mentors, colleagues, and friends by not responding. That being said, I
think there are a fair number of people in NANOG that would vouch for my
character and ethics relating to the intent of my actions, even if I were
to remain silent.  I would also like to preface that my explanation of the
events that occurred and actions taken by BackConnect are not to justify or
provide excuses. My goal is to simply show what happened and give insight
into our actions.



I will start with a little background to bring anyone up to speed that is
not aware of the events that transpired.


*About the company, BackConnect, Inc.*: We are a new (~4 months old)
open-sourced based DDoS mitigation and network security provider that
specializes in custom intrusion detection and prevention systems. We also
provide threat intelligence services, with an emphasis on active botnets,
new and upcoming DDoS attack patterns, and boot services. From time to
time, this information flows through our network for collection purposes.


*Events leading to the Hijack*: On 9/6/2016, ~10:30AM PST, one of our
clients and our website received a large and relatively sophisticated DDoS
attack. The attack targeted entire subnets and peaked over 200 Gbps and
40Mpps. Although the attack was automatically detected and mostly filtered,
there was initially a small leak. In response we quickly applied new
security rules that rendered it entirely ineffective. The attackers
continued to attack our network and client for roughly 6 hours before
giving up.


*Events that caused us to perform the BGP hijack*: After the DDoS attacks
subsided, the attackers started to harass us by calling in using spoofed
phone numbers. Curious to what this was all about, we fielded various calls
which allowed us to ascertain who was behind the attacks by correlating
e-mails with the information they provided over the phone. Throughout the
day and late into the night, these calls and threats continued to increase
in number. Throughout these calls we noticed an increasing trend of them
bringing up personal information of myself and employees. At this point I
personally filled a police report in preparation to a possible SWATing
attempt.  As they continued to harass our company, more and more red flags
indicated that I would soon be targeted. This was the point where I decided
I needed to go on the offensive to protect myself, my partner, visiting
family, and my employees. The actions proved to be extremely effective, as
all forms of harassment and threats from the attackers immediately stopped.
In addition to our main objective, we were able to collect intelligence on
the actors behind the bot net as well as identify the attack servers used
by the booter service.



*Afterthoughts*: The decision to hijack the attackers IP space was not
something I took lightly. I was fully aware there were services that
reported such actions and knew that this could potentially be brought up in
discussion and hurt BackConnect’s image. Even though we had the capacity to
hide our actions, we felt that it would be wrong to do so. I have spent a
long time reflecting on my decision and how it may negatively impact the
company and myself in some people’s eyes, but ultimately I stand by it. The
experience and feedback I have gained from these events has proven
invaluable and will be used to shape the policies surrounding the future
handling of similar situations. I am happy to field qu

Re: "Defensive" BGP hijacking?

[Matt Freitag]

+1 to this question.

Bryant, thanks for giving us your side of this story.

Matt Freitag
Network Engineer I
Information Technology
Michigan Technological University
(906) 487-3696 <%28906%29%20487-3696>
https://www.mtu.edu/
https://www.it.mtu.edu/

On Tue, Sep 13, 2016 at 12:22 PM, Ca By  wrote:

> On Tuesday, September 13, 2016, Bryant Townsend 
> wrote:
>
> > Hello Everyone,
> >
> >
> > I would like to give as much insight as I can in regards to the BGP
> hijack
> > being discussed in this thread. I won’t be going into specific details of
> > the attack, but we do plan to release more information on our website
> when
> > we are able to. I also wanted to let Hugo (who started the thread) know
> > that we harbor no hard feelings about bringing this topic up, as it is
> > relevant to the community and does warrant discussion. Hugo, you may owe
> me
> > a beer the next time we meet. :)
> >
> >
> >
> > We agree with others that NANOG is the most appropriate venue to answer
> any
> > questions and discuss the topic at hand. I have been attending NANOG for
> > the past 3-4 years, and I can assure you that it is of the utmost
> > importance to me how the community views my company, my employees, and
> > myself. There are many people in this community that I personally have
> the
> > upmost respect for, and it would sadden me If I were to lose the respect
> of
> > mentors, colleagues, and friends by not responding. That being said, I
> > think there are a fair number of people in NANOG that would vouch for my
> > character and ethics relating to the intent of my actions, even if I were
> > to remain silent.  I would also like to preface that my explanation of
> the
> > events that occurred and actions taken by BackConnect are not to justify
> or
> > provide excuses. My goal is to simply show what happened and give insight
> > into our actions.
> >
> >
> >
> > I will start with a little background to bring anyone up to speed that is
> > not aware of the events that transpired.
> >
> >
> > *About the company, BackConnect, Inc.*: We are a new (~4 months old)
> > open-sourced based DDoS mitigation and network security provider that
> > specializes in custom intrusion detection and prevention systems. We also
> > provide threat intelligence services, with an emphasis on active botnets,
> > new and upcoming DDoS attack patterns, and boot services. From time to
> > time, this information flows through our network for collection purposes.
> >
> >
> > *Events leading to the Hijack*: On 9/6/2016, ~10:30AM PST, one of our
> > clients and our website received a large and relatively sophisticated
> DDoS
> > attack. The attack targeted entire subnets and peaked over 200 Gbps and
> > 40Mpps. Although the attack was automatically detected and mostly
> filtered,
> > there was initially a small leak. In response we quickly applied new
> > security rules that rendered it entirely ineffective. The attackers
> > continued to attack our network and client for roughly 6 hours before
> > giving up.
> >
> >
> > *Events that caused us to perform the BGP hijack*: After the DDoS attacks
> > subsided, the attackers started to harass us by calling in using spoofed
> > phone numbers. Curious to what this was all about, we fielded various
> calls
> > which allowed us to ascertain who was behind the attacks by correlating
> > e-mails with the information they provided over the phone. Throughout the
> > day and late into the night, these calls and threats continued to
> increase
> > in number. Throughout these calls we noticed an increasing trend of them
> > bringing up personal information of myself and employees. At this point I
> > personally filled a police report in preparation to a possible SWATing
> > attempt.  As they continued to harass our company, more and more red
> flags
> > indicated that I would soon be targeted. This was the point where I
> decided
> > I needed to go on the offensive to protect myself, my partner, visiting
> > family, and my employees. The actions proved to be extremely effective,
> as
> > all forms of harassment and threats from the attackers immediately
> stopped.
> > In addition to our main objective, we were able to collect intelligence
> on
> > the actors behind the bot net as well as identify the attack servers used
> > by the booter service.
> >
> >
> >
> > *Afterthoughts*: The decision to hijack the attackers IP space was not
> > something I took lightly. I was fully aware there were services that
> > reported such actions and knew that this could potentially be brought up
> in
> > discussion and hurt BackConnect’s image. Even though we had the capacity
> to
> > hide our actions, we felt that it would be wrong to do so. I have spent a
> > long time reflecting on my decision and how it may negatively impact the
> > company and myself in some people’s eyes, but ultimately I stand by it.
> The
> > experience and feedback I have gained from these events has proven
> > invaluable and will be used to shape the

Re: "Defensive" BGP hijacking?

[Ca By]

On Tuesday, September 13, 2016, Bryant Townsend 
wrote:

> Hello Everyone,
>
>
> I would like to give as much insight as I can in regards to the BGP hijack
> being discussed in this thread. I won’t be going into specific details of
> the attack, but we do plan to release more information on our website when
> we are able to. I also wanted to let Hugo (who started the thread) know
> that we harbor no hard feelings about bringing this topic up, as it is
> relevant to the community and does warrant discussion. Hugo, you may owe me
> a beer the next time we meet. :)
>
>
>
> We agree with others that NANOG is the most appropriate venue to answer any
> questions and discuss the topic at hand. I have been attending NANOG for
> the past 3-4 years, and I can assure you that it is of the utmost
> importance to me how the community views my company, my employees, and
> myself. There are many people in this community that I personally have the
> upmost respect for, and it would sadden me If I were to lose the respect of
> mentors, colleagues, and friends by not responding. That being said, I
> think there are a fair number of people in NANOG that would vouch for my
> character and ethics relating to the intent of my actions, even if I were
> to remain silent.  I would also like to preface that my explanation of the
> events that occurred and actions taken by BackConnect are not to justify or
> provide excuses. My goal is to simply show what happened and give insight
> into our actions.
>
>
>
> I will start with a little background to bring anyone up to speed that is
> not aware of the events that transpired.
>
>
> *About the company, BackConnect, Inc.*: We are a new (~4 months old)
> open-sourced based DDoS mitigation and network security provider that
> specializes in custom intrusion detection and prevention systems. We also
> provide threat intelligence services, with an emphasis on active botnets,
> new and upcoming DDoS attack patterns, and boot services. From time to
> time, this information flows through our network for collection purposes.
>
>
> *Events leading to the Hijack*: On 9/6/2016, ~10:30AM PST, one of our
> clients and our website received a large and relatively sophisticated DDoS
> attack. The attack targeted entire subnets and peaked over 200 Gbps and
> 40Mpps. Although the attack was automatically detected and mostly filtered,
> there was initially a small leak. In response we quickly applied new
> security rules that rendered it entirely ineffective. The attackers
> continued to attack our network and client for roughly 6 hours before
> giving up.
>
>
> *Events that caused us to perform the BGP hijack*: After the DDoS attacks
> subsided, the attackers started to harass us by calling in using spoofed
> phone numbers. Curious to what this was all about, we fielded various calls
> which allowed us to ascertain who was behind the attacks by correlating
> e-mails with the information they provided over the phone. Throughout the
> day and late into the night, these calls and threats continued to increase
> in number. Throughout these calls we noticed an increasing trend of them
> bringing up personal information of myself and employees. At this point I
> personally filled a police report in preparation to a possible SWATing
> attempt.  As they continued to harass our company, more and more red flags
> indicated that I would soon be targeted. This was the point where I decided
> I needed to go on the offensive to protect myself, my partner, visiting
> family, and my employees. The actions proved to be extremely effective, as
> all forms of harassment and threats from the attackers immediately stopped.
> In addition to our main objective, we were able to collect intelligence on
> the actors behind the bot net as well as identify the attack servers used
> by the booter service.
>
>
>
> *Afterthoughts*: The decision to hijack the attackers IP space was not
> something I took lightly. I was fully aware there were services that
> reported such actions and knew that this could potentially be brought up in
> discussion and hurt BackConnect’s image. Even though we had the capacity to
> hide our actions, we felt that it would be wrong to do so. I have spent a
> long time reflecting on my decision and how it may negatively impact the
> company and myself in some people’s eyes, but ultimately I stand by it. The
> experience and feedback I have gained from these events has proven
> invaluable and will be used to shape the policies surrounding the future
> handling of similar situations. I am happy to field questions, but cannot
> promise any answers, disclosure of further information, or when they will
> be responded to.
>
>
> Sincerely,
>
> Bryant Townsend
>


Will you do the bgp hijacking in the future: yes or no?

Thanks!

Re: "Defensive" BGP hijacking?

[Bryant Townsend]

Hello Everyone,


I would like to give as much insight as I can in regards to the BGP hijack
being discussed in this thread. I won’t be going into specific details of
the attack, but we do plan to release more information on our website when
we are able to. I also wanted to let Hugo (who started the thread) know
that we harbor no hard feelings about bringing this topic up, as it is
relevant to the community and does warrant discussion. Hugo, you may owe me
a beer the next time we meet. :)



We agree with others that NANOG is the most appropriate venue to answer any
questions and discuss the topic at hand. I have been attending NANOG for
the past 3-4 years, and I can assure you that it is of the utmost
importance to me how the community views my company, my employees, and
myself. There are many people in this community that I personally have the
upmost respect for, and it would sadden me If I were to lose the respect of
mentors, colleagues, and friends by not responding. That being said, I
think there are a fair number of people in NANOG that would vouch for my
character and ethics relating to the intent of my actions, even if I were
to remain silent.  I would also like to preface that my explanation of the
events that occurred and actions taken by BackConnect are not to justify or
provide excuses. My goal is to simply show what happened and give insight
into our actions.



I will start with a little background to bring anyone up to speed that is
not aware of the events that transpired.


*About the company, BackConnect, Inc.*: We are a new (~4 months old)
open-sourced based DDoS mitigation and network security provider that
specializes in custom intrusion detection and prevention systems. We also
provide threat intelligence services, with an emphasis on active botnets,
new and upcoming DDoS attack patterns, and boot services. From time to
time, this information flows through our network for collection purposes.


*Events leading to the Hijack*: On 9/6/2016, ~10:30AM PST, one of our
clients and our website received a large and relatively sophisticated DDoS
attack. The attack targeted entire subnets and peaked over 200 Gbps and
40Mpps. Although the attack was automatically detected and mostly filtered,
there was initially a small leak. In response we quickly applied new
security rules that rendered it entirely ineffective. The attackers
continued to attack our network and client for roughly 6 hours before
giving up.


*Events that caused us to perform the BGP hijack*: After the DDoS attacks
subsided, the attackers started to harass us by calling in using spoofed
phone numbers. Curious to what this was all about, we fielded various calls
which allowed us to ascertain who was behind the attacks by correlating
e-mails with the information they provided over the phone. Throughout the
day and late into the night, these calls and threats continued to increase
in number. Throughout these calls we noticed an increasing trend of them
bringing up personal information of myself and employees. At this point I
personally filled a police report in preparation to a possible SWATing
attempt.  As they continued to harass our company, more and more red flags
indicated that I would soon be targeted. This was the point where I decided
I needed to go on the offensive to protect myself, my partner, visiting
family, and my employees. The actions proved to be extremely effective, as
all forms of harassment and threats from the attackers immediately stopped.
In addition to our main objective, we were able to collect intelligence on
the actors behind the bot net as well as identify the attack servers used
by the booter service.



*Afterthoughts*: The decision to hijack the attackers IP space was not
something I took lightly. I was fully aware there were services that
reported such actions and knew that this could potentially be brought up in
discussion and hurt BackConnect’s image. Even though we had the capacity to
hide our actions, we felt that it would be wrong to do so. I have spent a
long time reflecting on my decision and how it may negatively impact the
company and myself in some people’s eyes, but ultimately I stand by it. The
experience and feedback I have gained from these events has proven
invaluable and will be used to shape the policies surrounding the future
handling of similar situations. I am happy to field questions, but cannot
promise any answers, disclosure of further information, or when they will
be responded to.


Sincerely,

Bryant Townsend

Re: "Defensive" BGP hijacking?

[jim deleskie]

Redirecting someone's traffic, with out there permission or a court order,
by a court in your jurisdiction, not a lot different then the "bad guys"
themselves.




On Sun, Sep 11, 2016 at 5:54 PM, Hugo Slabbert  wrote:

> Hopefully this is operational enough, though obviously leaning more
> towards the policy side of things:
>
> What does nanog think about a DDoS scrubber hijacking a network "for
> defensive purposes"?
>
> http://krebsonsecurity.com/2016/09/alleged-vdos-proprietors-arrested-in-
> israel/
>
> "For about six hours, we were seeing attacks of more than 200 Gbps hitting
> us,” Townsend explained. “What we were doing was for defensive purposes. We
> were simply trying to get them to stop and to gather as much information as
> possible about the botnet they were using and report that to the proper
> authorities.”
>
> --
> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> pgp key: B178313E   | also on Signal

Re: "Defensive" BGP hijacking?

[Scott Weeks]

--- m...@beckman.org wrote:
From: Mel Beckman 

This looks to me like ISP community governance in the 
best sense. I look forward to thoughtful discussion.



Yes, 100% agree!

scott

Re: "Defensive" BGP hijacking?

[Mel Beckman]

Bryant from BackConnect (bry...@backconnect.com) 
has replied to me directly. He is a Nanog repeat attendee, but hasn't been 
subscribed to this list. Bryant says he is subscribing now and will post some 
clarifying comments shortly. I would share the content of his email, but he 
didn't explicitly give me permission for that, so I'll let him repeat anything 
that needs repeating.

This looks to me like ISP community governance in the best sense. I look 
forward to thoughtful discussion.

 -mel beckman

On Sep 12, 2016, at 2:03 PM, Paras Jha 
mailto:pa...@protrafsolutions.com>> wrote:

Well don't forget, normal attacks launched from vDOS were around 8 -
16gbps.

On the Krebs article, he mentions "the company received an email directly
from vDOS claiming credit for the attack"

Now, if this holds true, it's likely that the operator of vDOS (Apple J4ck
was his moniker) was directing the full resources of the network towards
BackConnect. Given that Brian indicated that at any given time vDOS could
be launching 10 - 15 times (9 "DDoS years" or something in a few months),
the full force of the vDOS network could easily amount to 200gbps.

This behavior is never defensible nor acceptable.

In addition to being in the wrong with BGP hijacking a prefix, it
appears that Mr. Townsend had the wrong target, too. We've been
attacked a few dozen times by this botnet, and they could never muster
anything near 200 gbps worth of traffic. They were orders of magnitude
smaller, only around 8-16 gbps depending on attack.

Mr. Townsend's motives were wrong and so was his information.

Re: "Defensive" BGP hijacking?

[Paras Jha]

Well don't forget, normal attacks launched from vDOS were around 8 -
16gbps.

On the Krebs article, he mentions "the company received an email directly
from vDOS claiming credit for the attack"

Now, if this holds true, it's likely that the operator of vDOS (Apple J4ck
was his moniker) was directing the full resources of the network towards
BackConnect. Given that Brian indicated that at any given time vDOS could
be launching 10 - 15 times (9 "DDoS years" or something in a few months),
the full force of the vDOS network could easily amount to 200gbps.

> This behavior is never defensible nor acceptable.
>
> In addition to being in the wrong with BGP hijacking a prefix, it
> appears that Mr. Townsend had the wrong target, too. We've been
> attacked a few dozen times by this botnet, and they could never muster
> anything near 200 gbps worth of traffic. They were orders of magnitude
> smaller, only around 8-16 gbps depending on attack.
>
> Mr. Townsend's motives were wrong and so was his information.

Re: "Defensive" BGP hijacking?

[Jean-Francois Mezei]

On 2016-09-12 14:15, valdis.kletni...@vt.edu wrote:

> I don't see "hijacking" in your description of the iStop case - it appears
> to have been fully coordinated and with permission.


While I am not sure about fully coordinated and with permission, it is
an example where it was a desirable outcome to maintain service to
customers who would otherwise have have been left without service.

I pointed this as an example where "highjacking" can sometimes be
desirable. An automated system would likekely block such announcements
from ISP3 about ISP1's IP blocks pointing to ISP2's routers as it could
be seen as highly suspect.

Then again, with many mergers and acquisitions, this type or arrangement
may be common as acquiring ISP1 may start to make BGP announcements of
ISP2's IPs before those IPs have had time to be transfered.

Re: "Defensive" BGP hijacking?

[Jean-Francois Mezei]

On 2016-09-12 14:14, Hugo Slabbert wrote:

> Was this all done at iStop's request and with their full support?

When iStop's router stopped making BGP announcements to the world
(because its last transit link was cut), and ISP3 highjacked the IP
blocks and made BGP announcements pointing to ISP2, I don't think there
was much of iStop left to complain, and it was to the benefit of end
users, so this highjacking was not nefarious.

Either ISP2 was asleep at the switch and let this happen, or perhaps
they had a deal ith iStop that they would not do BGP until block of IPs
was transfered, so they got a friend at ISP3 to do the deed for them.

The transfer of IP to ISP2 happened shortly after that day, after which
ISP2 did the proper BGP announcements for IPs now assigned to it.

Re: "Defensive" BGP hijacking?

[Mel Beckman]

John,

I appreciate you making this statement, and I appreciate ARIN’s attitude that 
this is a community issue. ISPs have done an amazing job of self-regulation, 
while still preserving their ability to innovate and be agile in the 
marketplace. BGP is a perfect example of that kind of self-policing. 

Outside regulation is rarely preferable to community self control, and I think 
a clear path forward is for those of us in the community to contact BackConnect 
and respectfully ask that they recognize their incorrect actions and repudiate 
this practice for the future. Everyone deserves a chance to recognize their 
mistakes and apologize, so I think we owe BackConnect this much. 

Nanog seems like a great place for BackConnect to reply to the ISP community as 
well.

 -mel


> On Sep 12, 2016, at 10:27 AM, John Curran  wrote:
> 
> On Sep 12, 2016, at 12:08 PM, Scott Weeks 
> mailto:sur...@mauigateway.com>> wrote:
> 
> Are the RIRs the internet police?
> 
> Thank you Scott for posing that question…  :-)
> 
> As others have noted, ARIN does indeed revoke resources, but to be clear,
> this is generally due to fraudulent activities _related_ to the registry 
> itself
> (i.e. if you commit fraud in the course of obtaining resources, ARIN will
> revoke those resources once we have determined the fraud beyond
> reasonable doubt; see )
> 
> The specific circumstances raised (of a party announcing an AS# which they
> do not control) can only happen if the others in the industry allow such, and
> therefore it is entirely within the community to address.   While It is 
> possible
> that some peering and/or transit agreements have been broken (for example,
> those agreements which state that the party should only announce routes that
> they have permission to do so), but in any case, the act of announcing someone
> else’s number resources stems from usage that the community is allowing to
> occur, either thru action or inaction, and is not any fraudulent act with 
> respect
> the Internet number registry itself.
> 
> ARIN is not a law enforcement entity (although we do work with them on
> occasion with regard to registry fraud), and it really is up to the industry 
> to
> “police” Internet routing to the extent necessary and desirable to keep the
> Internet running.
> 
> Thanks,
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> 

Re: "Defensive" BGP hijacking?

[Valdis . Kletnieks]

On Mon, 12 Sep 2016 14:07:47 -0400, Jean-Francois Mezei said:

> So there are some cases where BGP hijacking may be desirable. I guess
> this is where judgement kicks in.

I don't see "hijacking" in your description of the iStop case - it appears
to have been fully coordinated and with permission.





pgpfgWD007XFy.pgp
Description: PGP signature

Re: "Defensive" BGP hijacking?

[Hugo Slabbert]

On Mon 2016-Sep-12 14:07:47 -0400, Jean-Francois Mezei 
 wrote:


On 2016-09-11 16:54, Hugo Slabbert wrote:

Hopefully this is operational enough, though obviously leaning more towards the 
policy side of things:

What does nanog think about a DDoS scrubber hijacking a network "for defensive 
purposes"?



Different spin but still "highjacking":

Many moons ago, iStop, a small ISP in Canada saw its services from Bell
Canada (access to last mile) cut.  However, its core network and transit
was still functional for a number of months.

ISP2 quickly offered to rescue the stranded customers. Once registred
with ISP2, a customer would see the DSL signal re-instated by Bell (now
paid by ISP2) but would continue to be handed IPs that belonged to iStop.

ISP2 made use of the continuing transit capacity from the iStop router
which therefore continued to make BGP announcements for the iStop IP
blocks (and the iStop router then just sent everythingt o ISP2's router
for distribution to end users). During this time, the iStop IP blocks
continued to belong to iStop from ARIn's point of view.

Eventually the transit to the iStop router stopped. That day, former
iStop customers now on ISP2 saw their access to internet essentially
killed. At that point, the iStop IP blocks still had not been transfered
to ISP2.

To save the day, ISP3 kicked in and started to make BGP annoucements for
iStop IPs and redirected the traffic to ISP2.

At that point, ISP3 hijacked iStop's IPs, but it was done to help the
situation, not to steal traffic or anything. (In fact, I think the GBP
announcements from ISP3 pointed to ISP2 routers).

Eventually, the iStop IP blocks was transfered to ISP2 which was then
legally able to do the BGP announcements for those IPs.

So there are some cases where BGP hijacking may be desirable. I guess
this is where judgement kicks in.



Was this all done at iStop's request and with their full support?

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature

Re: "Defensive" BGP hijacking?

[Jared Mauch]

> On Sep 12, 2016, at 1:59 PM, Florian Weimer  wrote:
> 
> * Mel Beckman:
> 
>> If we can't police ourselves, someone we don't like will do it for us. 
> 
> That hasn't happened with with IP spoofing, has it?  As far as I
> understand it, it is still a major contributing factor in
> denial-of-service attacks.  Self-regulation has been mostly
> unsuccessful, and yet nothing has happened on the political level.

IP spoofing filtering is more of a technical issue than the social issue of
BGP filtering.

BGP filtering is feasible in hardware and software today.  You can put a 600k 
line config on most devices without issues, and automate policy generation 
with a tool like bgpq3 or similar.

Most hardware requires a recirculation of the packet to do a lookup on the
source IP address.  This means halving your NPU performance of something that
hasn’t been in the 40 bytes per packet range for quite some time.

- Jared

Re: "Defensive" BGP hijacking?

[Jean-Francois Mezei]

On 2016-09-11 16:54, Hugo Slabbert wrote:
> Hopefully this is operational enough, though obviously leaning more towards 
> the policy side of things:
> 
> What does nanog think about a DDoS scrubber hijacking a network "for 
> defensive purposes"?


Different spin but still "highjacking":

Many moons ago, iStop, a small ISP in Canada saw its services from Bell
Canada (access to last mile) cut.  However, its core network and transit
was still functional for a number of months.

ISP2 quickly offered to rescue the stranded customers. Once registred
with ISP2, a customer would see the DSL signal re-instated by Bell (now
paid by ISP2) but would continue to be handed IPs that belonged to iStop.

ISP2 made use of the continuing transit capacity from the iStop router
which therefore continued to make BGP announcements for the iStop IP
blocks (and the iStop router then just sent everythingt o ISP2's router
for distribution to end users). During this time, the iStop IP blocks
continued to belong to iStop from ARIn's point of view.

Eventually the transit to the iStop router stopped. That day, former
iStop customers now on ISP2 saw their access to internet essentially
killed. At that point, the iStop IP blocks still had not been transfered
to ISP2.

To save the day, ISP3 kicked in and started to make BGP annoucements for
iStop IPs and redirected the traffic to ISP2.

At that point, ISP3 hijacked iStop's IPs, but it was done to help the
situation, not to steal traffic or anything. (In fact, I think the GBP
announcements from ISP3 pointed to ISP2 routers).

Eventually, the iStop IP blocks was transfered to ISP2 which was then
legally able to do the BGP announcements for those IPs.

So there are some cases where BGP hijacking may be desirable. I guess
this is where judgement kicks in.

Re: "Defensive" BGP hijacking?

[Florian Weimer]

* Mel Beckman:

> If we can't police ourselves, someone we don't like will do it for us. 

That hasn't happened with with IP spoofing, has it?  As far as I
understand it, it is still a major contributing factor in
denial-of-service attacks.  Self-regulation has been mostly
unsuccessful, and yet nothing has happened on the political level.

Re: "Defensive" BGP hijacking?

[Richard Hesse]

This behavior is never defensible nor acceptable.

In addition to being in the wrong with BGP hijacking a prefix, it
appears that Mr. Townsend had the wrong target, too. We've been
attacked a few dozen times by this botnet, and they could never muster
anything near 200 gbps worth of traffic. They were orders of magnitude
smaller, only around 8-16 gbps depending on attack.

Mr. Townsend's motives were wrong and so was his information.

-richard

On Sun, Sep 11, 2016 at 8:54 PM, Hugo Slabbert  wrote:
> Hopefully this is operational enough, though obviously leaning more towards 
> the policy side of things:
>
> What does nanog think about a DDoS scrubber hijacking a network "for 
> defensive purposes"?
>
> http://krebsonsecurity.com/2016/09/alleged-vdos-proprietors-arrested-in-israel/
>
> "For about six hours, we were seeing attacks of more than 200 Gbps hitting 
> us,” Townsend explained. “What we were doing was for defensive purposes. We 
> were simply trying to get them to stop and to gather as much information as 
> possible about the botnet they were using and report that to the proper 
> authorities.”
>
> --
> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> pgp key: B178313E   | also on Signal

Re: "Defensive" BGP hijacking?

[John Curran]

On Sep 12, 2016, at 12:08 PM, Scott Weeks 
mailto:sur...@mauigateway.com>> wrote:

Are the RIRs the internet police?

Thank you Scott for posing that question…  :-)

As others have noted, ARIN does indeed revoke resources, but to be clear,
this is generally due to fraudulent activities _related_ to the registry itself
(i.e. if you commit fraud in the course of obtaining resources, ARIN will
revoke those resources once we have determined the fraud beyond
reasonable doubt; see )

The specific circumstances raised (of a party announcing an AS# which they
do not control) can only happen if the others in the industry allow such, and
therefore it is entirely within the community to address.   While It is possible
that some peering and/or transit agreements have been broken (for example,
those agreements which state that the party should only announce routes that
they have permission to do so), but in any case, the act of announcing someone
else’s number resources stems from usage that the community is allowing to
occur, either thru action or inaction, and is not any fraudulent act with 
respect
the Internet number registry itself.

ARIN is not a law enforcement entity (although we do work with them on
occasion with regard to registry fraud), and it really is up to the industry to
“police” Internet routing to the extent necessary and desirable to keep the
Internet running.

Thanks,
/John

John Curran
President and CEO
ARIN

Re: "Defensive" BGP hijacking?

[Blake Hudson]

Scott Weeks wrote on 9/12/2016 11:31 AM:


I am somewhat in agreement with Mel:

"This thoughtless action requires a response from the community, and an
apology from BackConnect.   If we can't police ourselves, someone we
don't like will do it for us. "

But the first part seems to verge on vigilantism.  Solutions are hard.
BGP filters should be in place.  Maybe that's the non-vigilante response.
Force filters somehow.

However, this has all been discussed over and over here...  ;-)


scott

I agree that Mel's response is well reasoned and thoughtful.

Regarding my mention of a pattern of fraudulent behavior: RIPE indicates 
that BackConnect has recently announced 55 IP prefixes via BGP 
(https://stat.ripe.net/widget/as-routing-consistency#w.resource=AS203959), 
even though they only appear to have 5 IP4 allocations and are currently 
only announcing 8 /24 prefixes. Given BackConnect's position as an 
anti-ddos provider it would not be unusual for them to announce the IP 
space of other organizations. One would likely need to confirm with the 
owners of each of these 55 prefixes as to whether BackConnect had 
authorization to announce this address space.


Based on the announcement of 82.118.233.0/24, it appears that BGP 
filters are either not in place for BackConnect or are modified without 
sufficient procedures to verify authorization.

Re: "Defensive" BGP hijacking?

[Hugo Slabbert]

On Mon 2016-Sep-12 09:31:41 -0700, Scott Weeks  wrote:

Full disclosure:  I had a working relationship with Bryant when he was 
still at Staminus.


Bryant (if you're on list):
I mean no harm by this and never had any trouble working with you.  I just 
believe this is a conversation that needs to be had.



--- bl...@ispn.net wrote:
From: Blake Hudson 
Scott Weeks wrote on 9/12/2016 11:08 AM:

From: NANOG  on behalf
of Blake Hudson 




My suggestion is that BackConnect/Bryant Townsend should have their ASN
revoked for fraudulently announcing another organization's address
space. They are not law enforcement, they did not have a warrant or
judicial oversight, they were not in immediate mortal peril, etc, etc.
-


Are the RIRs the internet police?



ARIN has policies against fraudulently obtaining resources and has
policies for revoking said resources. One could argue that announcing
another org's IP resources without authorization is fraud and that said
ip resources were fraudulently obtained during the time they were
announced by BlackConnect. That said, this ASN was obtained through RIPE
(despite the person/company being located in Calfornia, USA) and I did
not see any RIPE policies related to fraud.

My thought is that if Mr Townsend shows disregard for the stability of
the internet by hijacking other's IP space, he should not be allowed to
participate. There are comments to the Kreb's article indicating that
this was not an isolated incident by Mr Townsend and instead represents
one event in a pattern of behavior.
-


I am somewhat in agreement with Mel:

"This thoughtless action requires a response from the community, and an
apology from BackConnect.   If we can't police ourselves, someone we
don't like will do it for us. "

But the first part seems to verge on vigilantism.  


Operators are free to do whatever they like inside their own networks as 
long as they don't impact others.  Barring RPKI coverage, we're still 
talking about an element of trust in BGP to believe what AS 203959 tells 
us.  If I no longer believe what 203959 advertises, I don't have to accept 
anything with aspath .* 203959 .* in it.  I don't see routing policy 
decisions in my own network as vigilantism.


Solutions are hard. BGP filters should be in place.  Maybe that's the 
non-vigilante response. Force filters somehow.


However, this has all been discussed over and over here...  ;-)


scott


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature

Re: "Defensive" BGP hijacking?

[Scott Weeks]

--- bl...@ispn.net wrote:
From: Blake Hudson 
Scott Weeks wrote on 9/12/2016 11:08 AM:
> From: NANOG  on behalf
> of Blake Hudson 


> My suggestion is that BackConnect/Bryant Townsend should have their ASN
> revoked for fraudulently announcing another organization's address
> space. They are not law enforcement, they did not have a warrant or
> judicial oversight, they were not in immediate mortal peril, etc, etc.
> -
>
>
> Are the RIRs the internet police?


ARIN has policies against fraudulently obtaining resources and has 
policies for revoking said resources. One could argue that announcing 
another org's IP resources without authorization is fraud and that said 
ip resources were fraudulently obtained during the time they were 
announced by BlackConnect. That said, this ASN was obtained through RIPE 
(despite the person/company being located in Calfornia, USA) and I did 
not see any RIPE policies related to fraud.

My thought is that if Mr Townsend shows disregard for the stability of 
the internet by hijacking other's IP space, he should not be allowed to 
participate. There are comments to the Kreb's article indicating that 
this was not an isolated incident by Mr Townsend and instead represents 
one event in a pattern of behavior.
-


I am somewhat in agreement with Mel: 

"This thoughtless action requires a response from the community, and an 
apology from BackConnect.   If we can't police ourselves, someone we 
don't like will do it for us. "

But the first part seems to verge on vigilantism.  Solutions are hard.
BGP filters should be in place.  Maybe that's the non-vigilante response.
Force filters somehow.

However, this has all been discussed over and over here...  ;-)


scott

Re: "Defensive" BGP hijacking?

[Blake Hudson]

Scott Weeks wrote on 9/12/2016 11:08 AM:



From: NANOG  on behalf
of Blake Hudson 

My suggestion is that BackConnect/Bryant Townsend should have their ASN
revoked for fraudulently announcing another organization's address
space. They are not law enforcement, they did not have a warrant or
judicial oversight, they were not in immediate mortal peril, etc, etc.
-


Are the RIRs the internet police?

scott



ARIN has policies against fraudulently obtaining resources and has 
policies for revoking said resources. One could argue that announcing 
another org's IP resources without authorization is fraud and that said 
ip resources were fraudulently obtained during the time they were 
announced by BlackConnect. That said, this ASN was obtained through RIPE 
(despite the person/company being located in Calfornia, USA) and I did 
not see any RIPE policies related to fraud.


My thought is that if Mr Townsend shows disregard for the stability of 
the internet by hijacking other's IP space, he should not be allowed to 
participate. There are comments to the Kreb's article indicating that 
this was not an isolated incident by Mr Townsend and instead represents 
one event in a pattern of behavior.

Re: "Defensive" BGP hijacking?

[Mel Beckman]

Once we let providers cross the line from legal to illegal actions, we're no 
better than the crooks, and the Internet will descend into lawless chaos. 
BackConnect's illicit action undoubtedly injured innocent parties, so it's not 
self defense, any more than shooting wildly into a crowd to stop an attacker 
would be self defense. 

This thoughtless action requires a response from the community, and an apology 
from BackConnect. 

If we can't police ourselves, someone we don't like will do it for us. 

 -mel beckman

> On Sep 12, 2016, at 8:47 AM, Ryan, Spencer  wrote:
> 
> I'm in the "never acceptable" camp. Filtering routes/peers? Sure. 
> Disconnecting one of your own customers to stop an attack originating from 
> them? Sure. Hijacking an AS you have no permission to control? No.
> 
> 
> Obviously my views and not of my employer.
> 
> Spencer Ryan | Senior Systems Administrator | 
> sr...@arbor.net<mailto:sr...@arbor.net>
> Arbor Networks
> +1.734.794.5033 (d) | +1.734.846.2053 (m)
> www.arbornetworks.com<http://www.arbornetworks.com/>
> 
> 
> 
> From: NANOG  on behalf of Blake Hudson 
> 
> Sent: Monday, September 12, 2016 11:24:03 AM
> To: nanog@nanog.org
> Subject: Re: "Defensive" BGP hijacking?
> 
> 
> Hugo Slabbert wrote on 9/11/2016 3:54 PM:
>> Hopefully this is operational enough, though obviously leaning more towards 
>> the policy side of things:
>> 
>> What does nanog think about a DDoS scrubber hijacking a network "for 
>> defensive purposes"?
>> 
>> http://krebsonsecurity.com/2016/09/alleged-vdos-proprietors-arrested-in-israel/
>> 
>> "For about six hours, we were seeing attacks of more than 200 Gbps hitting 
>> us,” Townsend explained. “What we were doing was for defensive purposes. We 
>> were simply trying to get them to stop and to gather as much information as 
>> possible about the botnet they were using and report that to the proper 
>> authorities.”
>> 
> 
> 
> https://bgpstream.com/event/54711
> 
> My suggestion is that BackConnect/Bryant Townsend should have their ASN
> revoked for fraudulently announcing another organization's address
> space. They are not law enforcement, they did not have a warrant or
> judicial oversight, they were not in immediate mortal peril, etc, etc.

Re: "Defensive" BGP hijacking?

[Scott Weeks]

From: NANOG  on behalf 
of Blake Hudson 

My suggestion is that BackConnect/Bryant Townsend should have their ASN
revoked for fraudulently announcing another organization's address
space. They are not law enforcement, they did not have a warrant or
judicial oversight, they were not in immediate mortal peril, etc, etc.
-


Are the RIRs the internet police?

scott

Re: "Defensive" BGP hijacking?

[Ryan, Spencer]

I'm in the "never acceptable" camp. Filtering routes/peers? Sure. Disconnecting 
one of your own customers to stop an attack originating from them? Sure. 
Hijacking an AS you have no permission to control? No.


Obviously my views and not of my employer.

Spencer Ryan | Senior Systems Administrator | 
sr...@arbor.net<mailto:sr...@arbor.net>
Arbor Networks
+1.734.794.5033 (d) | +1.734.846.2053 (m)
www.arbornetworks.com<http://www.arbornetworks.com/>



From: NANOG  on behalf of Blake Hudson 
Sent: Monday, September 12, 2016 11:24:03 AM
To: nanog@nanog.org
Subject: Re: "Defensive" BGP hijacking?


Hugo Slabbert wrote on 9/11/2016 3:54 PM:
> Hopefully this is operational enough, though obviously leaning more towards 
> the policy side of things:
>
> What does nanog think about a DDoS scrubber hijacking a network "for 
> defensive purposes"?
>
> http://krebsonsecurity.com/2016/09/alleged-vdos-proprietors-arrested-in-israel/
>
> "For about six hours, we were seeing attacks of more than 200 Gbps hitting 
> us,” Townsend explained. “What we were doing was for defensive purposes. We 
> were simply trying to get them to stop and to gather as much information as 
> possible about the botnet they were using and report that to the proper 
> authorities.”
>


https://bgpstream.com/event/54711

My suggestion is that BackConnect/Bryant Townsend should have their ASN
revoked for fraudulently announcing another organization's address
space. They are not law enforcement, they did not have a warrant or
judicial oversight, they were not in immediate mortal peril, etc, etc.

Re: "Defensive" BGP hijacking?

[Blake Hudson]

Hugo Slabbert wrote on 9/11/2016 3:54 PM:

Hopefully this is operational enough, though obviously leaning more towards the 
policy side of things:

What does nanog think about a DDoS scrubber hijacking a network "for defensive 
purposes"?

http://krebsonsecurity.com/2016/09/alleged-vdos-proprietors-arrested-in-israel/

"For about six hours, we were seeing attacks of more than 200 Gbps hitting us,” 
Townsend explained. “What we were doing was for defensive purposes. We were simply 
trying to get them to stop and to gather as much information as possible about the 
botnet they were using and report that to the proper authorities.”




https://bgpstream.com/event/54711

My suggestion is that BackConnect/Bryant Townsend should have their ASN 
revoked for fraudulently announcing another organization's address 
space. They are not law enforcement, they did not have a warrant or 
judicial oversight, they were not in immediate mortal peril, etc, etc.

Re: "Defensive" BGP hijacking?

[Ca By]

On Sunday, September 11, 2016, Hugo Slabbert  wrote:

> Hopefully this is operational enough, though obviously leaning more
> towards the policy side of things:
>
> What does nanog think about a DDoS scrubber hijacking a network "for
> defensive purposes"?


Not ok.

Never.


>
> http://krebsonsecurity.com/2016/09/alleged-vdos-proprietors-arrested-in-
> israel/
>
> "For about six hours, we were seeing attacks of more than 200 Gbps hitting
> us,” Townsend explained. “What we were doing was for defensive purposes. We
> were simply trying to get them to stop and to gather as much information as
> possible about the botnet they were using and report that to the proper
> authorities.”
>
> --
> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com 
> pgp key: B178313E   | also on Signal

Re: "Defensive" BGP hijacking?

[FHR]