![nanog logo](/images/nanog-logo.png)
nanog mailing list archives
Re: "Defensive" BGP hijacking?
From: Sandra Murphy <sandy () tislabs com>
Date: Wed, 14 Sep 2016 17:49:55 -0400
On Sep 13, 2016, at 8:08 PM, Ca By <cb.list6 () gmail com> wrote: On Tuesday, September 13, 2016, Doug Montgomery <dougm.work () 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. dougmInteresting 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 () ap equinix com notify: noc () ap equinix com mnt-by: MAINT-EQUINIXPAC changed: mvillalobos () ap equinix com 20151229 source: NTTCOM route: 191.96.129.0/24 descr: Clan Servers origin: AS20473 notify: net-support () ap equinix com notify: noc () ap equinix com mnt-by: MAINT-EQUINIXPAC changed: mvillalobos () ap equinix com 20151229 source: NTTCOM route: 191.101.191.0/24 descr: Clan Servers origin: AS20473 notify: net-support () ap equinix com notify: ap-noc () ap equinix com mnt-by: MAINT-EQUINIXPAC changed: mporquez () 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 () aapt com au mnt-by: MAINT-AS2764 changed: nobody () 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 () 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 () 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 () 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 isthecore 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 blessthiskind 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 cellOn Sep 13, 2016, at 11:40 AM, Blake Hudson <blake () 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,visitingfamily, and my employees. The actions proved to be extremelyeffective,asall forms of harassment and threats from the attackers immediatelystopped.Bryant, what actions, exactly, did you take? This topic seemsintentionally 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 theseprefixes?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
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
Current thread:
- Re: "Defensive" BGP hijacking?, (continued)
- Re: "Defensive" BGP hijacking? Blake Hudson (Sep 12)
- Re: "Defensive" BGP hijacking? Scott Weeks (Sep 12)
- Re: "Defensive" BGP hijacking? Bryant Townsend (Sep 13)
- Re: "Defensive" BGP hijacking? Ca By (Sep 13)
- Re: "Defensive" BGP hijacking? Matt Freitag (Sep 13)
- Re: "Defensive" BGP hijacking? Ryan, Spencer (Sep 13)
- Re: "Defensive" BGP hijacking? Blake Hudson (Sep 13)
- Re: "Defensive" BGP hijacking? Mel Beckman (Sep 13)
- Re: "Defensive" BGP hijacking? Doug Montgomery (Sep 13)
- Re: "Defensive" BGP hijacking? Ca By (Sep 13)
- Re: "Defensive" BGP hijacking? Sandra Murphy (Sep 14)
- Re: "Defensive" BGP hijacking? Ca By (Sep 13)
- Re: "Defensive" BGP hijacking? Bryant Townsend (Sep 13)
- Re: "Defensive" BGP hijacking? Ca By (Sep 13)
- Re: "Defensive" BGP hijacking? Blake Hudson (Sep 13)
- Re: "Defensive" BGP hijacking? Hank Nussbacher (Sep 13)