[191436] in North American Network Operators' Group
Re: "Defensive" BGP hijacking?
daemon@ATHENA.MIT.EDU (Sandra Murphy)
Wed Sep 14 17:51:58 2016
X-Original-To: nanog@nanog.org
From: Sandra Murphy <sandy@tislabs.com>
In-Reply-To: <CAD6AjGQWm7ULdOJuNs7kwC45aB7G6evdx1OQiBO94bUeRzDXwQ@mail.gmail.com>
Date: Wed, 14 Sep 2016 17:49:55 -0400
To: Ca By <cb.list6@gmail.com>,
NANOG list <nanog@nanog.org>
Cc: Sandra Murphy <sandy@tislabs.com>
Errors-To: nanog-bounces@nanog.org
--Apple-Mail=_0CF0D85B-72FF-441A-82C0-E8F58545A5DD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
> On Sep 13, 2016, at 8:08 PM, Ca By <cb.list6@gmail.com> wrote:
>=20
> On Tuesday, September 13, 2016, Doug Montgomery <dougm.work@gmail.com>
> wrote:
>=20
>> 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.
>>=20
>> *cough https://www.nanog.org/meetings/abstract?id=3D2846 =
cough*
>>=20
>> I now return us to our discussion of network police, questionnaires =
for
>> network security, and the use of beer as a motivating force.
>>=20
>> dougm
>>=20
>>=20
> Interesting that backconnect has invalid ROA issued
>=20
> http://bgp.he.net/AS203959#_prefixes
Well, no, that=E2=80=99s 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 =E2=80=94 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=E2=80=99t keep up and their providers aren=E2=80=99t =
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 =E2=80=9Cnobody=E2=80=9D part???)
At least the aggregate announcements aren=E2=80=99t 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
=E2=80=94Sandy
(Since bgp.he.net changes as the routing world changes, the red keys =
could be gone by the time anyone looks, of course.)
>=20
> On Tue, Sep 13, 2016 at 2:51 PM, Mel Beckman <mel@beckman.org =
<javascript:;>>
>> wrote:
>>=20
>>> Blake,
>>>=20
>>> 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.
>>>=20
>>> 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?
>>>=20
>>> 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?
>>>=20
>>> -mel via cell
>>>=20
>>>> On Sep 13, 2016, at 11:40 AM, Blake Hudson <blake@ispn.net
>> <javascript:;>> wrote:
>>>>=20
>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>> Questions I was left with:
>>>>=20
>>>> 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?
>>>>=20
>>>=20
>>=20
>>=20
>>=20
>> --
>> DougM at Work
>>=20
--Apple-Mail=_0CF0D85B-72FF-441A-82C0-E8F58545A5DD
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJX2cYLAAoJEHplpQeet0IZHU4P/2ZCfpVZfE05NWnlPdpdZuH1
oJn2fqGeTI4/t1EcC2kWr921zY3oW5XwcVJ/AIBjFidotMmGK6O/NiKGAa0wFaQ3
JkH5L+GlgA7KFcGoxY0NQoPHeQ7Q00c+yNoNBwu/JU5QI4pA5X0jxR9SlJeJ9JOD
gFkWrbVy1rM7854pyfwpaaNXvf5ShgFFJUAWouFmQ9yIRkkNsWYGMYlkkJWHdYI1
hMxrUO9gccAEvtUty7JPRH4Dix2XXF/8zwUQnY4jvxAs6tom4vSo3nRi8f9POfpi
GDm1K5GzA3PahoGdcbqCWPzGA53JyQl28Nn5+RJlhPIv+iL7885vxmCp4Z8+WkLl
BrTo2NjaV6cEETbyV37nCG/CLGOO8Lbl62N7dWG1Kjl0PVEj8N0oNVaaFJTjOugn
WzvwceQawjC0Anxc6Vcb7vBxwOdRftvreOzU1sXB7JOf6aepl30jX+3OPmxIr31j
xElDIHBCg5Ke2rf7MPP/fV3YKd+6oWblG1/QpUAk2Ei1yTKer4Z/wrOLkU10OQfx
sVCY5WjNLcRnaPdFs04PfWPoCUiGoZczVED4A99mEzo8NN3IgjeUE7Zb1fi/oF+N
OOG+AqW2zEDbl8TdaHpnDAxNduy4n3ZwGP86zp2hAOZh+36LaV025/RnDEFrapBJ
6t/quN8oyn7nSWiDvLEM
=iZcH
-----END PGP SIGNATURE-----
--Apple-Mail=_0CF0D85B-72FF-441A-82C0-E8F58545A5DD--
