questions regarding prefix hijacking
Hi, as probably many of you know, it's possible to create a "route" object to RIPE database for an address space which is allocated outside the RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example an address space is from APNIC or ARIN region and AS is from RIPE region. For example a LIR in RIPE region creates a "route" object to RIPE database for 157.166.266.0/24(used by Turner Broadcasting System) prefix without having written permission from Turner Broadcasting System and as this LIR uses up-link providers who create prefix filters automatically according to RADb database entries, this ISP is soon able to announce this 157.166.266.0/24 prefix to Internet. This should disturb the availability of the real 157.166.266.0/24 network on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible? regards, Martin
Unfortunately, it is way too easy for people to inject routes into the global routing system. I think most of the folks on the list can attest to that. :-) - ferg On Wed, Aug 7, 2013 at 1:20 AM, Martin T <m4rtntns@gmail.com> wrote:
Hi,
as probably many of you know, it's possible to create a "route" object to RIPE database for an address space which is allocated outside the RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example an address space is from APNIC or ARIN region and AS is from RIPE region. For example a LIR in RIPE region creates a "route" object to RIPE database for 157.166.266.0/24(used by Turner Broadcasting System) prefix without having written permission from Turner Broadcasting System and as this LIR uses up-link providers who create prefix filters automatically according to RADb database entries, this ISP is soon able to announce this 157.166.266.0/24 prefix to Internet. This should disturb the availability of the real 157.166.266.0/24 network on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible?
regards, Martin
-- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com
Ok. And such attacks have happened in the past? For example one could do a pretty widespread damage for at least short period of time if it announces for example some of the root DNS server prefixes(as long prefixes as possible) to it's upstream provider and as upstream provider probably prefers client traffic over it's peerings or upstreams, it will prefer those routes by malicious ISP for all the traffic to root DNS servers? regards, Martin 2013/8/7, Paul Ferguson <fergdawgster@gmail.com>:
Unfortunately, it is way too easy for people to inject routes into the global routing system.
I think most of the folks on the list can attest to that. :-)
- ferg
On Wed, Aug 7, 2013 at 1:20 AM, Martin T <m4rtntns@gmail.com> wrote:
Hi,
as probably many of you know, it's possible to create a "route" object to RIPE database for an address space which is allocated outside the RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example an address space is from APNIC or ARIN region and AS is from RIPE region. For example a LIR in RIPE region creates a "route" object to RIPE database for 157.166.266.0/24(used by Turner Broadcasting System) prefix without having written permission from Turner Broadcasting System and as this LIR uses up-link providers who create prefix filters automatically according to RADb database entries, this ISP is soon able to announce this 157.166.266.0/24 prefix to Internet. This should disturb the availability of the real 157.166.266.0/24 network on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible?
regards, Martin
-- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com
On 8/7/13 11:13 AM, Martin T wrote:
Ok. And such attacks have happened in the past? For example one could do a pretty widespread damage for at least short period of time if it announces for example some of the root DNS server prefixes(as long prefixes as possible) to it's upstream provider and as upstream provider probably prefers client traffic over it's peerings or upstreams, it will prefer those routes by malicious ISP for all the traffic to root DNS servers?
Of course similar problems have occurred in the past. Just take a look at this video: http://www.youtube.com/watch?v=IzLPKuAOe50 Some minor occurrences have happened recently as well. Ciao! -- Massimiliano Stucchi
On Wed, Aug 7, 2013 at 2:13 AM, Martin T <m4rtntns@gmail.com> wrote:
Ok. And such attacks have happened in the past? For example one could do a pretty widespread damage for at least short period of time if it announces for example some of the root DNS server prefixes(as long prefixes as possible) to it's upstream provider and as upstream provider probably prefers client traffic over it's peerings or upstreams, it will prefer those routes by malicious ISP for all the traffic to root DNS servers?
Historically, most prefix hijacks have been accidental, generally due to configuration error -- for instance: http://www.renesys.com/2008/02/pakistan-hijacks-youtube-1/ Having said that, there are quite a few documented cases of it being done intentionally, and for nefarious purposes. - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com
On Wed, 07 Aug 2013 03:07:04 -0700, Paul Ferguson said:
Having said that, there are quite a few documented cases of it being done intentionally, and for nefarious purposes.
Do I need ECC on my brain to stop the bitrot, or was there a kerfluffle a long ways back when somebody announced 127/8, and a surprising number of systems actually bit?
From: Paul Ferguson Sent: Wednesday, August 7, 2013 3:07 AM Subject: Re: questions regarding prefix hijacking
Historically, most prefix hijacks have been accidental, generally due to configuration error -- for instance...
Having said that, there are quite a few documented cases of it being done intentionally, and for nefarious purposes.
It would be incredibly useful for someone to start a page or a category on Wikipedia "List of Internet Routing and DNS Incidents" that would include both "accidental" and malicious events. - Marsh
On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray <maray@microsoft.com> wrote:
It would be incredibly useful for someone to start a page or a category on Wikipedia "List of Internet Routing and DNS Incidents" that would include both "accidental" and malicious events.
do we really need that? they seem to occur often enough that that isn't really required :(
From: Christopher Morrow Sent: Wednesday, August 7, 2013 2:06 PM
On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray <maray@microsoft.com> wrote:
It would be incredibly useful for someone to start a page or a category on
Wikipedia "List of Internet Routing and DNS Incidents" that would include both "accidental" and malicious events.
do we really need that?
Have you ever heard of someone using IP addresses as an access control mechanism? (AKA, "IP whitelist") When I hear about this, I would really *love* to be able to link them to a credible source.
they seem to occur often enough that that isn't really required :(
*I* believe you, but in practice that's not sufficient to convince many other folks. Currently, a section of a page on Wikipedia lists 7 incidents going back to 1997. http://en.wikipedia.org/wiki/IP_hijacking#Public_incidents Serious question: Do folks here feel that is an accurate representation of this phenomenon in practice? - Marsh
Regards Alexander Alexander Neilson Neilson Productions Limited alexander@neilson.net.nz 021 329 681 022 456 2326 On 8/08/2013, at 9:47 AM, Marsh Ray <maray@microsoft.com> wrote:
From: Christopher Morrow Sent: Wednesday, August 7, 2013 2:06 PM
On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray <maray@microsoft.com> wrote:
It would be incredibly useful for someone to start a page or a category on
Wikipedia "List of Internet Routing and DNS Incidents" that would include both "accidental" and malicious events.
I would see there being a problem with Wikipedia trying to categorise some of them as accidental / malicious. I think if it was done it would have to be list where ones that were publicly announced as accidental would be listed as accidents and the rest left un noted to comply with neutral point of view and verification.
do we really need that?
Have you ever heard of someone using IP addresses as an access control mechanism? (AKA, "IP whitelist")
When I hear about this, I would really *love* to be able to link them to a credible source.
they seem to occur often enough that that isn't really required :(
*I* believe you, but in practice that's not sufficient to convince many other folks. Currently, a section of a page on Wikipedia lists 7 incidents going back to 1997. http://en.wikipedia.org/wiki/IP_hijacking#Public_incidents
Serious question: Do folks here feel that is an accurate representation of this phenomenon in practice?
I would tend to say as it lists BGPmon.net as an external link thats a good resource for finding out about other ones that have happened. Also maybe that section should be renamed notable incidents and just have it as a sample of some of these incidents.
- Marsh
In message <bd2d7aeac3fa49afa090e4869977d227@BLUPR03MB166.namprd03.prod.outlook .com>, Marsh Ray writes:
From: Christopher Morrow Sent: Wednesday, August 7, 2013 2:06 PM
On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray <maray@microsoft.com> wrote:
It would be incredibly useful for someone to start a page or a category on Wikipedia "List of Internet Routing and DNS Incidents" that would include both "accidental" and malicious events.
do we really need that?
Have you ever heard of someone using IP addresses as an access control mechanism? (AKA, "IP whitelist")
Yes. I've even had to configure my DHCP client to auto generate requests to get the whitelist updated when my ISP gives my cable modem a new address. They are used all the time to allow access to DNS servers. If fact we ship nameservers where the default setting whitelist particular sets of clients (directly connected) by default.
When I hear about this, I would really *love* to be able to link them to a credible source.
they seem to occur often enough that that isn't really required :(
*I* believe you, but in practice that's not sufficient to convince many other folks. Currently, a section of a page on Wikipedia lists 7 incidents going back to 1997. http://en.wikipedia.org/wiki/IP_hijacking#Public_incidents
Serious question: Do folks here feel that is an accurate representation of this phenomenon in practice?
- Marsh -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
They do happen, but they get little publicity. People that I've talked to about this say, for reasons mostly unspecified, they'd rather not talk about it. On Wed, Aug 7, 2013 at 6:06 PM, Christopher Morrow <morrowc.lists@gmail.com>wrote:
On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray <maray@microsoft.com> wrote:
It would be incredibly useful for someone to start a page or a category
on Wikipedia "List of Internet Routing and DNS Incidents" that would include both "accidental" and malicious events.
do we really need that? they seem to occur often enough that that isn't really required :(
-- -- ========================= Carlos M. Martinez-Cagnazzo h <http://cagnazzo.name>ttp://cagnazzo.me =========================
Saku,
In most cases upstream does not do any automatic prefix filter generation, it's maybe somewhat popular in mid-sized european shops but generally not too common.
What do you mean? In most cases upstreams do not filter prefixes at all?
There is active on-going work to secure BGP and you may want to read up on 'RPKI' which is further along that track.
Thanks for mentioning this! Very interesting effort. I validated some routes in LIR portal, verified that those are validated using RIPE rpki-validator tool and a Juniper router connected to validator: rpki@lr1.ham1.de> show validation session detail Session 195.13.63.18, State: up, Session index: 2 Group: eurotransit-testbed, Preference: 100 Local IPv4 address: 193.34.50.25, Port: 8282 Refresh time: 120s Hold time: 180s Record Life time: 3600s Serial (Full Update): 559 Serial (Incremental Update): 559 Session flaps: 0 Session uptime: 00:11:35 Last PDU received: 00:00:27 IPv4 prefix count: 4921 IPv6 prefix count: 833 rpki@lr1.ham1.de> show route protocol bgp 5.11.81.0 inet.0: 456407 destinations, 456408 routes (456407 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 5.11.81.0/24 *[BGP/170] 00:11:59, localpref 110, from 79.141.168.1 AS path: 33926 25577 43532 I, validation-state: valid > to 193.34.50.1 via em0.0 RPKI-valid.inet.0: 11440 destinations, 11440 routes (11440 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 5.11.81.0/24 *[BGP/170] 00:11:11, localpref 110, from 79.141.168.1 AS path: 33926 25577 43532 I, validation-state: valid > to 193.34.50.1 via em0.0 rpki@lr1.ham1.de> Massimiliano, Paul, Indra: thanks for pointing out those interesting cases! regards, Martin 2013/8/8, Carlos Martinez-Cagnazzo <carlosm3011@gmail.com>:
They do happen, but they get little publicity. People that I've talked to about this say, for reasons mostly unspecified, they'd rather not talk about it.
On Wed, Aug 7, 2013 at 6:06 PM, Christopher Morrow <morrowc.lists@gmail.com>wrote:
On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray <maray@microsoft.com> wrote:
It would be incredibly useful for someone to start a page or a category
on Wikipedia "List of Internet Routing and DNS Incidents" that would include both "accidental" and malicious events.
do we really need that? they seem to occur often enough that that isn't really required :(
-- -- ========================= Carlos M. Martinez-Cagnazzo h <http://cagnazzo.name>ttp://cagnazzo.me =========================
On (2013-08-08 17:48 +0300), Martin T wrote:
In most cases upstream does not do any automatic prefix filter generation, it's maybe somewhat popular in mid-sized european shops but generally not too common.
What do you mean? In most cases upstreams do not filter prefixes at all?
Exactly. Source data has usually low quality and even even data is high quality for many organization it's very complex task. Internet does not have very good MTBF what we are pretty good at is MTTR. -- ++ytti
It has happened in the past and there is no silver bullet solution to prevent this 100%. -----Original Message----- From: Martin T [mailto:m4rtntns@gmail.com] Sent: Wednesday, 7 August 2013 7:13 PM To: Paul Ferguson Cc: nanog@nanog.org Subject: Re: questions regarding prefix hijacking Ok. And such attacks have happened in the past? For example one could do a pretty widespread damage for at least short period of time if it announces for example some of the root DNS server prefixes(as long prefixes as possible) to it's upstream provider and as upstream provider probably prefers client traffic over it's peerings or upstreams, it will prefer those routes by malicious ISP for all the traffic to root DNS servers? regards, Martin 2013/8/7, Paul Ferguson <fergdawgster@gmail.com>:
Unfortunately, it is way too easy for people to inject routes into the global routing system.
I think most of the folks on the list can attest to that. :-)
- ferg
On Wed, Aug 7, 2013 at 1:20 AM, Martin T <m4rtntns@gmail.com> wrote:
Hi,
as probably many of you know, it's possible to create a "route" object to RIPE database for an address space which is allocated outside the RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example an address space is from APNIC or ARIN region and AS is from RIPE region. For example a LIR in RIPE region creates a "route" object to RIPE database for 157.166.266.0/24(used by Turner Broadcasting System) prefix without having written permission from Turner Broadcasting System and as this LIR uses up-link providers who create prefix filters automatically according to RADb database entries, this ISP is soon able to announce this 157.166.266.0/24 prefix to Internet. This should disturb the availability of the real 157.166.266.0/24 network on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible?
regards, Martin
-- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com
One big happening I can recall was the AS7007 incident way back in 1997. http://en.wikipedia.org/wiki/AS_7007_incident Cheers. On Wed, Aug 7, 2013 at 7:23 PM, Ahad Aboss <ahad@telcoinabox.com> wrote:
It has happened in the past and there is no silver bullet solution to prevent this 100%.
-----Original Message----- From: Martin T [mailto:m4rtntns@gmail.com] Sent: Wednesday, 7 August 2013 7:13 PM To: Paul Ferguson Cc: nanog@nanog.org Subject: Re: questions regarding prefix hijacking
Ok. And such attacks have happened in the past? For example one could do a pretty widespread damage for at least short period of time if it announces for example some of the root DNS server prefixes(as long prefixes as possible) to it's upstream provider and as upstream provider probably prefers client traffic over it's peerings or upstreams, it will prefer those routes by malicious ISP for all the traffic to root DNS servers?
regards, Martin
2013/8/7, Paul Ferguson <fergdawgster@gmail.com>:
Unfortunately, it is way too easy for people to inject routes into the global routing system.
I think most of the folks on the list can attest to that. :-)
- ferg
On Wed, Aug 7, 2013 at 1:20 AM, Martin T <m4rtntns@gmail.com> wrote:
Hi,
as probably many of you know, it's possible to create a "route" object to RIPE database for an address space which is allocated outside the RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example an address space is from APNIC or ARIN region and AS is from RIPE region. For example a LIR in RIPE region creates a "route" object to RIPE database for 157.166.266.0/24(used by Turner Broadcasting System) prefix without having written permission from Turner Broadcasting System and as this LIR uses up-link providers who create prefix filters automatically according to RADb database entries, this ISP is soon able to announce this 157.166.266.0/24 prefix to Internet. This should disturb the availability of the real 157.166.266.0/24 network on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible?
regards, Martin
-- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com
On (2013-08-07 11:20 +0300), Martin T wrote:
on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible?
Certainly practical scenario, but in many cases not needed at all. In most cases upstream does not do any automatic prefix filter generation, it's maybe somewhat popular in mid-sized european shops but generally not too common. There is active on-going work to secure BGP and you may want to read up on 'RPKI' which is further along that track. -- ++ytti
On Wed, Aug 7, 2013 at 1:58 AM, Saku Ytti <saku@ytti.fi> wrote:
On (2013-08-07 11:20 +0300), Martin T wrote:
on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible?
Certainly practical scenario, but in many cases not needed at all. In most cases upstream does not do any automatic prefix filter generation, it's maybe somewhat popular in mid-sized european shops but generally not too common.
There is active on-going work to secure BGP and you may want to read up on 'RPKI' which is further along that track.
I hope it has better adoption than BCP38/BCP84. :-) - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com
In message <CANQy6Fb2cv+bdtaz7LVx0G_D0FbxJYqSr=ki5Hfm_9QOum1cnw@mail.gmail.com> , Paul Ferguson writes:
On Wed, Aug 7, 2013 at 1:58 AM, Saku Ytti <saku@ytti.fi> wrote:
On (2013-08-07 11:20 +0300), Martin T wrote:
on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible?
Certainly practical scenario, but in many cases not needed at all. In most cases upstream does not do any automatic prefix filter generation, it's maybe somewhat popular in mid-sized european shops but generally not too common.
There is active on-going work to secure BGP and you may want to read up on 'RPKI' which is further along that track.
I hope it has better adoption than BCP38/BCP84. :-)
SIDR should help with BCP38/BCP84 as it allows correct filters to be securely built. Mark
- ferg
-- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
It appears AS3549 is announcing 10.0.0.0/8. I noticed it from an AS3549 customer.
From GBLX looking glass, ATL1
traceroute Protocol [ip]: ip Target IP address: 10.0.0.1 Source address: Numeric display [n]: n Timeout in seconds [3]: 1 Probe count [3]: 2 Minimum Time to Live [1]: 1 Maximum Time to Live [30]: 30 Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 10.0.0.1 VRF info: (vrf in name/id, vrf out name/id) 1 te3-1-10G.par9.CTA1.GRU.gblx.net (67.16.142.26) 120 msec 124 msec 2 122.5.125.189.static.impsat.net.br (189.125.5.122) 120 msec 120 msec 3 10.0.0.1 [AS 262487] 124 msec 120 msec
Apparently the customer didn't have proper inbound filter...... Reply from 10.0.0.1: bytes=32 time=132ms TTL=61
On 08/07/2013 02:20 AM, Martin T wrote:
Hi,
as probably many of you know, it's possible to create a "route" object to RIPE database for an address space which is allocated outside the RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example an address space is from APNIC or ARIN region and AS is from RIPE region. For example a LIR in RIPE region creates a "route" object to RIPE database for 157.166.266.0/24(used by Turner Broadcasting System) prefix without having written permission from Turner Broadcasting System and as this LIR uses up-link providers who create prefix filters automatically according to RADb database entries, this ISP is soon able to announce this 157.166.266.0/24 prefix to Internet. This should disturb the availability of the real 157.166.266.0/24 network on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible?
regards, Martin
participants (13)
-
Ahad Aboss -
Alexander Neilson -
Carlos Martinez-Cagnazzo -
Christopher Morrow -
Indra Pramana -
Mark Andrews -
Marsh Ray -
Martin T -
Massimiliano Stucchi -
Paul Donner -
Paul Ferguson -
Saku Ytti -
Valdis.Kletnieks＠vt.edu