All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
IP hijacking - is ROA the answer ?
as a follow-up to the ipsystems topic
this story has been about for a while. it's a poor state that ARIN, peers, and others with influence and control over routing, didn't jump on this earlier.
ipsystems aren't the only one with reports of IP hijacking. these days with plenty of methods of authentication, encryption, and validation, why is it even possible to hijack IP blocks ?
A question for all those there who manage their own ASN, and don't use ROA. Is there a technical problem with ROA ? Is it because it's optional? what's the answer to preventing ANY hijacking ?
A ROA is a cryptographically signed object that states which Autonomous System (AS) is authorized to originate a particular prefix or set of prefixes
do peers ignore it and peer without a valid ROA ?
Comments
@William usually knows his stuff on this.
Preventive measures? Not really but you can fix IP hijacking. Send your passports to ISPs who bother and then tell them to stop announcing the IPs that were hijacked from you.
Legitimate companies check their peers' ROA and requires a LOA to be submitted for every prefix announcement. By right, most companies are prefix filtered, with exception to some companies that are monopoly or are pretty old. Also, most companies implement prefix filtering.
ROA is a two sided sword - Currently there is no real implementation to verify it directly on even modern routers (Like Junipers MX or Ciscos Nexus series) - You'd need your own scripts for that and interface it with your customers prefix lists.
ROA is also, currently, only available on limited IP space - No ROA on Legacy (except in RIPE, but then you need to be RIPE member (=€€€) which you usually don't need to be as legacy owner), very limited ROA on AFRINIC (new PA only) and no ROA for PI on LACNIC, APNIC and AFRINIC. Not sure about ARIN direct allocations. In general ROA is only available if you have your login to the RIRs management portal, which PI/Direct Alloc customers of a LIR won't have (RIPE has now a workaround for this by ORG but iirc no other RIR).
It is also a solution to a problem that is simple to fix - Your customer should never have an unfiltered session, it should be limited to his prefixes. ROA can support his claim/LOA that he owns it but not much more. Route objects, as opposed to LOA, require MNT-BY (or MNT-ROUTES) on the IP space in question, so if the customer creates a route object with your AS for his network (check i.e. whois -h whois.ripe.net 2a05:dfc7:10::/48 - I own the /32, the customer has a /44, the network size itself is a /48 and the route object clearly shows that AS200753 is allowed to announce it, you can't manipulate that and it cancels out any need for written LOA) you can be next to 100% sure that the space is legit and not hijacked (else the guy would have the RIPE MNT-BY password/cert which would mean he owns it anyway, legit or not).
Further, LOA, ROA and Route object won't help you if the hijacker just simply hijacks the ROA signed ASN as well (either by spoofing path or by just using it) so you also need a peering (import/export) on the ASN - Check for example mine here: whois -h whois.ripe.net AS198412
With all 3: Import/Export on ASN - Route object on IP space + ASN - ROA for the IP space on ASN any carrier should be able to 100% securely tell that you control this IP space and are allowed to use it, a LOA is then not required anymore and just additional (useless) work.
I can understand that some IP blocks might become surplus to requirements, and owners squat on them until the market price is right. presumably that is why this opportunity for hijacking exists. ad possibly there's an undisclosed deal happening that allows it to continue.
is there a list of hijacked IPs ? or at least a list of unannounced blocks ?
Spamhaus maintains a list of hijacked IP addresses.
Reserved/unannounced IPs - http://infocellar.com/networks/ip/reserved-ip-addresses.htm
You could scan for assigned ranges and compare that list to a BGP table export, all RIRs iirc provide a list of assigned netblocks (except AFRINIC which is, for some strange reason, on the APNIC FTP).
The problem with hijacking of large netblocks is not always that the owners wait until they have value - Many just got so early in the game that the default, no questions asked, policy was to assign them a /16 (or even larger, policy was /8 (Class A) for carriers, /16 (Class
for DCs and /24 (Class C) for end users) - Often even by Internic before ARIN/RIRs existed (which after creation quickly changed policies along with classless design, but a /16 was until around 2000 still easy as shit to obtain by any RIR and still is easy at AFRINIC - i've seen VPN PROVIDERS with a /12 Afrinic space).
Now many of this companies only need a few /24s (i saw some calc at a RIPE meeting which said that the large legacy blocks are in median only 20% or so used) but they obviously will not return the unused space for many reasons:
1.: Because it has value, after all a /16 is worth at least 250kEUR (at ~4EUR/IP)
2.: Because they need more space in the future - Even if you only need a few /24s per year it makes sense to keep your /16+ as you won't get any new space easily
3.: They don't want to renumber or simply can't, as the RIRs which are empty (APNIC, RIPE, ARIN) will not give you like a /19 if you return a /16, so they simpley have no space options to renumber to without investing money to buy other legacy or non-legacy netblocks at possible higher price per IP than theirs sell for (smaller space is in general more expensive per IP)
needing just a /24 out of a /16 is fine, but these hijacked blocks presumably weren't being announced at all. weren't they unused at the time?
Just out of curiosity, a mid size ISP in Germany has some unusual IP announcements also.
http://bgp.he.net/AS12586#_prefixes
what's the takeup of this BGP Feed from Spamhaus? is it effective?
I'm struggling to understand your English.
I think you're trying to say that blocks need to be unused for them to be vulnerable to hijacking, which isn't true.
If a block already in use is hijacked, then it becomes an anycast sort of arrangement. Both are still in use and traffic from ISPs will be routed to whichever is closest etc.
See http://arstechnica.com/information-technology/2014/03/google-dns-briefly-hijacked-to-venezuela/
These are more or less "legit" - The Chilean IP space is our famous IP space hoarder host1plus (that sells their netblocks to VPN providers), the Afrinic space are other hoarders that took similar company names to large ones (like "orang" -> "Orange") so their justification is easier to believe, the /24 announces with other company names are most likely made up company names to justify more space (The larger netblocks are again owned by companies like Host1Plus's African "business")
It's not "legit" as what they do and violates RIR policies (AFRINIC space in RIPE region is not well liked at all) but it is not hijacked space.
I assumed that a block being announced "incorrectly" would have been corrected quickly, as that would cause disruption to the legitimate owner. I assumed the hijacked blocks were essentially abandoned
Not all - Most with a /16 and alike are not monitoring their prefixes by services like bgpmon (which is now prohibitively expensive)
Well, there is that. There is nothing physically preventing anybody hijacking a block in use though.
By the way, a similar topic but not exactly about hijacking: Why are so many autonomous systems announcing bogon IPv4 and IPv6 prefixes? Most of them are either unallocated or just completely wrong, like those IPv6 addresses within 0000::/8 or AS which are announcing RFC1918 IP space.
@NeoXiD improper filtering. We might announce a default route, for example, but that obviously would be announced to Customers who don't take up full feed and would be filtered to anyone else. Many just doesn't care as 'it works'.
Wrong configs mainly (like configuring their internal IP space as iBGP for redundancy reasons on multiple locations/routers and then forget to disable outbound route replication) - Though many never notice it as every upstream (even the ones that allow spoofing and/or unfiltered BGP sessions) filters it out on the edge connected to this AS. So realistically it is not really relevant.
Most you see on bgp.he.net as Bogons is only there because HE peers so widely (HE filters it of course as well and does not replicate it but they still log it for their bgp viewing tool) - There is likely much more of them but as it never crosses even the first upstream looking glasses and/or the BGP table do not show it.
poor BGP config? any examples?
HEs viewer is probably the most widely used:
http://bgp.he.net/report/bogons#_bogons
wrong bgp config would be something like that (if you meant that, but i doubt it):
https://paster.li/?4199c6f488108345#sQC2cG806r+x1f02Z78+35xl76Lbf2FNOjy70eedlJc=
You probably haven't seen that IPv4 and IPv6 in my previous posts were links, right?
yeah I missed them. thanks
So everyone should setup proper filtering.
Example: MikroTik
(created them yesterday, may contain mistakes or missing prefixes, no warranty)
You can also peer with the cymru bogon route server and install all bogon routes as blackhole.
You should also use communities to filter customer prefixes within your core.
You should never ever consider any service from Spamhaus. Using whatever form of blacklist from them will result in dropping connection to many legit networks.
There are some organizations which provide real lists of unauthorized announced prefixes but relying on them is going against the decentralized nature of the Internet and nothing can predict that the administrators of these lists won't at any time become roguish like spamhaus.
Yea, i would not use the Spamhaus DROP list either without manually checking each prefix - You'll never know how/when something went in there.
Team Cymru is not much better either.
Not always, if they hi-jack a larger allocation, you can announce it in multiple smaller subnets to get it routing properly for the time being.
I've seen some larger space hi-jacked (such as /16's) and the ISP will announce the larger allocation /24 by /24 (smallest you can push to global route tables) to get around it... while posting to NANOG, albeit understandably pissed.