Imagine this scenario: You are a computer network engineer and operate an IP network for an ISP. A new business customer has signed up today and requests you to allow transit for his IP prefix. What do you do?
As it’s a business customer you could simply add a new eBGP peer on the edge router and accept the prefix that the customer is originating. But, there is an element of risk involved here, for example, the customer mistypes the prefix or has hijacked the prefix and you are allowing the transit. I’m sure you’ve heard about the well-known YouTube incident!
Being good Internet citizens we should verify any transits to any IP prefix, or conduct a Legitimacy of Address (LoA) check. As outlined in my earlier blog post, there are four situations where you may need to do a LoA check.
Option 1
Option one does not require any LoA check. The customer prefix is a subnet (that is, 3fff:ffff:dcdc::/48) of the ISP’s own prefix (that is, 3fff:ffff::/32). Other filtering requirements should be in place as outlined in the diagram.
Option 2
As explained in the diagram, the customer is a single home so no BGP routing is required. The customer prefix (that is, 2001:0DB8::/32) would be originated by the ISP’s AS number (in this case AS17821). This option requires a LoA check as the customer is using a portable prefix allocated by the Internet registry, that is, APNIC. This can be a manual or an automated LoA check.
Depending on the scale of the network there are two types of LoA checks:
- Manual LoA Check. This involve doing a whois search on the customer’s IP address from the Internet registry’s whois database. Find the admin-c / tech-c contact e-mail address from the database search and email them for verification. This option is applicable for a small scale network deployment. It requires a significant amount of time during the validation process.
- Automated LoA Check. This does not require any manual validation checks as the router’s filtering configuration will be updated automatically by fetching the routing policy (that is, the IP prefix that will be originated by the AS number etc) from a published and validated database. Again there are two types of automated processes for the LoA check:
- Internet Routing Registry (IRR). This is an older way of publishing validated routing policies using the RPSL syntax to a number of interconnected IRR databases (that is, APNIC, RADB etc). Then, using an automated programming script grabbing those policies, builds product specific filtering configurations and uploads it to the router. This is why some large ISPs ask their customers to add route objects to an IRR database as then the prefixes are allowed automatically.
- Resource Public Key Infrastructure (RPKI) is a new technology to digitally sign an IP prefix originating from an AS number and publish it to a database. Routers can then talk to the database cache directly and allow transits to those valid prefixes. This to me is great!
Option 3
Even though the customer is multihomed, the customer’s prefix (that is, 3fff:ffff:dcdc::/48) is a subnet of their upstream ISP’s prefix (that is 3fff:ffff::/32). The upstream that has provided the IP prefix (in this case AS17821) does not need to do a LoA check. But the other upstream ISP (in this case AS131107) must do a LoA check, either manually or in an automated way, depending on the scale.
Option 4
Option 4 is the most widely used deployment for current network requirements. The customer is multihomed, has its own IP and AS number, will do their own BGP routing, and the upstream ISP will allow transit for their IP prefix. Both upstream ISPs will need to do a LoA check. They can ask their customers to create their route object (if using IRR) or ROA’s (if using RPKI). Please look at the diagram for other filtering requirements. These small diagrams contain plenty of information.
I hope this information will be useful in understanding how to plan and help secure global routing infrastructure. I’m happy to answer any comments you may have.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Thanks for valuable article.
Some general questions which I am sure are easy.
1) In general if one can establish that an AS is advertising a prefix in the wild via route views is this “good-enough” for some people to allow the downstream to announce through them?? Can this be used in Lieu of an LOA?
2) In general I have always understood that a prefix “re-assigned” to an organization does not automatically mean they should be allowed to advertise that prefix back to any other upstream outside the direct party who was allocated the prefix. Ie: if I am a customer of AT&T and they reassign me a /24 and I want to go to ISP B and annouce to them.. ISP B should do the checks regardless of it “being reassigned” ..etc
Thanks for your question.
Ans1. RIR maintain the firsthand information of IP & AS distribution. LoA check is to verify that with the RIR record at the operational level. Route view information is not an official record of IP and AS allocation hence is not a replacement of LoA check. It is an useful tool for the operator though.
Ans2. Yes, correct.
What I have to do in Option 3 scenario where I am ISP with AS17621 to delegate few class C address to be originated from Customer AS so he can able run multi homing