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.
dougm
Interesting that backconnect has invalid ROA issued
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 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@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