CARDIGAN implements RPKI - Cleanliness of prefixes onWIX
Hi All, CARDIGAN has just finished implementing RPKI Origin Validation on its WIX peering connection. What this effectively does is finds out if ASs are permitted to announce the IP addresses that they are advertising to the exchange. CARDIGAN then makes a decision on wether to allow invalid announcements to be turned into OpenFlow rules. So I thought you'd all be interested in the state of the prefixes on the exchange. The following table has removed all the routes for which no RPKI information was found. This leaves two conditions: Lines which start with a "V" have a valid RPKI ROA. That means that the AS originating the prefix has been explicitly authorised by the IP resource owner to do so. Likes which start with an "I" have an RPKI ROA which is different to the route seen. This means that the AS originating the prefix has been explicitly disallowed from doing so by the IP resource owner. These are explicit authorisations as the IP Resource owner has had to go to an RPKI trust anchor (normally the RIRs) and request certification of the ASs allowed to originate the prefix (or subnet of the prefix). For most of us (who are APNIC members) this is as simple as logging into the MyAPNIC portal and creating an ROA. APNIC handles everything else for you. Anything that turns up as an "I" on this list, I'm going to be looking at pretty carefully before I prefer into the CARDIGAN network. Anyone with more questions about RPKI, how it works, what it means, how to get it going. Feel free to post/email me. Network Next Hop Metric LocPrf Weight Path V* 58.28.0.0/16 202.7.1.22 30 0 9439 17435 i V*> 202.7.1.22 30 0 9439 17435 i V* 103.10.233.0/24 202.7.0.190 30 0 9439 132003 i V*> 202.7.0.190 30 0 9439 132003 i V* 103.23.16.0/22 202.7.0.222 30 0 9439 132040 i V*> 202.7.0.221 30 0 9439 132040 i I* 103.23.16.0/24 202.7.0.222 10 0 9439 132040 i I*> 202.7.0.221 10 0 9439 132040 i I* 103.23.17.0/24 202.7.0.222 10 0 9439 132040 i I*> 202.7.0.221 10 0 9439 132040 i I* 103.23.18.0/23 202.7.0.222 10 0 9439 132040 i I*> 202.7.0.221 10 0 9439 132040 i V* 113.197.96.0/22 202.7.0.211 30 0 9439 45831 45831 i V*> 202.7.0.211 30 0 9439 45831 45831 i I* 113.197.96.0/28 202.7.0.211 10 0 9439 45831 i I*> 202.7.0.211 10 0 9439 45831 i I* 113.197.96.32/27 202.7.0.211 10 0 9439 45831 i I*> 202.7.0.211 10 0 9439 45831 i I* 113.197.96.96/28 202.7.0.211 10 0 9439 45831 i I*> 202.7.0.211 10 0 9439 45831 i I* 113.197.96.112/28 202.7.0.211 10 0 9439 45831 i I*> 202.7.0.211 10 0 9439 45831 i I* 113.197.96.168/29 202.7.0.211 10 0 9439 45831 i I*> 202.7.0.211 10 0 9439 45831 i I* 113.197.98.32/29 202.7.0.211 10 0 9439 45831 i I*> 202.7.0.211 10 0 9439 45831 i I* 113.197.98.64/27 202.7.0.211 10 0 9439 45831 i I*> 202.7.0.211 10 0 9439 45831 i I* 116.90.130.16/29 202.7.0.176 10 0 9439 38477 i I*> 202.7.0.176 10 0 9439 38477 i I* 116.90.130.96/29 202.7.0.176 10 0 9439 38477 i I*> 202.7.0.176 10 0 9439 38477 i I* 116.90.135.0/24 202.7.0.176 10 0 9439 38477 45641 i I*> 202.7.0.176 10 0 9439 38477 45641 i V* 116.90.139.0/24 202.7.0.176 30 0 9439 38477 i V*> 202.7.0.176 30 0 9439 38477 i I* 116.90.139.0/29 202.7.0.176 10 0 9439 38477 i I*> 202.7.0.176 10 0 9439 38477 i I* 116.90.139.8/29 202.7.0.176 10 0 9439 38477 i I*> 202.7.0.176 10 0 9439 38477 i I* 116.90.139.16/29 202.7.0.176 10 0 9439 38477 i I*> 202.7.0.176 10 0 9439 38477 i I* 116.90.139.24/29 202.7.0.176 10 0 9439 38477 i I*> 202.7.0.176 10 0 9439 38477 i I* 116.90.139.64/27 202.7.0.176 10 0 9439 38477 i I*> 202.7.0.176 10 0 9439 38477 i I* 116.90.139.144/29 202.7.0.176 10 0 9439 38477 i I*> 202.7.0.176 10 0 9439 38477 i V* 118.90.0.0/16 202.7.1.22 30 0 9439 17435 i V*> 202.7.1.22 30 0 9439 17435 i 202.7.0.76 20 0 9439 24006 i V* 182.154.0.0 202.7.1.22 30 0 9439 17435 i V*> 202.7.1.22 30 0 9439 17435 i 202.7.0.168 20 0 9439 i I* 198.48.0.0/23 202.7.0.222 10 0 9439 132040 i I*> 202.7.0.221 10 0 9439 132040 i I* 198.48.2.0 202.7.0.222 10 0 9439 132040 132001 i I*> 202.7.0.221 10 0 9439 132040 132001 i I* 198.48.3.0 202.7.0.222 10 0 9439 132040 i I*> 202.7.0.221 10 0 9439 132040 i I* 202.7.4.0 202.7.0.222 10 0 9439 132040 23755 i I*> 202.7.0.221 10 0 9439 132040 23755 i I* 202.7.5.0 202.7.0.222 10 0 9439 132040 23755 i I*> 202.7.0.221 10 0 9439 132040 23755 i I* 202.7.6.0 202.7.0.222 10 0 9439 132040 23755 i I*> 202.7.0.221 10 0 9439 132040 23755 i I* 202.7.7.0 202.7.0.222 10 0 9439 132040 23755 i I*> 202.7.0.221 10 0 9439 132040 23755 i V* 203.119.88.0/23 202.7.1.253 30 0 9439 42 187 i V*> 202.7.1.253 30 0 9439 42 187 i 202.7.1.252 20 0 9439 i 202.7.0.147 20 0 9439 24183 45563 i 202.7.0.147 20 0 9439 24183 ? 202.7.0.128 20 0 9439 i 202.7.0.107 20 0 9439 i
On Mon, 6 Jan 2014 11:26:24 +1300, Dean Pemberton wrote:
Anything that turns up as an "I" on this list, I'm going to be looking at pretty carefully before I prefer into the CARDIGAN network.
Cool. I think I see some of our prefixes in there, which is probably a mistake :) I'm travelling today but I'll be having a close look at this tomorrow myself as well. -- Michael Fincham System Administrator, Unleash Office: 0800 750 250
Most of the invalid ones are on there because people are advertising prefixes more specific than their ROA covers. Ie a 22-24 Roa and then advertising /28s on the exchange. Or more likely a 22-22 Roa and 24s on the exchange. It's as much about getting the range right as it is about the originating as and prefix On Monday, January 6, 2014, Michael Fincham wrote:
On Mon, 6 Jan 2014 11:26:24 +1300, Dean Pemberton wrote:
Anything that turns up as an "I" on this list, I'm going to be looking at pretty carefully before I prefer into the CARDIGAN network.
Cool. I think I see some of our prefixes in there, which is probably a mistake :)
I'm travelling today but I'll be having a close look at this tomorrow myself as well.
-- Michael Fincham System Administrator, Unleash Office: 0800 750 250
Keep in mind that advertising more specific prefixes is also how route hijacking works. That's why it's important to only accept the range that the original resource holder specifies. If the owner knows that their prefix will be advertised as a /22, you permitting the containing /24s allows someone else to advertise them and attract the traffic. Think what would happen on the exchange if someone took one of your prefixes and advertised more specifics? On Monday, January 6, 2014, Dean Pemberton wrote:
Most of the invalid ones are on there because people are advertising prefixes more specific than their ROA covers.
Ie a 22-24 Roa and then advertising /28s on the exchange. Or more likely a 22-22 Roa and 24s on the exchange.
It's as much about getting the range right as it is about the originating as and prefix
On Monday, January 6, 2014, Michael Fincham wrote:
On Mon, 6 Jan 2014 11:26:24 +1300, Dean Pemberton wrote:
Anything that turns up as an "I" on this list, I'm going to be looking at pretty carefully before I prefer into the CARDIGAN network.
Cool. I think I see some of our prefixes in there, which is probably a mistake :)
I'm travelling today but I'll be having a close look at this tomorrow myself as well.
-- Michael Fincham System Administrator, Unleash Office: 0800 750 250
participants (2)
-
Dean Pemberton -
Michael Fincham