"Defensive" BGP hijacking?

Wed Sep 14 21:49:55 UTC 2016

> On Sep 13, 2016, at 8:08 PM, Ca By <cb.list6 at gmail.com> wrote:
> 
> On Tuesday, September 13, 2016, Doug Montgomery <dougm.work at gmail.com>
> 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-support at ap.equinix.com
notify:     noc at ap.equinix.com
mnt-by:     MAINT-EQUINIXPAC
changed:    mvillalobos at ap.equinix.com 20151229
source:     NTTCOM

route:      191.96.129.0/24
descr:      Clan Servers
origin:     AS20473
notify:     net-support at ap.equinix.com
notify:     noc at ap.equinix.com
mnt-by:     MAINT-EQUINIXPAC
changed:    mvillalobos at ap.equinix.com 20151229
source:     NTTCOM

route:      191.101.191.0/24
descr:      Clan Servers
origin:     AS20473
notify:     net-support at ap.equinix.com
notify:     ap-noc at ap.equinix.com
mnt-by:     MAINT-EQUINIXPAC
changed:    mporquez at 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.shared at aapt.com.au
mnt-by:     MAINT-AS2764
changed:    nobody at 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:    modestas at 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:    modestas at 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 <mel at beckman.org <javascript:;>>
>> 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 <blake at ispn.net
>> <javascript:;>> 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
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160914/57febdc8/attachment.sig>