RPKI, or Resource Public Key Infrastructure, is a way to cryptographically produce and sign messages that bind a particular IP prefix with an originating Autonomous System. It essentially contains the information “192.0.2.0/24 up to /24 can originate in BGP from AS64500”. Or, “2001:db8::/32 up to /48 can originate in BGP from AS64500”.
These messages, after they are signed by the rightful owner of 192.0.2.0/24 or 2001:db8::/32, can be made available to anyone, so network operators can protect against accidents, such as a typo, causing traffic to be sent to the wrong destination, or against malicious attacks, with the purpose of hijacking IP prefixes using BGP, to monitor or change traffic.
Operators need to monitor the announcements they receive from BGP, and compare them against this list of signed messages. This comparison can yield three possible outcomes. The first is valid. That is, the announcement received over BGP matches an RPKI “ROA” (or message). It can also be invalid, which means that there is a mismatch, i.e. the owner of the IP Space did not authorize this ASN to announce this route. The final state is unknown, which means that there is no ROA message for this specific IP prefix, or, simply, that it is an ARIN prefix.
After an announcement has been categorized into one of the above three buckets, it should be kept (valid / unknown) or discarded (invalid). Some operators may choose to prefer a valid announcement path more than an unknown one.
So why are there three states, instead of two? Why do we have three possible answers in a yes or no question? What is this unknown?
As I mentioned before, an IP prefix owner has to actively publish a ROA. They have to specify which IP prefix can originate from which ASN, sign this message, and publish it. So yeah.. Not everyone does this. Some operators haven’t heard of RPKI, some don’t fully understand it, some don’t want to do it, some find the process of publishing the ROAs difficult, … It doesn’t matter, as long as there’s no ROA by the owner, this prefix cannot be protected by RPKI.
So with all that in mind, let’s start by having a look at the state of RPKI deployment in Greece. This blog post will only cover the deployment of ROAs, and not the validation done by the networks.
First, it’s the ISPs.
Undoubtedly, the largest one is OTE. OTE operates under many ASNs, so we will examine them one by one.
This is the main ASN of OTE, with over 1.8M IPv4 addresses and a /29 of IPv6 addresses. In total there are 104 prefixes announced, of which all IPv6 ones are signed and valid, and from the IPv4 ones, all but a handful do not have a ROA, and those that don’t, do not belong to OTE, but to customers, such as FRAPort, and AB VASSILOPOULOS. Overall, pretty good here!
This ASN belongs to OTEGlobe, which is technically a different company, that provides IP services mostly. It has about 4,000 IPv4 addresses and a few IPv6 subnets, over 23 announcements. Here the situation is also good, with all prefixes covered by ROAs, which are valid.
This ASN is the Cosmote network, mainly used for mobile communications, such as 4G, etc. They have about 377,000 IPv4 addresses, and a /29 as well. Like before, the entire address space is covered by valid ROAs.
The next ISP is Vodafone, which is also an ISP and a mobile service provider. They are using AS3329, with a total of about 760,000 IPv4 addresses, and again, a /29. Isn’t IPv6 just so much easier? :-) They originate a total of about 120 prefixes. Out of these, none are protected by RPKI, and all are marked unknown, since Vodafone has not published any ROAs for their prefixes. So things are bad here..
Now CYTA is a special kind of ISP. CYTA is from Cyprus, but also has a CYTA Hellas company, which operated in Greece. The CYTA Hellas part was acquired recently by Vodafone, above, but they always operated under the same ASN with the Cyprus part, so differentiating between them is a bit tricky, and can only be done reliably by the amount of prefixes that now have “Vodafone” as their description.. So AS6866 has a total of 770,000 IPv4 addresses, and, again, a /29. Assessing the RPKI deployment situation here is a bit trickier, as they have ROAs deployed, but also announce more specifics, that are not covered by their ROAs.
Quick break here to explain what this all means. When a ROA message is published, it can contain the info 2001:db8::/32 up to /48 for AS64500. That means 2001:db8:50::/48 is also covered. However, a ROA can also be 2001:db8::/32 up to /32 for AS64500. This only covers 2001:db8::/32 and not 2001:db8:50::/48, even though it is included in the /32.
CYTA could extend their up to to include more specifics, but they didn’t. For this reason, they have a valid ROA for an advertisement, and an invalid for a more specific. They also have the same problem with IRRDB route and route6 objects, but there isn’t really a problem there. It is not clear to me why they have this behavior. Maybe it’s a weird way of traffic engineering, between networks with RPKI validation, and networks without it.. :-)
Overall, about half their IP space has ROAs, and the other half has no ROAs. On the half that has, there are tons of invalids, but they have a less specific prefix which is valid at all times, so, in a way, they are protected by RPKI.
Wind is another ISP that also serves as a mobile service provider. They operate AS25472 and AS15617. Like OTE, they will be analyzed separately.
This is the main ASN, with about 340,000 IPv4 addresses, and a /32 of IPv6 addresses. They advertise 32 prefixes. All but two of their IP prefixes are covered by ROAs and are valid. One prefix belongs to a customer, so it is probably not under their control, and the other is theirs, but for some reason not covered. Overall, pretty good, but why not add that last prefix there, Wind? :-)
This is another ASN by Wind, with about 32,000 IPv4 addresses, and no IPv6 :-( :-(. It originates 17 prefixes. In this ASN, nothing is protected by RPKI, as there are no published ROAs for any of the prefixes.
HCN is a FTTH ISP that operates in Thessaloniki, Greece’s second largest city. They use AS57794, and have about 14,000 IPv4 addresses, and no IPv6.. :-( They advertise their IP space using 27 announcements. None are covered by ROAs, and therefore HCN is not protected against hijacks by RPKI.
inalan is a FTTH ISP that started in Athens and recently expanded to Thessaloniki as well. Under AS200736 they have about 4,900 IPv4 addresses, and, like their competitor, HCN, no IPv6. None of their 21 prefixes is covered by ROAs, and most of them do not even have valid IRRDB route objects.
Finally, we have Forthnet, another Greek ISP. It is a spin-off of FoRTH, an academic institution and research center. They operate under AS1241, and have about 612,000 IPv4 addresses, and, again, a /29. They originate a total of 85 prefixes. All their IPv4 prefixes are covered by ROAs, except all large customer ones, which is a common pattern. In IPv6, all of their announcements are covered. So a pretty good result here as well.
Now it’s time to have a look at the Greek NREN, GRNET, as well as its customers, which are education, research, health, and culture institutions.
GRNET operates under AS5408, and has almost quarter million IPv4 addresses, and, like almost everyone else, a /29. In the legacy IP version, it carries 22 prefixes of their own, and 38 of its customers. In the IPv6 world, everything is within the /29, except SNFCC.
All of GRNET’s prefixes are covered by ROAs, but all but one prefix advertised by AS5408 that belong to customers, are not. SNFCC has no ROAs, but FoRTH has. FoRTH happens to be the .gr DNS zone operator, so it has some special treatment. Most GRNET customers have signed and published ROAs, with the exception of NCSR Demokritos, and the National Technical University of Athens (NTUA). However, a large number of customers utilize GRNET IP Space, so they are protected.
Content Providers in Greece are in a shortage, unfortunately, as most of the content, including 100% Greek targeted content, is out of the country. However, of the few that remain in the country, here’s the current status..
Skroutz is the largest price aggregator in Greece. They operate from AS202042, and have 1,200 legacy IP addresses, and a /32 of IPs. They have not published ROAs for any of their IP space, and one of their IPv4 prefixes even has an invalid route object, as it belongs to Cogent.
Top.Host is a hosting company, and are behind AS199246. They have 2,048 IPv4 addresses, and a /29 of IPv6. All their prefixes are covered by ROAs and therefore protected by RPKI.
Another hosting website, and the company behind AS50520, Hostmein owns 1,024 IPv4 addresses, and a /32 worth of IPv6, none of which are covered by ROAs.
Interworks is a Cloud company in Thessaloniki, that operates AS50919. Out of their over 5,000 IPv4 addresses, none are covered by ROAs, and for one of their /22s I was not able to even find a route object.
DNHOST runs off of AS200128, with a /22 of IPv4 and a /32 of IPv6. No ROA has been published.
Finally, IpHost, another hosting company with Greek presence, owns and runs AS47521. They have almost 6,000 IPv4 addresses, and a /29 of IPv6. They do not have ROAs published for any of their prefixes.
There are also a few datacenters in Greece, some neutral and some non-neutral, but no matter what, all of them sell IP Transit. They operate their own networks, with a mix of GR-IX, Tier 1 (Cogent), and maybe some local providers as well. Let’s see though how well they fare in terms of RPKI readiness..
Lamda Hellix, the datacenter behind AS56910 and almost 4,000 IPv4 addresses, as well as a /29 of IPv6 space has ROAs deployed for all their prefixes, but for none of their customer IP space that is announced by their ASN.
With two datacenters in Athens and Thessaloniki, Synapsecom, or AS8280, advertises over 8,000 IPv4 addresses, and a /29 worth of IPv6. All their IP space, and all their customer IP space is covered by published ROAs, with the exception of one of their customers.
Lancom, another multi-city datacenter provider, which is more focused on cloud solutions however, operates through AS199081, AS60911, and AS207034. Overall, it announces about 14,000 IPv4 addresses, as well as a /32 of IPv6 space. All of their prefixes are covered by ROAs, with the exception, like others before them, of the customer prefixes, which have no ROAs.
TIS has two datacenters in Athens and uses AS198477 for their operations in Greece. They have about 3,500 IPv4 prefixes and a /32 of IPv6. Like many other companies, all their prefixes are covered by ROAs, with the exception of customer prefixes announced by their ASN.
A lot of banks operate their own ASNs in Greece, so it is worth looking whether these networks that require the protection RPKI provides make use of it, or not.
This is not a commercial bank, but is included in the list due to its importance, and, of course, its name, which contains the word “Bank”. They have AS41125, with only 512 IPv4 addresses, none of which are protected by RPKI.
This is a commercial bank, which is customer facing. They operate behind AS6674. Although a different entity, I am also including their Securities department ASN, which is AS15853. They also have 512 IPv4 addresses, and as a common pattern in banks, no IPv6. None of their IP Space is protected by RPKI.
Alpha Bank uses AS9128, and has 512 IPv4 addresses only as well. Again, no IPv6. They have a single IP prefix, which is not covered by any ROA.
A smaller bank than the others in the list, Attica Bank operates AS41579. However, they have over 2,000 IPv4 addresses, and, again, no IPv6. As a pattern here, they have no ROAs published, and therefore are not protected against hijacks by RPKI.
A very popular Greek bank, Piraeus has multiple ASNs, likely from the many banks it has acquired over the years. They have AS28953, AS44036, and AS42680. They add up to 1,024 IPv4 addresses, and again, they are legacy only. Like every other bank, they have no ROAs whatsoever, so that’s also a fail for this study.
Don’t expect much change here either.. Eurobank has AS15439 and AS39062, with 2,500 IPv4 addresses, and of course no IPv6. Like IPv6, they also lack ROAs, so they too are vulnerable to attacks RPKI can prevent with 2 minutes of work.
The Pancreta Cooperative Bank, or PCB for short, uses AS202506 for Internet connectivity. They only have legacy IP, and not IP, but, unlike any other bank in this list, they have ROAs!!
Finally we have some networks that don’t really belong to any of the above categories, so I will freely mention them here, for sake of completion.
With their own AS, AS201374, and 256 IPv4 addresses, the Hellenic Parliament has ROAs published, covering their /24.
The nation’s largest (and until recently only) airline, Aegean is the owner of AS51537. They have a /24, which is not covered by ROAs.
The Eleftherios Venizelos Airport of Athens (ATH) is the only Greek airport with its own ASN. They have AS199370, and they announce their /22 as four /24s (please don’t do that, aggregate your routes). All four of them have valid ROAs making the airport protected by RPKI.
The VoIP company Modulus has AS201494, and a /22 and a /29 of legacy and modern IP respectively. Both prefixes are covered by valid ROAs.
OPAP is the largest Greek gambling company, starting from football, and expanding to anything you can imagine. They have AS201293, which announces a /22, the same /22 in /24s (why?), and a /32 of IPv6 space. All their prefixes are covered by valid ROAs.
Attiki Odos is the company that made a road in Athens called “Attiki Odos”.. :-P They are also the owners of AS48380, with a /24 of IPv4, which is not covered by any ROAs.
DIAS, or Interbanking Systems, is a company that handles how money is transferred between the Greek banks locally. They have AS29241, with 256 IPv4 addresses, not protected by RPKI.
The national land register, is a company owned by the Government, and has AS50501. They have 256 IPv4 addresses, and this prefix is not covered by a ROA.
Information Society is another Government company, that operates the Syzefxis network. This network provides connectivity to national agencies and services, like the tax offices, the municipalities, etc. They have AS35506, and almost 13,000 IPv4 addresses. Unfortunately they don’t have any IPv6.. All of their announcements are covered by valid ROAs.
RPKI is a relatively new technology, which was originally introduced in 2012. It cannot be a solution that will address any and all problems of BGP misrouting on the Internet, be it accidents or attacks, but it is a very good first step, with more to come. It may be complicated, or not supported at all, to deploy validation in your network, which is understandable. However, there are other ways you can help secure the Internet as a network operator. As Job Snijders said, if all Internet Exchanges, and a handful of networks across the globe do validation, it will be enough to stop most, if not all, hijacks. But in order for these few entities to be able to perform validation, the number of unknowns must be zero. And this is something every network operator can help. By publishing ROAs for all your IP prefixes, v4, and v6, you help these few people do validation, and you also protect your networks from most types of attacks.
So login to your RIR portal, be it RIPE, APNIC, or anything else, and start publishing ROAs. In RIPE it takes two minutes, and you don’t need to type any information. It automatically collects everything from BGP, and you just need to confirm it.
Now if you can do RPKI validation, even better. You may want to not start rejecting invalids from the beginning, to see if everything works, but after you troubleshoot a bit and play around and feel comfortable, start discarding these routes. Keep in mind, however, that if you have a default route, it negates the effects of discarding prefixes.
You may be concerned that by rejecting some routes, you can reach “less of the Internet”. This isn’t true. If it’s something like the example of CYTA above, you lose nothing. You can’t access the /20, but you still have the valid route to the /16. Connectivity is the same. And in case something bad happens, you actually have “more of the Internet”. If you see an invalid announcement for a /24 of a /22, by sending the traffic to the attacker, you lose connectivity, you don’t gain more..
Finally, since validation requires a server, don’t worry. In the worst case that this server goes down, all the prefixes will be unknown, and not invalid, you will just lose validation, and not connectivity, until the service is back up.