21 Feb

Indian RPKI ROA status

In Melbourne for the week for APRICOT 2020. Someone jokingly said it’s should be “APRICOT and RPKI 2020”. 🙂

It seems like both JPNIC and TWNIC are doing a good job at promoting their member operators in Japan & Taiwan for signing ROA. I thought to check for the status in India to find how India is doing.

RPKI ROA status for India










  1. Total prefixes: 40,834 (IPv4 + IPv6)
  2. Prefixes with valid ROA: 4693
  3. Prefixes with invalid ROA: 354
  4. Prefixes without ROA: 35,787

IRR route objects

  1. Prefixes with at least one valid IRR route object: 38,075
  2. Prefixes with invalid route object: 2213
  3. Prefixes with missing route object: 546

The method used to pull this data

  1. Download APNIC extended data: https://ftp.apnic.net/stats/apnic/delegated-apnic-extended-20200221
  2. Find IN ASNs which is APNIC assigned as well as IRINN delegated prefixes.
  3. Find all prefixes originated by these ASNs (assuming a large of them would be used in India only).
  4. Check for IRR and RPKI status for those prefixes.
06 Feb

Alternate to IRINN IRR manual entry / ALTDB

IRINN (Indian Registry for Internet Names and Numbers) is a NIR (National Internet Registry) for India operating under the APNIC RIR (Regional Internet Registry). IRINN is run and managed by NIXI. It’s a decent NIR and was set up in 2012. Indian organisations have the option to either maintain relation with APNIC or with IRINN.

A large number of small networks prefer IRINN because it’s annual charges are 25000 INR / $351 USD against APNIC’s membership fee which is over 2x of that.

There are a couple of key disadvantages of using IRINN:

  1. The membership portal is rather limited and the entire process of creating, updating route objects as well as AS SETs via IRINN is rather a manual process. One raises a ticket and during working days IRINN processes those requests & updates the IRR entries. In backend entries just go in the APNIC’s IRR.
  2. Process of creating/updating/maintaining RPKI ROAs is also rather manual.

As of now there’s not much one can do about #2 other than just following manual process by opening a ticket with IRINN but for #1 if you have a challenge that it’s rather slow to update/change because it is a manual process.

Introduction to IRR’s

IRR or Internet Routing Registry is just the public register for BGP related activities. Logic is that one first publishes what one wants to do and then does it. So I can say I want to originate 2402:b580::/32 from AS58901, publish it one of the publicly visible registers (known as IRRs) and then I actually announce the pool.

So who can run an IRR?

Anyone can! IRRd software is open source and one can use it to set up an IRR server. The old and most widely used IRRd is available here and the new version of IRRd (IRRd version 4) is here which is quite advanced, offers many excellent features. What makes IRRs run by APNIC, ARIN, RIPE, RADB etc popular is the fact that RADB mirrors them all and a large number of tools default to RADB for generating the filtering config. As per data available here, RADB mirrors 23 other IRRs besides serving from its own database. So one can get entry to either of these available IRRs based on relation one has with them for creating the route objects or AS SETs and it just works.

ALTDB

Many people know of RADB which is run by merit. It’s a paid option and many networks use that for maintaining route objects. There’s also a free IRR called ATLDB. It’s free to create an account on it and approval of account is a manual process but once approved, creation/updation of route objects as well as AS SETs is all automated and works via email with a specific syntax. Unfortunately, there’s not much on the ALTDB website except a whois lookup tool, however, if you want to read in detail about IRR as well as using ALTDB, the Fremont Cabal Internet Exchange has an excellent guide on that (here).

The basic logic here is to do following: Create a maintainer object > Define routing policy of the ASN (peers, transit, downstream etc) > Create AS SET (if you have BGP downstream customers) > Create route objects for your IPv4 and IPv6 prefixes > Publish your ASSET on PeeringDB. Again one can follow the detailed steps given on the FCIX website.

Here’s an example of it in action for a test prefix of the pool I use:
2402:b580::/32

As of now, there’s no corresponding route object with it. Here’s a quick check on RADB:

anurag@devops01 ~> whois -h whois.radb.net 2402:b580::/32
%  No entries found for the selected source(s).
anurag@devops01 ~>

As of now, there’s no route object for it. Let’s say I want to start originating from AS58901, so I will put following in a plain text mail and send it to ALTDB email ID (auto-dbm@altdb.net) which processes these requests automatically.

route6:     2402:b580::/32
descr:      Anurag Bhatia R&D Network IPv6 Pool
origin:     AS58901
mnt-by:     MAINT-AS58901
changed:    me@anuragbhatia.com 20200205
source:     ALTDB

