Prefix hijacking, how to prevent and fix currently
AS Number 43239 AS Name SPETSENERGO-AS SpetsEnergo Ltd. Has started hijacking our IPv4 prefix, while this prefix was NOT in production, it worries us that it was this easy for someone to hijack it. http://bgp.he.net/AS43239#_prefixes 103.20.212.0/22 <- This belongs to us. 103.238.232.0/22 KNS Techno Integrators Pvt. Ltd. 193.43.33.0/24 hydrocontrol S.C.R.L. 193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline Where do we complain to get this fixed. -Tarun AS132420
I would say, start off with the NOC Contact http://bgp.he.net/AS43239#_whois It is most likely that someone has fat-fingered the IP space.. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message -----
From: "Tarun Dua" <lists@tarundua.net> To: nanog@nanog.org Sent: Thursday, August 28, 2014 12:55:25 PM Subject: Prefix hijacking, how to prevent and fix currently
AS Number 43239 AS Name SPETSENERGO-AS SpetsEnergo Ltd.
Has started hijacking our IPv4 prefix, while this prefix was NOT in production, it worries us that it was this easy for someone to hijack it.
http://bgp.he.net/AS43239#_prefixes
103.20.212.0/22 <- This belongs to us.
103.238.232.0/22 KNS Techno Integrators Pvt. Ltd. 193.43.33.0/24 hydrocontrol S.C.R.L. 193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline
Where do we complain to get this fixed.
-Tarun AS132420
In this case.. Google that ASN name. Then go upstream. On 29-Aug-2014 8:56 am, "Faisal Imtiaz" <faisal@snappytelecom.net> wrote:
I would say, start off with the NOC Contact
http://bgp.he.net/AS43239#_whois
It is most likely that someone has fat-fingered the IP space..
Faisal Imtiaz Snappy Internet & Telecom
----- Original Message -----
From: "Tarun Dua" <lists@tarundua.net> To: nanog@nanog.org Sent: Thursday, August 28, 2014 12:55:25 PM Subject: Prefix hijacking, how to prevent and fix currently
AS Number 43239 AS Name SPETSENERGO-AS SpetsEnergo Ltd.
Has started hijacking our IPv4 prefix, while this prefix was NOT in production, it worries us that it was this easy for someone to hijack it.
http://bgp.he.net/AS43239#_prefixes
103.20.212.0/22 <- This belongs to us.
103.238.232.0/22 KNS Techno Integrators Pvt. Ltd. 193.43.33.0/24 hydrocontrol S.C.R.L. 193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline
Where do we complain to get this fixed.
-Tarun AS132420
On Aug 28, 2014, at 9:55 AM, Tarun Dua <lists@tarundua.net> wrote:
AS Number 43239 AS Name SPETSENERGO-AS SpetsEnergo Ltd.
Has started hijacking our IPv4 prefix, while this prefix was NOT in production, it worries us that it was this easy for someone to hijack it.
http://bgp.he.net/AS43239#_prefixes
103.20.212.0/22 <- This belongs to us.
103.238.232.0/22 KNS Techno Integrators Pvt. Ltd. 193.43.33.0/24 hydrocontrol S.C.R.L. 193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline
Where do we complain to get this fixed.
-Tarun AS132420
Do you implement RPKI? Are providers that neighbor with them implementing RPKI? If not, complain to the folks not indicating RPKI and therefore accepting a hijacked prefix. Including yourself.
On (2014-08-29 03:24 +0000), Fred Baker (fred) wrote:
Do you implement RPKI? Are providers that neighbor with them implementing RPKI?
I feel RPKI would be much more marketable if vendors would implement 'loose' mode. Loose mode would drop failing routes, iff there is covering (i.e. less specific is ok) route already in RIB. This mode would protect from routed hijacks, but not from non-routed hijacks, which are less serious. And it would completely remove false-positive blackholing. There is very small incentive for SP to deploy RPKI, since user-error in far-end, would make my product look worse than competitors product. I'm spending money to lose money. -- ++ytti
On Fri, Aug 29, 2014 at 06:25:16PM +0900, Randy Bush wrote:
Loose mode would drop failing routes, iff there is covering (i.e. less specific is ok) route already in RIB.
isn't that exactly the hole punching attack?
The proposed 'loose' mode protects against unauthorized hole punching
Am 29.08.2014 11:25, schrieb Randy Bush:
Loose mode would drop failing routes, iff there is covering (i.e. less specific is ok) route already in RIB. isn't that exactly the hole punching attack?
randy No, as the the more specific route is signed and is preferred (longest match routing) against the less specific hijacked route
Loose mode would drop failing routes, iff there is covering (i.e. less specific is ok) route already in RIB. isn't that exactly the hole punching attack? No, as the the more specific route is signed and is preferred (longest match routing) against the less specific hijacked route
clearly i am missing something. got a write-up? randy
Am 29.08.2014 11:39, schrieb Randy Bush:
Loose mode would drop failing routes, iff there is covering (i.e. less specific is ok) route already in RIB. isn't that exactly the hole punching attack? No, as the the more specific route is signed and is preferred (longest match routing) against the less specific hijacked route clearly i am missing something. got a write-up?
randy sorry my mistake, you're right
Loose mode would drop failing routes, iff there is covering (i.e. less specific is ok) route already in RIB. isn't that exactly the hole punching attack? No, as the the more specific route is signed and is preferred (longest match routing) against the less specific hijacked route clearly i am missing something. got a write-up? sorry my mistake, you're right
been around this a few times. no magic pill found. would love to learn of one. but one either wants to stop mis-originations or not. but i would like to see an actual write-up of this 'loose mode' and terse would be fine, heck preferred. :) randy
On Fri, Aug 29, 2014 at 06:39:32PM +0900, Randy Bush wrote:
Loose mode would drop failing routes, iff there is covering (i.e. less specific is ok) route already in RIB. isn't that exactly the hole punching attack? No, as the the more specific route is signed and is preferred (longest match routing) against the less specific hijacked route
clearly i am missing something. got a write-up?
I'll attempt to clarify. Assume: ROA: 10.0.0.0/16, max_length = 16, origin = AS123 in RIB: 10.0.0.0/16 origin AS123 (valid) With the above two conditions any updates containing more-specifics of 10.0.0.0/16 would be rejected/not-installed, just like in todays 'strict mode' Loose mode A would look like this: In the case that 10.0.0.0/16 origin AS123 is not in your table, the loose mode would kick in and one could accept more specifics for 10.0.0.0/16, but only when originated by AS123. Loose mode B would look like this: In the case that 10.0.0.0/16 origin AS123 is not in your table, the loose mode would kick in and one could accept more specifics for 10.0.0.0/16 originated by any ASN. The major point is that when the valid route is missing, one might choose to accept invalid routes. When the valid route returns, the invalids are purged from your table. Or in other words: Proposal is, that when additional 'loose' mode is configured, invalid routes are accepted if and only if they are the only route to destination. If there is any other route (less-specific) which is not invalid, it will be used, instead of the invalid route. Kind regards, Job
On Aug 29, 2014, at 6:08 AM, Job Snijders <job@instituut.net> wrote:
On Fri, Aug 29, 2014 at 06:39:32PM +0900, Randy Bush wrote:
Loose mode would drop failing routes, iff there is covering (i.e. less specific is ok) route already in RIB. isn't that exactly the hole punching attack? No, as the the more specific route is signed and is preferred (longest match routing) against the less specific hijacked route
clearly i am missing something. got a write-up?
I'll attempt to clarify.
Assume:
ROA: 10.0.0.0/16, max_length = 16, origin = AS123 in RIB: 10.0.0.0/16 origin AS123 (valid)
With the above two conditions any updates containing more-specifics of 10.0.0.0/16 would be rejected/not-installed, just like in todays 'strict mode'
Loose mode A would look like this:
In the case that 10.0.0.0/16 origin AS123 is not in your table, the loose mode would kick in and one could accept more specifics for 10.0.0.0/16, but only when originated by AS123.
Loose mode B would look like this:
In the case that 10.0.0.0/16 origin AS123 is not in your table, the loose mode would kick in and one could accept more specifics for 10.0.0.0/16 originated by any ASN.
The major point is that when the valid route is missing, one might choose to accept invalid routes. When the valid route returns, the invalids are purged from your table.
Or in other words: Proposal is, that when additional 'loose' mode is configured, invalid routes are accepted if and only if they are the only route to destination. If there is any other route (less-specific) which is not invalid, it will be used, instead of the invalid route.
In your examples, you presume there's a ROA for the less-specific. Here you say "not invalid", which would mean a route that is "unknown", i.e. no ROA exists. Your Loose Mode A relies on the existence of the ROA - you accept more specifics but only when originated by the ASN in the ROA. So which do you mean? The less specific has a ROA or the less specific may not have a ROA? (Just trying to work this out in my head.) --Sandy P.S. All the RPKI use is subject to local routing policy, so working out impact of different policies is a really good thing.
On Fri, Aug 29, 2014 at 06:17:09AM -0400, Sandra Murphy wrote:
Loose mode A would look like this:
In the case that 10.0.0.0/16 origin AS123 is not in your table, the loose mode would kick in and one could accept more specifics for 10.0.0.0/16, but only when originated by AS123.
Loose mode B would look like this:
In the case that 10.0.0.0/16 origin AS123 is not in your table, the loose mode would kick in and one could accept more specifics for 10.0.0.0/16 originated by any ASN.
The major point is that when the valid route is missing, one might choose to accept invalid routes. When the valid route returns, the invalids are purged from your table.
Or in other words: Proposal is, that when additional 'loose' mode is configured, invalid routes are accepted if and only if they are the only route to destination. If there is any other route (less-specific) which is not invalid, it will be used, instead of the invalid route.
In your examples, you presume there's a ROA for the less-specific.
Correct.
Here you say "not invalid", which would mean a route that is "unknown", i.e. no ROA exists.
Sorry, with "not invalid" i meant "valid".
Your Loose Mode A relies on the existence of the ROA - you accept more specifics but only when originated by the ASN in the ROA.
I'd like to accept more-specifics, only in the absense of the less-specific ROA covered prefix.
So which do you mean? The less specific has a ROA or the less specific may not have a ROA?
The less specific has to have a ROA, for any loose mode to make sense. Loose mode A & B came into existence 15 minutes ago, its good to discuss what a loose mode could mean. ;-) Kind regards, Job
On Friday, August 29, 2014, Randy Bush <randy@psg.com> wrote:
i am ENOTIME. when you have a simple spec i can follow, i would really look forward to it.
Thanks for summing up in a few words how most of us outside your ivory tower feel about RPKI. Now if you'll excuse me, I'm a grown-up with real work to do. Drive slow, Paul
On (2014-08-29 18:39 +0900), Randy Bush wrote:
clearly i am missing something. got a write-up?
Job got to it, but shortly: Loose mode RPKI: - verified or unknown less-specific route is preferable to failing more-specific The main goal is always to have all routes, never to blackhole, prefering bad route over no route. -- ++ytti
On (2014-08-29 14:37 +0300), Saku Ytti wrote:
clearly i am missing something. got a write-up?
Loose mode RPKI: - verified or unknown less-specific route is preferable to failing more-specific
Or said otherwise when choosing route from Adj-RIBs-In to Loc-RIB longest match is not done to whole population, population is first divided to 'verified', 'unknown' and 'failed' routes, and longest match is done for each sub-population in order, until match is found. -- ++ytti
On 8/28/14, 11:28 PM, "Mark Andrews" <marka@isc.org> wrote:
The long term solution is to deploy RPKI and only use transits which use RPKI. No RPKI support => no business. Additionally make RPKI a peering requirement.
WG] So should we ask for that before, or after we get everyone to roll out IPv6 everywhere by voting with our wallets? *ducks* On 8/28/14, 11:24 PM, "Fred Baker (fred)" <fred@cisco.com> wrote:
Are providers that neighbor with them implementing RPKI? If not, complain to the folks not indicating RPKI and therefore accepting a hijacked prefix.
WG] %s/RPKI/inbound route filtering on downstream customers/g There, FTFY Tarun, other than directly contacting the originator, I recommend that you complain to their upstream provider(s) (the neighboring ASN(s) in the AS-Path) that they are accepting routes from their customer that they shouldn't be, include proof that you own the block they are announcing, and ask them to apply a prefix filter. Yes, this presupposes that you can find valid contact info in whois or peeringdb, but it's the best we've got right now. RPKI isn't likely to fix this anytime soon, because it's mostly not deployed where it needs to be to affect this problem. And just like inbound route filtering and lots of other protective security measures, [1, 2] and eating your vegetables, and getting more exercise, most folks agree that it would help, but it's only useful with wide deployment, which mostly needs to happen on "everyone else's network", and those things all have an additional cost (time, money, or both) to deploy and maintain. The unfortunate thing is that RPKI arguably takes more work than the others, with a much longer time-horizon to see benefit during the incremental deployment period. Wes George [1] https://www.routingmanifesto.org/manifesto/ [2] http://tools.ietf.org/html/draft-ietf-opsec-bgp-security Anything below this line has been added by my company’s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
The long term solution is to deploy RPKI and only use transits which use RPKI. No RPKI support => no business. Additionally make RPKI a peering requirement. WG] So should we ask for that before, or after we get everyone to roll out IPv6 everywhere by voting with our wallets?
considering that measured rpki registration (which has a very tragic side) is ten time ipv6 penetration, i think we ask for rpki first. but keep shoveling. it's a good week for twt. randy
On 8/29/14, 9:08 AM, "Randy Bush" <randy@psg.com> wrote:
considering that measured rpki registration (which has a very tragic side) is ten time ipv6 penetration, i think we ask for rpki first.
WG] I guess I should know better than to ask rhetorical questions on NANOG, lest I get an answer. The horse race to determine the fastest lame horse is a rather boring one to watch, but unless you're counting how many ASNs have IPv6 allocations (whether they're using them or not) as a measure of IPv6 penetration, counting RPKI registrations as penetration doesn't lead to a useful comparison. Number of ASNs doing *validation* and discarding invalid routes (especially among top transit N ASNs by reach) would be far more telling as a measure of penetration, since it directly impacts RPKI's relative effectiveness at preventing hijacks such as the original poster was experiencing.
but keep shoveling. it's a good week for twt.
WG] Randy, if you're going to try to poke me in the eye about an outage in lieu of a snappy comeback, the least you could do is get my company's name right. ;-) It'll be in the stupidly long disclaimer at the bottom of this message for future reference, but it's in the first sentence, so you don't even have to read the whole thing. Wes This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
See "whois -r AS43239". The long term solution is to deploy RPKI and only use transits which use RPKI. No RPKI support => no business. Additionally make RPKI a peering requirement. Mark In message <CAAjbWEr_o+yQY1T72JMvJ_Nw2Eu2L7=TzZ0dc33mhodo5JB=yw@mail.gmail.com> , Tarun Dua writes:
AS Number 43239 AS Name SPETSENERGO-AS SpetsEnergo Ltd.
Has started hijacking our IPv4 prefix, while this prefix was NOT in production, it worries us that it was this easy for someone to hijack it.
http://bgp.he.net/AS43239#_prefixes
103.20.212.0/22 <- This belongs to us.
103.238.232.0/22 KNS Techno Integrators Pvt. Ltd. 193.43.33.0/24 hydrocontrol S.C.R.L. 193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline
Where do we complain to get this fixed.
-Tarun AS132420 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
I look forward to the ARIN fee schedule for legacy IPv4 holder RPKI registrations. Matthew Kaufman (Sent from my iPhone)
On Aug 28, 2014, at 8:28 PM, Mark Andrews <marka@isc.org> wrote:
See "whois -r AS43239".
The long term solution is to deploy RPKI and only use transits which use RPKI. No RPKI support => no business. Additionally make RPKI a peering requirement.
Mark
In message <CAAjbWEr_o+yQY1T72JMvJ_Nw2Eu2L7=TzZ0dc33mhodo5JB=yw@mail.gmail.com> , Tarun Dua writes:
AS Number 43239 AS Name SPETSENERGO-AS SpetsEnergo Ltd.
Has started hijacking our IPv4 prefix, while this prefix was NOT in production, it worries us that it was this easy for someone to hijack it.
http://bgp.he.net/AS43239#_prefixes
103.20.212.0/22 <- This belongs to us.
103.238.232.0/22 KNS Techno Integrators Pvt. Ltd. 193.43.33.0/24 hydrocontrol S.C.R.L. 193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline
Where do we complain to get this fixed.
-Tarun AS132420 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Fri, Aug 29, 2014 at 06:39:07PM -0400, Robert E. Seastrom wrote:
Matthew Kaufman <matthew@matthew.at> writes:
I look forward to the ARIN fee schedule for legacy IPv4 holder RPKI registrations.
I'd assume that it would be included in your annual LRSA maintenance fees.
Make sure you have counsel review the RPA if you are looking at RPKI vs reading it yourself. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
You're funny. What percentage of legacy holders have or will sign the LRSA do you suppose? Matthew Kaufman (Sent from my iPhone)
On Aug 29, 2014, at 3:39 PM, Rob Seastrom <rs@seastrom.com> wrote:
Matthew Kaufman <matthew@matthew.at> writes:
I look forward to the ARIN fee schedule for legacy IPv4 holder RPKI registrations.
I'd assume that it would be included in your annual LRSA maintenance fees.
-r
participants (16)
-
Faisal Imtiaz -
Fred Baker (fred) -
George, Wes -
Jared Mauch -
Job Snijders -
Karsten Thomann -
Mark Andrews -
Matthew Kaufman -
Nick Hilliard -
Paul WALL -
Randy Bush -
Rob Seastrom -
Saku Ytti -
Sandra Murphy -
Suresh Ramasubramanian -
Tarun Dua