It’s important to send email in cleartext. One can check how to do that in a specific email client or web interface one uses. For Gmail the option is here:

I get following in reply from ALTDB:

And now query to RADB gives us:

anurag@devops01 ~> whois -h whois.radb.net 2402:b580::/32
route6:     2402:b580::/32
descr:      Anurag Bhatia R&D Pool
origin:     AS58901
mnt-by:     MAINT-AS58901
changed:    me@anuragbhatia.com 20200205
source:     ALTDB
anurag@devops01 ~>

And here goes the example of creating AS SET: AS-ANURAG. I sent following to the ATLDB:

as-set:     AS-ANURAG
descr:      Anurag Bhatia's AS SET
members:    AS58901
mnt-by:     MAINT-AS58901
changed:    me@anuragbhatia.com 20200205
source:     ALTDB

Upon confirmation, I get when I query RADB:

anurag@devops01 ~> whois -h whois.radb.net AS-ANURAG
as-set:     AS-ANURAG
descr:      Anurag Bhatia's AS SET
members:    AS58901
mnt-by:     MAINT-AS58901
changed:    me@anuragbhatia.com 20200205
source:     ALTDB
anurag@devops01 ~>

Remember if you happen to use ALTDB, make sure to ask IRINN to delete your route objects after you have successfully created them on ALTDB. Duplicate entries just add to the junk in IRR.

Further reading

  1. My detailed presentation on IRR last year at Singapore NOG: Let’s talk about the routing security
  2. Automated configuration of BGP on edge routers by University of Amsterdam
26 Apr

IRINN | APNIC inetnum range confusion

Last week I saw an interesting post at APNIC mailing list about IRINN (recently formed NIR in Indian region). 

 

Poster Jimmy was concerned about IRINN’s netname

inetnum: 0.0.0.0 – 255.255.255.255
netname: IRINN-BROADCAST-ADDRESSES
descr: Broadcast addresses
descr: These addresses cannot (should not) be routed on the Internet.
country: IN
admin-c: IH1-IN
tech-c: IH1-IN
status: ALLOCATED PORTABLE
remarks: send spam and abuse report to info@irinn.in
mnt-by: IRINN-HM
mnt-irt: IRT-IRINNHM-IN
mnt-lower: IRINN-HM
changed: hostmaster2@irinn.in 20130420
source: IRINN

 

As per first two lines entire IPv4 address space i.e 0.0.0.0/0 (ranging from 0.0.0.0 to 255.255.255.255) was put as IRINN-Broadcast while expected was IANA broadcast (since IANA sits on top in this RIR & NIR hierarchy).

Right after that post IRINN came into action and changed values to:

inetnum: 255.0.0.0 – 255.255.255.255
netname: IANA-BROADCAST-ADDRESSES
descr: Broadcast addresses
descr: These addresses cannot (should not) be routed on the Internet.
descr: http://www.apnic.net/db/RIRs.html
country: US
admin-c: HM20-AP
tech-c: NO4-AP
remarks: This is a placeholder object to ensure no objects are created
remarks: in the enclosing range.
mnt-by: MAINT-APNIC-AP
mnt-lower: MAINT-APNIC-AP
changed: apnic-dbm@apnic.net 19991214
changed: hm-changed@apnic.net 20040926
status: ALLOCATED PORTABLE
source: APNIC

 

This had correct netname suggesting IANA but source is APNIC and moreover it got a really interesting inetnum i.e 255.0.0.0 to 255.255.255.255. This really sounded bit weird to me as I was expecting entire IPv4 address range here and start from 255.0.0.0 rather then from 0.0.0.0 sounds confusing. 

 

I did some testing and saw results from whois db were different based on query. I was getting range from 255.0.0.0 to 255.255.255.255 if I query APNIC db for 0.0.0.0/0 while for 0.0.0.0 (without /0) I was getting expected range 0.0.0.0 to 255.255.255.255. I posted about this in APNIC mailing list to figure out reason for these strange numbers.

I got a really interesting reply from Leo Vegoda from ICANN:

I agree that it seems quite odd. 255/8 is part of 240/4. In 240/4 the only address whose use has been defined is 255.255.255.255, which is used for limited broadcast. The rest of 255/8 does not (yet) have a defined use. You can find the details here: http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml

Regards, Leo

Right after his reply, Guangliang from APNIC posted clarification and actually fix too. 🙂

Thanks to Anurag for pointing out this and Leo for your clarifications. The inetnum object 255.0.0.0 – 255.255.255.255 was created in 1999 to reflect that Broadcast reservation. We have now removed it from the APNIC whois database to avoid any confusion.

Best regards,

Guangliang

 

So yet another interesting case from internet world. Time for me to get back to work, have a good time ahead! 🙂