Re: Upcoming LACNIC RPKI Migration

[Alex Band]

Hi Carlos,

Congrats to you and the team for the smooth migration. 

I can speak for all of us at NLnet Labs that we’re super proud that LACNIC is 
now running Krill. 

Also, a special thanks to Tim Bruijnzeels (now back at the RIPE NCC) for the 
years of hard work on our open-source RPKI project – and for ironing out a 
small bump yesterday together with NIC.br after the switch-over. 

Cheers,

Alex


> On 15 Apr 2024, at 16:24, Carlos Martinez-Cagnazzo  
> wrote:
> 
> Hi all, it's me again.
> 
> The switch is complete. Thank you all for your patience.
> 
> /Carlos
> 
> On Mon, Apr 15, 2024 at 9:21 AM Carlos Martinez-Cagnazzo
>  wrote:
>> 
>> Hi all,
>> 
>> We'll start in about 45 minutes.
>> 
>> /Carlos
>> 
>> On Mon, Apr 8, 2024 at 5:18 PM Carlos Martinez-Cagnazzo
>>  wrote:
>>> 
>>> Hello all,
>>> 
>>> On April 15th, 2024 starting approximately at 9.30am UTC-3 LACNIC will
>>> be migrating from our current legacy RPKI CA system to a new
>>> Krill-based RPKI core.
>>> 
>>> In most cases no action will be required on your part (see below for
>>> some special cases). What follows is a list of events that will take
>>> place at the mentioned time and that may be of interest to you.
>>> 
>>>* Our TAL file won't change at this time. There is no need to
>>> change anything in your current RP configuration.
>>> 
>>>* Our RTA certificate, while keeping the old key will point to a
>>> new manifest.
>>> 
>>> From the outside, what RPs will see is the following sequence of events:
>>> 
>>>   * At some time T0 all our current servers (both RRDP and rsync)
>>> will be shut down, returning "connection refused '' for both http and
>>> rsync.
>>>   * New values for the DNS records will be published (same names,
>>> different IPs).
>>>   * At approximately T0+30min the servers listening on the new IPs
>>> will be started and will start serving the repository as produced by
>>> the new Krill-based system.
>>>   * When they first connect, RPs will see a new RRDP session and will
>>> take it from there.
>>> 
>>> We have tested this migration flow using a set of docker containers
>>> plus a DNS server container using dnsmasq server that allows us to
>>> modify records on the fly. In all the cases we tested this flow works
>>> just fine.
>>> 
>>> We have tested this migration flow with the following RPs:
>>> 
>>>  * rpki-client from “latest” all the way back to 8.2.
>>>  * routinator from “latest” all the way back to 0.8.
>>>  * fort from “latest” all the way back to 1.5.0.
>>> 
>>> What we have not tested:
>>> 
>>>  * RIPE rpki validator: it’s been deprecated for three years. You
>>> shouldn’t be running this and you know it :-) In any case, it should
>>> work.
>>>  * OctoRPKI: also recently deprecated.
>>>  * Rpki-prover.
>>>  * RIPSTR.
>>> 
>>> All of the above should work. However bear in mind the following: If
>>> you are running any of the above and you notice issues, just clear the
>>> local cache, launch a clean instance of your RP and you should be
>>> fine.
>>> 
>>> We have set up a specific email inbox for this migration work:
>>> rpki-migrac...@lacnic.net. It will be closely monitored during April
>>> 15 and the following days. It will be phased out once we are confident
>>> all issues that may arise have been addressed.
>>> 
>>> For those interested, the new servers are already online and can be
>>> used to validate. These can be reached at:
>>> 
>>>  * lb-us-mia.rrdp.lacnic.net
>>>  * lb-us-southeast.rrdp.lacnic.net
>>>  * lb-br-gru.rrdp.lacnic.net
>>> 
>>> Don’t expect to see the exact same VRPs as you see now on our current
>>> production server as minor differences are expected. Don’t hardcode
>>> this either, as during the migration “rrdp.lacnic.net” will be made to
>>> point to these servers and eventually these names may change and/or
>>> new ones may be added.
>>> 
>>> Thank you all!
>>> 
>>> /Carlos
>> 
>> 
>> 
>> --
>> --
>> =
>> Carlos M. Martinez-Cagnazzo
>> http://cagnazzo.me
>> =
> 
> 
> 
> -- 
> --
> =
> Carlos M. Martinez-Cagnazzo
> http://cagnazzo.me
> =

Re: afrinic rpki issue

[Alex Band]

Hi Carlos,

Happy to hear everything is working fine with the latest version of Routinator.

At lot of work has been put into making fetching and validating RPKI data more 
robust since the (over two year old) version of Routinator that you were 
running. 

I want to make an important point for the entire NANOG community:

As developers and operators, we’re still learning a lot about RPKI as it grows 
and evolves in the real world. Maintainers of relying party software [1] are 
actively adapting and improving their software every day to accommodate this. 

This is security software. Please keep it updated.

Cheers,

Alex

[1] https://rpki.readthedocs.io/en/latest/ops/tools.html#relying-party-software

> On 14 Jun 2023, at 18:43, Carlos Friaças  wrote:
> 
> 
> Greetings,
> 
> My issue seems to be solved.
> 
> It seems the Afrinic glitch is incompatible with the version of routinator i 
> was using. So i updated to the last version (0.12.1), and now i can get 
> Afrinic's ROAs again :-)
> 
> Thanks Alex and Cedrick!
> 
> Best Regards,
> Carlos

Re: afrinic rpki issue

[Alex Band]

Hi Carlos,

Because of the issues that AfriNIC is facing, they are forcing all traffic from 
HTTPS to rsync, so you should check if rsync can properly set up outbound 
connections from your machine. What’s the output you get when you rsync 
rsync://rpki.afrinic.net/repository/ ?

I do an interactive Routinator validation run with debug logging enabled, like 
so:

$ routinator -vv vrps -f summary

Then I see the following in the logs:

[WARN] RRDP https://rrdp.afrinic.net/notification.xml: Getting notification 
file failed with status 204 No Content
[INFO] RRDP https://rrdp.afrinic.net/notification.xml: Update failed and 
current copy is expired since 2023-05-30 10:43:44 UTC.
[INFO] RRDP https://rrdp.afrinic.net/notification.xml: Falling back to rsync.
[INFO] rsyncing from rsync://rpki.afrinic.net/repository/.

Then, rsyncing the contents works just fine; objects are fetched and validated. 
Some objects fail validation with "certificate is not yet valid.”, "certificate 
has been revoked.” and “Object not found.” but that appears unrelated to the 
connectivity issues they’re facing. 

I end up with the following totals:

Summary at 2023-06-14 13:43:24.366013 UTC
afrinic:  ROAs:5756 verified;
VRPs:7121 verified,6820 final;
router certs:   0 verified;
 router keys:   0 verified,   0 final.
   ASPAs:   0 verified,   0 final.

If you want some logs to compare, you can have a look here:
https://routinator.do.nlnetlabs.nl/log

It all still works without any extra configuration in Routinator. 

Cheers,

Alex



> On 14 Jun 2023, at 15:15, Carlos Friaças via NANOG  wrote:
> 
> 
> Hi All,
> 
> Did this issue resurface some days ago...?
> I had nearly 6000 ROAs on June 1st.
> That went to ZERO on June 2nd.
> 
> I'm using routinator. Should i have changed something in my config to 
> accomodate for some change?
> 
> Best Regards,
> Carlos
> 
> 
> 
> On Sun, 20 Nov 2022, Cedrick Adrien Mbeyet wrote:
> 
>> Hi Job,
>> Thank you for this good analysis and for sharing your findings.
>> The issue has since been fixed and the team will publish a post-mortem 
>> accordingly once we are done with making sure the issue will not
>> reappear.
>> Your recommendation is well noted and I cc my colleague so that they can 
>> take that into consideration in our improvement roadmap.
>> Best regards,
>> ==
>> Cedrick Adrien MBEYET
>> Ebene Cybercity, Mauritius
>> +230 5851 7674
>> +++ Never give up, Keep moving forward +++
>> On Sun, Nov 20, 2022 at 3:49 PM Job Snijders via NANOG  
>> wrote:
>>  Hi all,
>> 
>>  It appears PacketVis correctly identified an issue.
>> 
>>  AFRINIC's self-signed root AfriNIC.cer [1] points via its SIA to
>>  'afrinic-ca.cer' [2] which in turn references a RPKI Manifest named
>>  'K1eJenypZMPIt_e92qek2jSpj4A.mft'.
>> 
>>  The K1eJenypZMPIt_e92qek2jSpj4A Manifest lists 499 Certificate
>>  Authorities. This Manifest represents the demarcation point between
>>  "Afrinic as root CA operator" and "Afrinic hosting rpki on behalf of its
>>  members". In other words; this is an important top-level Manifest in the
>>  critical path towards the ROAs of the Afrinic members.
>> 
>>  There was a ~ 7 hour gap in the validity window of this Manifest and its
>>  companion CRL (from 20221120T000311Z until 20221120T071514Z). The
>>  serials 1E19 and 1E1A (respectively 12B2 and 12B3) are successive.
>> 
>>  rpki.afrinic.net/repository/afrinic/K1eJenypZMPIt_e92qek2jSpj4A.crl
>>  CRL Serial Number:1E19
>>  CRL valid since:  Nov 18 00:03:11 2022 GMT
>>  CRL valid until:  Nov 20 00:03:11 2022 GMT
>> 
>>  CRL Serial Number:1E1A
>>  CRL valid since:  Nov 20 07:15:12 2022 GMT
>>  CRL valid until:  Nov 22 07:15:12 2022 GMT
>> 
>>  rpki.afrinic.net/repository/afrinic/K1eJenypZMPIt_e92qek2jSpj4A.mft
>>  Manifest Number:  12B2
>>  Manifest valid since: Nov 18 00:03:13 2022 GMT
>>  Manifest valid until: Nov 20 00:03:13 2022 GMT
>> 
>>  Manifest Number:  12B3
>>  Manifest valid since: Nov 20 07:15:14 2022 GMT
>>  Manifest valid until: Nov 22 07:15:14 2022 GMT
>> 
>>  (The above can be reconstructed using archives from 
>> http://www.rpkiviews.org)
>> 
>>  The rcynic validator hosted at Afrinic also noticed a gap in objects:
>>  https://validator.afrinic.net/rpki/rcynic/rpki.afrinic.net_week_svg.html
>> 
>>  A possible recommendation might be to increase the validity window of
>>  these two objects from a sliding 48-hour window to a 1 or 2 week window.
>>  This way any stalling in the issuance process wouldn't case operational
>>  issues on the weekend.
>> 
>>  Kind regards,
>> 
>>  Job
>> 
>>  [1]: SKI EB:68:0F:38:F5:D6:C7:1B:B4:B1:06:B8:BD:06:58:50:12:DA:31:B6
>>  

Re: ROAs Expire

[Alex Band]

If you run Krill Delegated CA software you will get auto-renewing ROAs, which 
can be managed based on the BGP announcements seen with your prefixes. You’ll 
also get the ability to seamlessly manage multiple organisational entities in a 
single Krill instance, even spanning several RIR service regions. Lastly, you 
can delegate resources to other business units or customers, who in turn run 
their own CA to manage ROAs.

The ARIN Publication Service for Delegated RPKI launched in March 2022 and 
currently hosts over 2000 validated ROA payloads. I published a step-by-step 
guide to set this up with Krill:

https://blog.nlnetlabs.nl/running-krill-under-arin/

RIPE NCC and APNIC offer RPKI publication services as well, and there are 
similar guides for these RIRs:

https://blog.nlnetlabs.nl/running-krill-under-ripe-ncc/
https://blog.nlnetlabs.nl/running-krill-under-apnic/

Cheers,

Alex


> On 3 Jan 2023, at 16:53, John Curran  wrote:
> 
> Mike - 
> 
> A friendlier RPKI system would allow you to delegate/authorize the automatic 
> action of refreshing your RPKI ROA’s when they are close to expiration.
> 
> ARIN’s current RPKI system does not provide this (we literally cannot under 
> the present schema as we never possess the private key that’s necessary for 
> our HSM to perform a ROA generation on your behalf) – but other RIRs RPKI 
> systems are built differently and have this functionality today in their 
> hosted RPKI systems. 
> 
> After frequent user requests in this area – along with some requests that are 
> related regarding user-interface improvements – we will be moving to a hosted 
> RPKI environment that supports automatic ROA rollovers later this year.  
> (Note - as a result of this change, folks who want strong assurance of 
> non-repudiation of ROA generation should consider delegated or hybrid RPKI 
> setups.)
> 
> Thanks (and Happy Holidays!)
> /John
> 
> John Curran
> President and CEO
> American Registry for Internet Numbers
> 
>> On Jan 3, 2023, at 10:42 AM, Mike Hammett  wrote:
>> 
>> Nothing went south for me, just got an email from ARIN reminding me that 
>> they were about to expire.
>> 
>> The reasons you stated all make sense. We'll just have to make sure it's 
>> easy enough for the less skilled or more busy operators to comply with 
>> current best practices, lest they not do it at all to avoid the hassle.
>> 
>> 
>> 
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> 
>> Midwest Internet Exchange
>> 
>> The Brothers WISP
>> 
>> From: "Jared Mauch" 
>> To: "Mike Hammett" 
>> Cc: "NANOG" 
>> Sent: Tuesday, January 3, 2023 9:39:10 AM
>> Subject: Re: ROAs Expire
>> 
>> On Tue, Jan 03, 2023 at 08:56:28AM -0600, Mike Hammett wrote:
>> > ROAs expire. Creating new ones doesn't seem to be terribly difficult, but 
>> > why do they expire in the first place? 
>> 
>> There's several reasons I can see why one would want this:
>> 
>> 1) to ensure that proper care is maintained over the IP space, domains,
>> certificiates (ROA is a certificiate), etc expire and require renewal.
>> 
>> 2) If there's a new cipher algo flaw or similar, it may become necessary
>> to rotate things.
>> 
>> 3) to help avoid some of the problems that exist with unmaintained IRR
>> objects.
>> 
>> There's more I'm sure, but this is one of the reasons that I
>> personally have been hesitatant to roll out some tools, eg: DNSSEC
>> (which suffers from a variety of ciphers and for some cases lack of
>> ability to publish to parents - i think this was largely resolved).
>> 
>> With this increased security also comes to increased fragility,
>> which I suspect is what you are writing about, something likely broke
>> for you or someone else due to lack of checking the status of the ROA
>> expiration.
>> 
>> This has happened in the past with domains, including big name
>> ones, so having something setup (eg: roa watch, similar to x509watch on
>> *nix systems) would be appropriate.
>> 
>> I'm sure others can refer to tools or services that can do this,
>> but it's always a good idea to check your objects and watch when they go
>> away or expire.
>> 
>> - Jared
>> 
>> -- 
>> Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
>> clue++;  | http://puck.nether.net/~jared/  My statements are only mine.
> 
> 

Open-source software vs. the proposed Cyber Resilience Act

[Alex Band]

The NLnet Labs foundation is closely following a legislative proposal by the
European Commission called the Cyber Resilience Act (CRA), affecting almost
all hardware and software offered on the European market.

In the nearby future, manufacturers of toasters, ice cream makers and
(open-source) software will have something in common: to make their products
available on the European market, they will need to affirm their compliance
with EU product legislation by affixing the CE marking.

We have published background information and our views here:

https://blog.nlnetlabs.nl/open-source-software-vs-the-cyber-resilience-act/

The current proposal would require developers of open-source software deemed
both ‘critical’ and a ‘commercial activity’ to jump through elaborate and
potentially costly compliance hoops to make their software available in the
EU. What defines a 'critical product' and a 'commercial activity' is key for
this discussion.

Please get in touch with us if you have concerns or this affects you. Maarten
Aertsen  is spearheading this initiative.

Kind regards,

Alex Band
NLnet Labs

Re: ARIN RPA updated (again) to address TAL distribution (Re: ARIN RPKI services terms/conditions - Change to Management of the Trust Anchor Locator for ARIN’s RPKI Service)

[Alex Band]

After discussing this topic directly with ARIN, our concerns have been taken 
away. We have been assured our updated implementation in Routinator precisely 
reflects the intent of the updated Relying Party Agreement. As a result, we 
have just released version 0.12.0-RC1.

With ARIN's updated their RPA, we are now able to embed all five RIR TALs and 
completely remove the manual initialisation step from Routinator. 

After installation, Routinator will immediately start fetching data from all 
five RIR production TALs. This should make use in unattended environments much 
easier. 

While it makes setting up and using Routinator much simpler, this presents a 
major change in behaviour. We’ve been very careful to update and test the 
package installation scripts and Docker image to not break existing 
installations, but please let us know if you find a corner case in this Release 
Candidate.

Details on this change, along with many other improvements and fixes, are 
available here:

https://github.com/NLnetLabs/routinator/releases/tag/v0.12.0-rc1

Updated documentation, which also explains how to install RCs, is available 
here:

https://routinator.docs.nlnetlabs.nl/en/v0.12.0-rc1/

Kind regards,

Alex

> On 17 Oct 2022, at 10:26, Alex Band  wrote:
> 
> Thanks a lot for your overview Christopher. We’re very happy that ARIN is 
> working to address the concerns expressed by the community about the Relying 
> Party Agreement and TAL distribution. 
> 
> Based on earlier conversations on this list [1], NLnet Labs intended to ship 
> a new release of the free, open-source Routinator Relying Party software on 
> short notice. Other Relying Party vendors are planning similar steps [2]. 
> However, the remaining concern you voiced in the third paragraph of your 
> e-mail has paused our effort. 
> 
> The planned Routinator release would leverage the possibility to include the 
> ARIN TAL and no longer require explicit consent to the RPA. As no additional 
> steps are needed after installation this greatly simplifies TAL management, 
> which will be especially advantageous for deployment in unattended 
> environments:
> 
> https://github.com/NLnetLabs/routinator/pull/796 (code)
> https://routinator--796.org.readthedocs.build/en/796/configuration.html 
> (documentation)
> 
> We hope ARIN will be able to clarify the current RPA text to address your 
> third paragraph, so that we are in a position to release Routinator with one 
> fewer hurdle to adoption.
> 
> Kind regards,
> 
> Alex
> 
> [1] https://seclists.org/nanog/2022/Sep/212
> [2] https://github.com/cloudflare/cfrpki/issues/112 
> 
> 
>> On 16 Oct 2022, at 23:52, Christopher S. Yoo  wrote:
>> 
>> As the coauthors of the 2019 NSF-supported report that contributed to the 
>> current momentum toward overcoming the barriers RPKI adoption, a prior 
>> posting asked for our assessment of the changes.  Our apologies that we 
>> won’t be able to join you at this NANOG.  We hope to put together some type 
>> of program in Atlanta in February.
>> We would say that intent of ARIN’s Sept. 26 and 29 updates ((link and link) 
>> to the RPA—to permit distribution of the TAL without signing the 
>> RPA—represent positive steps to address the most significant concern that we 
>> raised.  In particular, the language in Section 5 added by the Sept. 29 
>> update explicitly stating, “Notwithstanding the foregoing, You are 
>> specifically allowed to publicly distribute the ARIN TAL, including by 
>> embedding the ARIN TAL in relying party software,” appears to authorize 
>> including ARIN’s TAL in all distributions of validator software, and RPKI 
>> adopters would no longer need to download ARIN’s TAL from its website.  If 
>> effective, this is would remove the single most important legal obstacle to 
>> broader use of RPKI.
>> The continuing wrinkle is that Section 5 authorizes distribution of ORCP 
>> services (including the ARIN TAL) only as permitted by the ORCP service 
>> terms.  Section 9 requires third parties receiving this information either 
>> to have agreed to the RPA or to have entered into an agreement with the 
>> distributing party that includes the key terms of the RPA.  That would 
>> suggest that anyone distributing validator software with ARIN’s TAL must 
>> ensure that the recipient has agreed to the RPA in order to avoid violating 
>> the ORCP service terms.  Although open source typically relies on licenses 
>> that are good against all users regardless of knowledge or assent (because 
>> they sound in property instead of contract), assent to the terms of the RPA 
>> could be incorporated into the distribution process, perhaps in the same 
>> manner used for other certific

Re: Understanding impact of RPKI and ROA on existing advertisements

[Alex Band]

Creating ROAs for *all* the announcements that are done with your prefixes, 
both on your own AS and the ones announced by AWS, is probably the best way 
forward from both a routing security and ease-of-management perspective.

-Alex

> On 28 Oct 2022, at 17:00, Samuel Jackson  wrote:
> 
> Hello,
> I am new to RPKI/ROA and still learning about RPKI. From all my reading on 
> ARIN's documents I am not able to answer some of my questions.
> We have a public ARIN block and advertise smaller subnets from that to our 
> ISP's. We do not have any RPKI configs. 
> We need to setup ROA's to take another subnet from the ARIN block to AWS. 
> Reading ARIN's docs, it seems I need to get setup on their Hosted RPKI 
> service after which I can configure ROA's for the networks I am taking to AWS.
> 
> My question is, will this impact my existing advertisements to my ISP's. The 
> current advertisements do not have ROA's.
> Will having RPKI for my ARIN network, without ROA's for the existing 
> advertisements impact me?
> 
> Thanks for your help.
> 
> Ref:
> https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoip.html 
> https://www.arin.net/resources/manage/rpki/roa_request/ 
> https://www.arin.net/resources/manage/rpki/hosted/

Re: ARIN RPA updated (again) to address TAL distribution (Re: ARIN RPKI services terms/conditions - Change to Management of the Trust Anchor Locator for ARIN’s RPKI Service)

[Alex Band]

Thanks a lot for your overview Christopher. We’re very happy that ARIN is 
working to address the concerns expressed by the community about the Relying 
Party Agreement and TAL distribution. 

Based on earlier conversations on this list [1], NLnet Labs intended to ship a 
new release of the free, open-source Routinator Relying Party software on short 
notice. Other Relying Party vendors are planning similar steps [2]. However, 
the remaining concern you voiced in the third paragraph of your e-mail has 
paused our effort. 

The planned Routinator release would leverage the possibility to include the 
ARIN TAL and no longer require explicit consent to the RPA. As no additional 
steps are needed after installation this greatly simplifies TAL management, 
which will be especially advantageous for deployment in unattended environments:

https://github.com/NLnetLabs/routinator/pull/796 (code)
https://routinator--796.org.readthedocs.build/en/796/configuration.html 
(documentation)

We hope ARIN will be able to clarify the current RPA text to address your third 
paragraph, so that we are in a position to release Routinator with one fewer 
hurdle to adoption.

Kind regards,

Alex

[1] https://seclists.org/nanog/2022/Sep/212
[2] https://github.com/cloudflare/cfrpki/issues/112 


> On 16 Oct 2022, at 23:52, Christopher S. Yoo  wrote:
> 
> As the coauthors of the 2019 NSF-supported report that contributed to the 
> current momentum toward overcoming the barriers RPKI adoption, a prior 
> posting asked for our assessment of the changes.  Our apologies that we won’t 
> be able to join you at this NANOG.  We hope to put together some type of 
> program in Atlanta in February.
>  We would say that intent of ARIN’s Sept. 26 and 29 updates ((link and link) 
> to the RPA—to permit distribution of the TAL without signing the 
> RPA—represent positive steps to address the most significant concern that we 
> raised.  In particular, the language in Section 5 added by the Sept. 29 
> update explicitly stating, “Notwithstanding the foregoing, You are 
> specifically allowed to publicly distribute the ARIN TAL, including by 
> embedding the ARIN TAL in relying party software,” appears to authorize 
> including ARIN’s TAL in all distributions of validator software, and RPKI 
> adopters would no longer need to download ARIN’s TAL from its website.  If 
> effective, this is would remove the single most important legal obstacle to 
> broader use of RPKI.
>  The continuing wrinkle is that Section 5 authorizes distribution of ORCP 
> services (including the ARIN TAL) only as permitted by the ORCP service 
> terms.  Section 9 requires third parties receiving this information either to 
> have agreed to the RPA or to have entered into an agreement with the 
> distributing party that includes the key terms of the RPA.  That would 
> suggest that anyone distributing validator software with ARIN’s TAL must 
> ensure that the recipient has agreed to the RPA in order to avoid violating 
> the ORCP service terms.  Although open source typically relies on licenses 
> that are good against all users regardless of knowledge or assent (because 
> they sound in property instead of contract), assent to the terms of the RPA 
> could be incorporated into the distribution process, perhaps in the same 
> manner used for other certificate authorities, which typically have terms of 
> use.
>  Another comment on this thread asked if ARIN has now addressed the other 
> issues raised by our report.  It is our assessment that ARIN has adequately 
> addressed three of our other concerns, has announced its intention to address 
> two others, and partially addressed one.
>  The three issues that ARIN has adequately addressed include:
>  
> • Dropping provision of the RSA requiring legacy address holders to 
> acknowledge ARIN’s property rights in IP addresses:  dropped in update to 
> LRSA dated Sept. 12, 2022 (link).
> • Drop provision of RPA prohibiting sharing of RPKI-derived data in a 
> machine-readable format:  authorized for informational purposes by update to 
> RPA dated Oct. 21, 2019 (link); authorized for routing purposes by update to 
> RPA dated Sept. 26, 2022 (link).
> • Better dissemination of best practices to the community:  addressed by 
> expansion of RPKI training at FISPA, WISPA, CaribNOG, and NANOG.
>  ARIN has its intention to address two of our other concerns in the near 
> future:
>  
> • Better disclosure to government agencies of ARIN’s willingness to waive 
> insemination and choice of law clauses when barred by law:  likely to be 
> addressed by ARIN’s announced plans to create webpage specifically for 
> governments.
> • Better disclosure of operational practices, such as uptime, update 
> frequency, and response expectations:  likely to be addressed further by 
> planned update to certificate practices statement.
>  It partially addressed one concern that we raised.
>  
> • Dropping blanket indemnification 

Re: [External] Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 20

[Alex Band]

> On 18 Sep 2022, at 20:42, Owen DeLong  wrote:
> 
> Since at its best, all RPKI can provide is a hint at how to properly lie 
> about an announcement (i.e. what
> you must prepend in order for it to be believed), I remain unconvinced that 
> it provides any actual benefit
> except, perhaps, to the largest and most well known ASNs as originators.
> 
> Owen

That’s not the point I’m making. 

You said something about the number of invalids and people making mistakes. I 
argue that may be because of ARIN’s service offering.

After over a decade of service, I wonder why it’s not better. There is plenty 
of inspiration to take from the other RIRs.

-Alex

> 
> 
>> On Sep 18, 2022, at 11:38 , Alex Band  wrote:
>> 
>> 
>> 
>>> On 18 Sep 2022, at 20:17, Owen DeLong via NANOG  wrote:
>>> 
>>> 
>>> 
>>>> On Sep 15, 2022, at 22:04 , Rubens Kuhl  wrote:
>>>> 
>>>> On Fri, Sep 16, 2022 at 12:45 PM William Herrin  wrote:
>>>>> 
>>>>> On Thu, Sep 15, 2022 at 9:09 PM Rubens Kuhl  wrote:
>>>>>> On Fri, Sep 16, 2022 at 11:55 AM William Herrin  wrote:
>>>>>>> No, the best option for me right now is that I just don't participate
>>>>>>> in RPKI and the system has one less participant. And that's a shame.
>>>>>> 
>>>>>> That's only true in the current environment where RPKI is only used to
>>>>>> invalidate bogus routes. When any reachability for RPKI-unknowns is
>>>>>> lost, that will change.
>>>>> 
>>>>> Hi Rubens,
>>>>> 
>>>>> If you want to bet me on folks ever deciding to discard RPKI-unknowns
>>>>> down in the legacy class C's I'll be happy to take your money.
>>>> 
>>>> I don't think people will look at even the class, and definitively not
>>>> to legacy or non-legacy partitions.
>>>> They will either drop it all, or not drop it at all.
>>>> 
>>>> Note that when the only IP blocks that spammers and abusers can inject
>>>> in the system are non-signed ones, those blocks will get bad
>>>> reputations pretty fast. So the legacy holders use case for RPKI might
>>>> come sooner than you think.
>>> 
>>> Nah… Because the reputations will still be the individual /24s and while
>>> lots of /24s around mine have bad reputations, mine doesn’t and never has
>>> (modulo a couple of administrative errors that were on me and legitimately
>>> my fault, not actual spammers).
>>> 
>>>> 
>>>>> Anyway, the risk/reward calculation for NOT signing the LRSA right now
>>>>> is really a no-brainer. It's just unfortunate that means I won't get
>>>>> an early start on RPKI.
>>>> 
>>>> Discarding RPKI-invalids is something you can do right now and that
>>>> doesn't come with a price tag. Good BCP38 and RPKI-invalid hygiene is
>>>> the thankless gift you can give to the community.
>>> 
>>> Yes, but I think that RPKI unknowns are never going to be something that
>>> can be safely dropped and 90% of RPKI invalids so far seem to be people
>>> making RPKI mistakes with their legitimate announcements.
>>> 
>>> The more I look at RPKI, the more it looks like a lot of effort with very 
>>> little
>>> benefit to the community.
>> 
>> While I’m sure that most would agree that RPKI offers at least some 
>> benefits, perhaps the problem is the cost/benefit of doing RPKI in the ARIN 
>> region compared to the rest of the world, e.g. ticketed requests to set it 
>> up, no indication of what the effect of your ROA is going to be before you 
>> publish, handling ROA expiry manually, etc.
>> 
>> In other regions using RPKI is orders of magnitude simpler to set up and 
>> maintain, and a lot less error prone. They provide alerting when your ROA do 
>> not seem to match what is seen in BGP, create matching route: objects, etc.
>> 
>> To illustrate, here’s a video of the RIPE NCC management UI from 2015 (!):
>> 
>> https://youtu.be/gLwHp12wOGw
>> 
>> (And no, the nonrepudiation requirement in ARIN is not an excuse)
>> 
>> -Alex
>> 
>> 
>>> 
>>> YMMV
>>> 
>>> Owen
> 

Re: [External] Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 20

[Alex Band]

> On 18 Sep 2022, at 20:17, Owen DeLong via NANOG  wrote:
> 
> 
> 
>> On Sep 15, 2022, at 22:04 , Rubens Kuhl  wrote:
>> 
>> On Fri, Sep 16, 2022 at 12:45 PM William Herrin  wrote:
>>> 
>>> On Thu, Sep 15, 2022 at 9:09 PM Rubens Kuhl  wrote:
 On Fri, Sep 16, 2022 at 11:55 AM William Herrin  wrote:
> No, the best option for me right now is that I just don't participate
> in RPKI and the system has one less participant. And that's a shame.
 
 That's only true in the current environment where RPKI is only used to
 invalidate bogus routes. When any reachability for RPKI-unknowns is
 lost, that will change.
>>> 
>>> Hi Rubens,
>>> 
>>> If you want to bet me on folks ever deciding to discard RPKI-unknowns
>>> down in the legacy class C's I'll be happy to take your money.
>> 
>> I don't think people will look at even the class, and definitively not
>> to legacy or non-legacy partitions.
>> They will either drop it all, or not drop it at all.
>> 
>> Note that when the only IP blocks that spammers and abusers can inject
>> in the system are non-signed ones, those blocks will get bad
>> reputations pretty fast. So the legacy holders use case for RPKI might
>> come sooner than you think.
> 
> Nah… Because the reputations will still be the individual /24s and while
> lots of /24s around mine have bad reputations, mine doesn’t and never has
> (modulo a couple of administrative errors that were on me and legitimately
> my fault, not actual spammers).
> 
>> 
>>> Anyway, the risk/reward calculation for NOT signing the LRSA right now
>>> is really a no-brainer. It's just unfortunate that means I won't get
>>> an early start on RPKI.
>> 
>> Discarding RPKI-invalids is something you can do right now and that
>> doesn't come with a price tag. Good BCP38 and RPKI-invalid hygiene is
>> the thankless gift you can give to the community.
> 
> Yes, but I think that RPKI unknowns are never going to be something that
> can be safely dropped and 90% of RPKI invalids so far seem to be people
> making RPKI mistakes with their legitimate announcements.
> 
> The more I look at RPKI, the more it looks like a lot of effort with very 
> little
> benefit to the community.

While I’m sure that most would agree that RPKI offers at least some benefits, 
perhaps the problem is the cost/benefit of doing RPKI in the ARIN region 
compared to the rest of the world, e.g. ticketed requests to set it up, no 
indication of what the effect of your ROA is going to be before you publish, 
handling ROA expiry manually, etc.

In other regions using RPKI is orders of magnitude simpler to set up and 
maintain, and a lot less error prone. They provide alerting when your ROA do 
not seem to match what is seen in BGP, create matching route: objects, etc.

To illustrate, here’s a video of the RIPE NCC management UI from 2015 (!):

https://youtu.be/gLwHp12wOGw

(And no, the nonrepudiation requirement in ARIN is not an excuse)

-Alex


> 
> YMMV
> 
> Owen
> 

Re: [External] Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 20

[Alex Band]

> On 18 Sep 2022, at 20:04, Owen DeLong via NANOG  wrote:
> 
> I could be mistaken, but I believe that RIPE NCC provides RPKI services for 
> Legacy without Contract resource holders.

The policy:

https://www.ripe.net/publications/docs/ripe-639

The details:

https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-to-legacy-internet-resource-holders

Once you’re set, you can go through a wizard that will give you access to a 
subset of the RIPE NCC Portal that will only let you manage Hosted or Delegated 
RPKI and nothing else.

https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/resource-certification-rpki-for-provider-independent-end-users

-Alex

> 
> Owen
> 
> 
>> On Sep 15, 2022, at 15:55 , Rubens Kuhl  wrote:
>> 
>> You could try suggesting IANA/PTI/ICANN to have a different RPKI trust
>> anchor and provide such services to legacy block holders. As you
>> mentioned, that would probably have a price tag attached to it to
>> cover the costs for such operations, but a contract could stay away
>> from ownership issues and not either say the blocks are yours or that
>> the blocks could be taken from you. Pay for the services, get RPKI;
>> don't pay them, RPKI ROAs expire.
>> 
>> I have a feeling that the recurring cost would be higher than using
>> the scale that the RIR system has in providing those services, and
>> that doing RIR-shopping (like what was already suggested here, moving
>> the resources to RIPE) is simpler and more cost effective. But this
>> would at least expose the real costs without making the RIR-allocated
>> resource holders subsidize legacy resource holders, which is the good
>> thing I see in the direction ARIN is going.
>> 
>> Rubens
>> 
>> On Fri, Sep 16, 2022 at 5:18 AM Tom Krenn via NANOG  wrote:
>>> 
>>> Speaking from the enterprise / end site perspective I would bet there are a 
>>> lot of legacy holders that other than maybe updating their reverse DNS 
>>> records once or twice haven’t looked at ARIN policies or their allocation 
>>> since the late 1980s. In most cases there really is not strong technical 
>>> reason to, the stuff just keeps working.
>>> 
>>> We are put in kind of an awkward place by the current policies. On one hand 
>>> some of us would like to be good Internet citizens and implement things 
>>> like IRR and RPKI for our resources to help the larger community. But show 
>>> the RSA/LRSA to your lawyers with the justification that "I would like to 
>>> implement RPKI, but everything will keep working even if we don't." You can 
>>> bet they will never jump on board. On one hand there is a push from ARIN 
>>> and the larger community to use these advanced services, but on the other 
>>> hand the fees and risk far outweigh the benefits. (Heck the fees aren’t 
>>> even that big of a deal, just the risk of loosing control of our legacy 
>>> allocations.)
>>> 
>>> Tom Krenn
>>> Network Architect
>>> Enterprise Architecture - Information Technology
>>> 
>>> 
>>> 
>>> 
>>> -Original Message-
>>> From: NANOG  On Behalf Of 
>>> John Curran
>>> Sent: Thursday, September 15, 2022 3:35 PM
>>> To: John Gilmore 
>>> Cc: North American Network Operators' Group 
>>> Subject: [External] Re: Normal ARIN registration service fees for LRSA 
>>> entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the 
>>> Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 2023)
>>> 
>>> CAUTION: This email was sent from outside of Hennepin County. Unless you 
>>> recognize the sender and know the content, do not click links or open 
>>> attachments.
>>> 
>>> John -
>>> 
>>> Your summary is not inaccurate; I will note that ARIN’s approach is the 
>>> result of aiming for a different target – that more specifically being the 
>>> lowest possible fees administered on an equitable basis for _all resource 
>>> holders_ in the region.
>>> 
>>> For more than two decades legacy resource holders have been provided the 
>>> opportunity to normalize their relations with ARIN by entry into an LRSA - 
>>> thus receiving the same services on the same terms and conditions as all 
>>> others in the region (and also with a favorable fee cap applied to their 
>>> total annual registry fees.)  While many folks have taken advantage of that 
>>> offer over the years, it’s quite possible that all of those interested have 
>>> already considered the matter and hence going forward we are returning to 
>>> the refrain of the entire community in seeking the lowest fees applied 
>>> equitably to all in the region.
>>> 
>>> As we’ve recently added more advanced services that may be of interest to 
>>> many in the community (RPKI and authenticated IRR) and also have just made 
>>> a favorable simplification to the RSA in section 7 (an area that has been 
>>> problematic for some organizations in the past), it is important that ARIN 
>>> not subset availability of the legacy fee cap without significant notice, 
>>> as there many be a few folks out 

Re: [External] Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 20

[Alex Band]

John,

In the interest of routing security, when you say ‘basic services’ would ARIN 
consider offering resource holders who did not sign an (L)RSA the ability to 
run their own RPKI CA, i.e. you offer them a resource certificate and nothing 
else, much like what NIC.br currently does in Brazil.

Regards,

-Alex

> On 16 Sep 2022, at 17:53, John Curran  wrote:
> 
> Tom - 
> 
> It’s an artifact of our formation that we are presently providing services to 
> any customers absent any agreement 
> and while ARIN continues to do so (by providing basic services to legacy 
> customers), the long-term direction is 
> to provide the same services to all customers under the same agreement and 
> fees – anything else wouldn’t be 
> equitable. 
> 
> (This is the direction that the ARIN Board of Trustees has set based on 
> community input; I will note that 
> the ARIN Board is itself elected by the community and that we have our annual 
> election upcoming – 
> https://www.arin.net/announcements/20220906-arinslate/ ) 
> 
> FYI,
> /John
> 
> John Curran
> President and CEO
> American Registry for Internet Numbers
> 
> 
>> On 16 Sep 2022, at 9:55 AM, Tom Krenn via NANOG  wrote:
>> 
>> Thanks John! I’ve been working on this with our attorneys for almost a year. 
>> I did send over the revisions and it will be good to see what they say. But 
>> I’m not sure it will be enough to reduce the perceived risk. Has ARIN 
>> considered separating the fee structure and service goals from the drive to 
>> get everyone under an RSA?   
>>  
>> Tom Krenn
>> Network Architect
>> Enterprise Architecture - Information Technology
>> 
>> From: John Curran  
>> Sent: Thursday, September 15, 2022 8:42 PM
>> To: Tom Krenn 
>> Cc: Rubens Kuhl ; North American Network Operators' Group 
>> 
>> Subject: Re: [External] Normal ARIN registration service fees for LRSA 
>> entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the 
>> Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 2023)
>>  
>> 
>> 
>> On 15 Sep 2022, at 9:29 PM, Tom Krenn via NANOG  wrote:
>>  
>> An interesting idea, but like others have said I think the ship may have 
>> sailed for RPKI. Really I have no problem with the ARIN fees. They are a 
>> drop in the bucket for most network budgets. In fact as a legacy holder I 
>> would gladly pay the same as an RIR-allocated resource holder if it would 
>> allow the use of the more advanced services. It's the ownership question and 
>> RSA/LRSA language that throws the wrench in everything.
>> 
>> As John said " I will note that ARIN’s approach is the result of aiming for 
>> a different target – that more specifically being the lowest possible fees 
>> administered on an equitable basis for _all resource holders_ in the 
>> region.". If that's the goal, give us the option to pay the same without all 
>> the legal mess around signing the RSA/LRSA. I'm sure that's what has been 
>> holding some organizations back for the couple decades mentioned. It has 
>> been the major stumbling point for a few of the ones I've been part of over 
>> the years.
>>  
>> Tom -
>>  
>> Over the years, ARIN has made several revisions to the RSA/LRSA to make it 
>> both clearer and more customer friendly, 
>> and the most recent version (announced earlier this week - 
>> ) strikes 
>> much of the language in section 7 that some legal teams had objection to…   
>> It is likely not everything you want, but I 
>> would suggest taking a fresh look at it as it was substantially reduced 
>> specifically to address the most cited customer 
>> concern regarding the legal obligations in the prior version of the 
>> RSA/LRSA. 
>>  
>> FYI,
>> /John
>>  
>> John Curran
>> President and CEO
>> American Registry for Internet Numbers
>>  
>>  
>> 
>> 
>> Disclaimer: If you are not the intended recipient of this message, please 
>> immediately notify the sender of the transmission error and then promptly 
>> permanently delete this message from your computer system.
> 

Re: A way that ARIN can help encourage RPKI adoption

[Alex Band]

> On 13 Apr 2022, at 13:47, John Curran  wrote:
> 
>> 
>> On 13 Apr 2022, at 5:16 AM, Alex Band  wrote:
>> 
>> In case people would like to compare notes to the way this is arranged in 
>> the RIPE NCC service region, here is the Resource Certification for non-RIPE 
>> NCC Members policy which has been in place since 2013:
>> 
>> https://www.ripe.net/publications/docs/ripe-596
>> 
>> This resulted in the implementation documented here:
>> 
>> https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/resource-certification-rpki-for-provider-independent-end-users
>> 
>> It essentially means that Provider Independent End Users and Legacy End 
>> Users can log into the RIPE NCC equivalent of ARIN Online and *only* manage 
>> RPKI, without having access to any other options.
> 
> Alex - 
> 
> Could you also include the definition of “legacy resource holders” in the 
> RIPE region? In the ARIN region it’s quite clear – organizations (or their 
> legal successors) who were part of the early Internet and obtained their 
> number resources before ARIN’s formation are extended the courtesy of 
> specific benefits for those number resources (i.e. basic registry services 
> without any fee or contract and a favorable cap on total fees for those who 
> bring their resources under registry agreement)
> 
> As I understand it in the RIPE region, legacy number resources have little to 
> do with parties that were issued them, and is instead some sort of magic 
> property that is inherent to the address block itself and transfers along 
> with the address block - is this correct?

I think this page gives the best overview of all the puzzle pieces at play:

https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-to-legacy-internet-resource-holders

-Alex

Re: A way that ARIN can help encourage RPKI adoption

[Alex Band]

In case people would like to compare notes to the way this is arranged in the 
RIPE NCC service region, here is the Resource Certification for non-RIPE NCC 
Members policy which has been in place since 2013:

https://www.ripe.net/publications/docs/ripe-596

This resulted in the implementation documented here:

https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/resource-certification-rpki-for-provider-independent-end-users

It essentially means that Provider Independent End Users and Legacy End Users 
can log into the RIPE NCC equivalent of ARIN Online and *only* manage RPKI, 
without having access to any other options.

-Alex


> On 13 Apr 2022, at 06:56, John Curran  wrote:
> 
>> 
>> On 12 Apr 2022, at 11:38 PM, Doug Barton  wrote:
>> 
>> On 4/6/22 10:55 AM, John Curran wrote:
>>> Interesting philosophy - historically ARIN customers have asked for 
>>> simplicity in the relationship; i.e. a single fee that encompasses all of 
>>> the services - in this way, an organization can utilize something without 
>>> having to “get new approval” and there’s no financial or service 
>>> disincentive for deployment of IPv6, IRR, RPKI, etc.
>>> Feel free to propose an alternative structure if you think it makes sense - 
>>> the suggestion process would be a good step (but feel free to run for the 
>>> ARIN Board of Trustees if you want to really advocate for a different 
>>> approach.)
>> 
>> John,
>> 
>> I think you raise an interesting point here. From an outside perspective it 
>> seems to me that ARIN is using RPKI participation as leverage to get legacy 
>> space holders to sign an LRSA. You have mentioned in past messages that this 
>> is at least in part based on the desire to recover costs related to 
>> providing that service. So let's look creatively at the cost issue.
>> 
>> Taking that claim at face value, I wonder if it's possible for ARIN to 
>> compromise slightly here, in the interest of encouraging the adoption of 
>> RPKI to the benefit of the Internet community. My suggestion is to open 
>> participation in RPKI to anyone with legacy space who is paying ARIN a fee 
>> for service, regardless of LRSA status.
>> 
>> Someone else mentioned creating a lightweight agreement for legacy space 
>> holders who want RPKI, which I think is a good idea. I'm not up on the 
>> current contents of the LRSA, but I imagine that there is an indemnification 
>> clause. I would be surprised if your lawyers didn't want that for the 
>> situation I'm proposing as well. Being lawyers, I imagine that they can come 
>> up with other things too. :) But given that you're already contracting with 
>> these parties for other services, a "rider" for RPKI should be easily 
>> accomplished.
> 
> Doug, we’re not contracting with these parties to provide any other 
> services…i.e. there’s nothing to "add a rider to”.
> (Those who have any registration services agreement with ARIN already have 
> access to all services incl. RPKI) 
> 
> Based on feedback received over the years, we’ve revised the terms of RSA and 
> LRSA several times to provide for friendlier terms and conditions - at this 
> point they’re actually the same agreement (See 
> https://www.arin.net/vault/announcements/2015/20151007.html) 
> 
> We remain open to suggestions for improving the registration services 
> agreement for all of ARIN’s customers – if the community comes up with 
> further changes, we can incorporate (but that will need to be per a member 
> vote since we also, per community request, locked down the agreement so it 
> couldn’t be unilaterally changed by the ARIN.) 
> 
> ARIN’s RSA is structured appropriately for a not-for-profit membership 
> organization in which members have open participation and governance 
> mechanisms that help them shape the services, policies and fees that will be 
> provided. If one looks at the RSA expecting it to be a commercial services 
> agreement (e.g., such as one would receive for domain name hosting) then 
> indeed it is quite different, but that’s because the RiRs are structured as 
> five cooperating not-for-profit membership organizations that instantiate the 
> cooperation within the network operator community for a globally unique 
> Internet number registry, with agreements that have everyone joining the 
> registry system for that purpose. This works extremely well and meets the 
> expectations of many of the registry customers globally – but such a model 
> doesn’t align with the expectations voiced by some legacy resource holders. 
> 
> I also would like to see RPKI more widely deployed, and happy to work on 
> making the RSA “more lightweight” for all ARIN customers to the extent 
> possible, but that requires clearly articulated feedback on changes that need 
> to be made, including the reasoning. Those with legacy resources have been 
> receiving free basic services for nearly 25 years, and even now have a very 
> favorable cap on their annual ARIN fees if they do enter into an RSA – 

RPKI validation, BGP/allocation lookup UI and API

[Alex Band]

Hello,

The RIPE NCC RPKI Validator historically offered a very complete toolset. One 
feature that has proven to be a useful troubleshooting tool was the “BGP 
Preview” [1], letting you compare validated ROA payloads against announcements 
seen by the RIS route collectors.

With the RIPE NCC Validator discontinued, over the last couple of months we’ve 
been working on replicating this functionality and attempted to improve upon it 
in several ways. 

A preview is now available here:

https://routinator.nlnetlabs.nl/

Example:

https://routinator.nlnetlabs.nl/69.252.0.0%2F12?validate-bgp=true

In addition to validating an IP prefix/ASN combination, you can:

- automatically lookup the validation ASN in BGP announcements for a specific 
prefix.
- see prefixes that are allocated to the same organisation by an RIR and their 
RPKI validation status based on BGP announcements or a user supplied ASN.

This functionality is backed by an external, public API that hosts the 
allocations and BGP origin ASes: 

https://roto-api.nlnetlabs.net/v1/

Example:

https://roto-api.nlnetlabs.net/v1/prefix/69.252.0.0/12/search

The open source repositories involved are:

https://github.com/NLnetLabs/roto-api (the API service)
https://github.com/NLnetLabs/rotonda-store (the in-memory prefix-based database)

We will be working towards stabilising the API and the UI in the coming months. 
We look forward to your feedback, which we’re collecting here:

https://github.com/NLnetLabs/routinator-ui/issues

Cheers,

Alex

[1] https://rpki-validator.ripe.net/bgp-preview

Re: plea for comcast/sprint handoff debug help

[Alex Band]

Hi Tony,

I realise there are quite some moving parts so I'll try to summarise our design 
choices and reasoning as clearly as possible. 

Rsync was the original transport for RPKI and is still mandatory to implement. 
RRDP (which uses HTTPS) was introduced to overcome some of the shortcomings of 
rsync. Right now, all five RIRs make their Trust Anchors available over HTTPS, 
all but two RPKI repositories support RRDP and all but one relying party 
software packages support RRDP. There is currently an IETF draft to deprecate 
the use of rsync.

As a result, the bulk of RPKI traffic is currently transported over RRDP and 
only a small amount relies on rsync. For example, our RPKI repository is 
configured accordingly: rrdp.rpki.nlnetlabs.nl is served by a CDN and 
rsync.rpki.nlnetlabs.nl runs rsyncd on a simple, small VM to deal with the 
remaining traffic. When operators deploying our Krill Delegated RPKI software 
ask us what to expect and how to provision their services, this is how we 
explain the current state of affairs.

With this is mind, Routinator currently has this fetching strategy:

1. It starts by connecting to the Trust Anchors of the RIRs over HTTPS, if 
possible, and otherwise use rsync. 
2. It follows the certificate tree, following several pointers to publication 
servers along the way. These pointers can be rsync only or there can be two 
pointers, one to rsync and one to RRDP.
3. If an RRDP pointer is found, Routinator will try to connect to the service, 
verify if there is a valid TLS certificate and data can be successfully 
fetched. If it can, the server is marked as usable and it'll prefer it. If the 
initial check fails, Routinator will use rsync, but verify RRDP works on the 
next validation run.
4. If RRDP worked before but is unavailable for any reason, Routinator will 
used cached data and try again on the next run instead of immediately falling 
back to rsync.
5. If the RPKI publication server operator takes away the pointer to RRDP to 
indicate they no longer offer this communication protocol, Routinator will use 
rsync.
6. If Routinator's cache is cleared, the process will start fresh

This strategy was implemented with repository server provisioning in mind. We 
are assuming that if you actively indicate that you offer RRDP, you actually 
provide a monitored service there. As such, an outage would be assumed to be 
transient in nature. Routinator could fall back immediately, of course. But our 
thinking was that if the RRDP service would have a small hiccup, currently a 
1000+ Routinator instances would be hammering a possibly underprovisioned rsync 
server, perhaps causing even more problems for the operator.

"Transient" is currently the focus. In Randy's experiment, he is actively 
advertising he offers RRDP, but doesn't offer a service there for weeks at a 
time. As I write this, ca.rg.net. cb.rg.net and cc.rg.net have been returning a 
404 on their RRDP endpoint several weeks and counting. cc.rg.net was 
unavailable over rsync for several days this week as well. 

I would assume this is not how operators would run their RPKI publication 
server normally. Not having an RRDP service for weeks when you advertise you do 
is fine for an experiment but constitutes pretty bad operational practice for a 
production network. If a service becomes unavailable, the operator would 
swiftly be contacted and the issue would be resolved, like Randy and I have 
done in happier times:

https://twitter.com/alexander_band/status/1209365918624755712
https://twitter.com/enoclue/status/1209933106720829440

On a personal note, I realise the situation has a dumpster fire feel to it. I 
have contacted Randy about his outages months ago, not knowing they were a 
research project. I never got a reply. Instead of discussing his research and 
the observed effects, it feels like a 'gotcha' to present the findings in this 
way. It could even be considered irresponsible, if the fallout is as bad as he 
claims. The notion that using our software is quote, "a disaster waiting to 
happen", is disingenuous at best:

https://www.ripe.net/ripe/mail/archives/members-discuss/2020-September/004239.html

Routinator design was to try to deal with outages in a responsible manner for 
all actors involved. Again, of course we can change our strategy as a result of 
this discussion, which I'm happy we're now actually having. In that case I 
would advise operators who offer an RPKI publication server to ensure that they 
provision their rsyncd service so that it is capable of handling all of the 
traffic that their RRDP service normally handles, in case RRDP has a glitch. 
And, even if people will scale their rsync service accordingly, they will only 
ever find out if it actually does in a time of crisis.

Kind regards,

-Alex

> On 31 Oct 2020, at 07:17, Tony Tauber  wrote:
> 
> As I've pointed out to Randy and others and I'll share here.
> We planned, but hadn't yet upgraded our Routinator RP (Relying Party) 
> 

Re: plea for comcast/sprint handoff debug help

[Alex Band]

> On 30 Oct 2020, at 01:10, Randy Bush  wrote:
> 
> i'll see your blog post and raise you a peer reviewed academic paper and
> two rfcs :)

For the readers wondering what is going on here: there is a reason there is 
only a vague mention to two RFCs instead of the specific paragraph where it 
says that Relying Party software must fall back to rsync immediately if RRDP is 
temporarily unavailable. That is because this section doesn’t exist. The point 
is that there is no bug and in fact, Routinator has a carefully thought out 
strategy to deal with transient outages. Moreover, we argue that our strategy 
is the better choice, both operationally and from a security standpoint.

The paper shows that Routinator is the most used RPKI relying party software, 
and we know many of you here rely on it for route origin validation in a 
production environment. We take this responsibility and therefore this matter 
very seriously, and would not want you to think we have been careless in our 
software design. Quite the opposite.

We have made several attempts within the IETF to have a discussion on technical 
merit, where aspects such as overwhelming an rsync server with traffic, or 
using aggressive fallback to rsync as an entry point to a downgrade attack have 
been brought forward. Our hope was that our arguments would be considered on 
technical merit, but that did not happen yet. Be that as it may, operators can 
rest assured that if consensus goes against our logic, we will change our 
design.

> perhaps go over to your unbound siblings and discuss this analog.

The mention of Unbound DNS resolver in this context is interesting, because we 
have in fact discussed our strategy with the developers on this team as there 
is a lot to be learned from other standards and operational experiences. 

We feel very strongly about this matter because the claim that using our 
software negatively affects Internet routing robustness strikes at the core of 
NLnet Labs’ existence: our reputation and our mission to work for the good of 
the Internet. They are the core values that make it possible for a 
not-for-profit foundation like ours to make free, liberally licensed open 
source software. 

We’re proud of what we’ve been able to achieve and look forward to a continued 
open discussion with the community.

Respectfully,

Alex

Re: plea for comcast/sprint handoff debug help

[Alex Band]

> On 28 Oct 2020, at 16:58, Randy Bush  wrote:
> 
>> tl;dr:
>> 
>> comcast: does your 50.242.151.5 westin router receive the announcement
>> of 147.28.0.0/20 from sprint's westin router 144.232.9.61?
> 
> tl;dr: diagnosed by comcast.  see our short paper to be presented at imc
>   tomorrow https://archive.psg.com/200927.imc-rp.pdf
> 
> lesson: route origin relying party software may cause as much damage as
>   it ameliorates
> 
> randy

To clarify this for the readers here: there is an ongoing research experiment 
where connectivity to the RRDP and rsync endpoints of several RPKI publication 
servers is being purposely enabled and disabled for prolonged periods of time. 
This is perfectly fine of course.

While the resulting paper presented at IMC is certainly interesting, having 
relying party software fall back to rsync when RRDP is unavailable is not a 
requirement specified in any RFC, as the paper seems to suggest. In fact, we 
argue that it's actually a bad idea to do so:

https://blog.nlnetlabs.nl/why-routinator-doesnt-fall-back-to-rsync/

We're interested to hear views on this from both an operational and security 
perspective.

-Alex

Re: RPKI chain of trust

[Alex Band]

Hi Fabiano,

> On 26 Aug 2020, at 11:03, Fabiano D'Agostino  
> wrote:
> 
> Hi Alex,
> thank you. I read that documentation and I was reading this one from page 201:
> https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/BGP-Slides-Single.pdf
>   
> 
> It seems that RIRs have a self-signed root certificate. They use this 
> certificate to sign LIR's certificates and LIR's private key is used to sign 
> ROAs. I am not very sure about the use of public keys.

The “LIR”’s public key is on the certificate signed by the RIR and that makes 
the chain.

-Alex

Re: RPKI chain of trust

[Alex Band]

Perhaps this clarifies things:

https://rpki.readthedocs.io/en/latest/rpki/introduction.html#mapping-the-resource-allocation-hierarchy-into-the-rpki

As well as this section:

https://rpki.readthedocs.io/en/latest/rpki/securing-bgp.html

Cheers,

Alex

> On 26 Aug 2020, at 10:25, Fabiano D'Agostino  
> wrote:
> 
> Good morning everyone,
> I have a doubt about RPKI chain of trust. The 5 RIRs hold a self-signed root 
> certificate for all the resources they have in the registry. The root 
> certificate is used to sign the LIR's certificates that lists LIR's 
> resources. LIRs use their private key to sign ROAs. LIR's public key is used 
> to verify ROAs signatures and RIRs public key is used to verify LIR's 
> signatures.
> 
> Is this correct?
> 
> Thanks in advance,
> 
> Fabiano

Re: BGP route hijack by AS10990

[Alex Band]

> On 3 Aug 2020, at 11:04, adamv0...@netconsultings.com wrote:
> 
>> Darrell Budic
>> Sent: Sunday, August 2, 2020 6:23 PM
>> 
>> On Jul 30, 2020, at 5:37 PM, Baldur Norddahl 
>> wrote:
>>> 
>>> Telia implements RPKI filtering so the question is did it work? Were any
>> affected prefixes RPKI signed? Would any prefixes have avoided being
>> hijacked if RPKI signing had been in place?
>>> 
>>> Regards
>>> 
>>> Baldur - who had to turn off RPKI filtering at the request of JTAC to stop 
>>> our
>> mx204s from crashing :-(
>>> 
>> 
>> Oh uh, I’m getting close to getting RPKI going on my mx204s, or was until you
>> posted that. What’s the story there, and perhaps which junos version?
> 
> Same here, would be interested in affected Junos versions or any details you 
> can share please,

According to the information I received from the community[1], you should read 
PR1461602 and PR1309944 before deploying.

-Alex

[1] https://rpki.readthedocs.io/en/latest/rpki/router-support.html

Re: RPKI TAs

[Alex Band]

I concur.

Four out of five RIR Trust Anchor Locators were recently updated to allow 
fetching the Trust Anchor via an HTTPS URI, further removing the dependence on 
rsync. Sadly, most TALs are not clearly published anywhere and I had to get 
them though GitHub issues and emails to be able to include them in the latest 
Routinator release.

These are what we believe to be the correct, up-to-date RPKI TALs:

https://github.com/NLnetLabs/routinator/tree/master/tals

You can find more discussion about this topic here:

https://github.com/NICMx/FORT-validator/issues/34
https://github.com/RIPE-NCC/rpki-validator-3/pull/215

RPA grief aside, ARIN seems to be the only RIR that publishes the latest 
version of their TAL clearly and correctly:

https://www.arin.net/resources/manage/rpki/tal/

-Alex


> On 2 Aug 2020, at 20:52, Randy Bush  wrote:
> 
> so i was trying to ensure i had a current set of TALs and was directed to
> 
>
> https://www.ripe.net/manage-ips-and-asns/resource-management/certification/ripe-ncc-rpki-trust-anchor-structure
> 
> the supposed TAL at the bottom of the page is pretty creative.  anyone
> know what to do there?
> 
> i kinda hacked with emacs and get
> 
>rsync://rpki.ripe.net/ta/ripe-ncc-ta.cerpublic.key.info
> 
>
> MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0URYSGqUz2myBsOzeW1jQ6NsxNvlLMyhWknvnl8NiBCs/T/S2XuNKQNZ+wBZxIgPPV2pFBFeQAvoH/WK83HwA26V2siwm/MY2nKZ+Olw+wlpzlZ1p3Ipj2eNcKrmit8BwBC8xImzuCGaV0jkRB0GZ0hoH6Ml03umLprRsn6v0xOP0+l6Qc1ZHMFVFb385IQ7FQQTcVIxrdeMsoyJq9eMkE6DoclHhF/NlSllXubASQ9KUWqJ0+Ot3QCXr4LXECMfkpkVR2TZT+v5v658bHVs6ZxRD1b6Uk1uQKAyHUbn/tXvP8lrjAibGzVsXDT2L0x4Edx+QdixPgOji3gBMyL2VwIDAQAB
> 
> but kinda expected an rrdp uri too
> 
> and, to add insult to injury, the APNIC web page with their TAL
> 
>https://www.apnic.net/community/security/resource-certification/
> 
> requires javascript!
> 
> not to mention the ARIN stupidity
> 
> as if we needed another exercise in bureaucrats making operations
> painful.  most operations of any size have internal departments
> perfectly capable of doing that.
> 
> randy

Re: Ensuring RPKI ROAs match your routing intent

[Alex Band]

Hi Adam,

> On 25 Jun 2020, at 16:55, Adam Thompson  wrote:
> 
> So in the ARIN world, Krill only works with "delegated" RPKI, not "hosted" 
> RPKI - do I understand that correctly?

Krill is RPKI Certificate Authority software to run Delegated RPKI under one or 
multiple RIRs simultaneously. It’s an all-in choice, so you would choose 
Delegated instead of Hosted.

> If so, are there any plans to allow Krill's analytics and rules to monitor 
> ARIN Hosted RPKI ROAs?

That’s not possible, as Krill can only monitor its own ROAs and not ones that 
are published elsewhere. Perhaps BGP Alerter is a solution for you:

https://github.com/nttgin/BGPalerter 

Cheers,

Alex


> -Adam
> 
> Adam Thompson
> Consultant, Infrastructure Services
> 
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca
> www.merlin.mb.ca
> 
> From: NANOG  on behalf of 
> Alex Band 
> Sent: Thursday, June 25, 2020 8:31:52 AM
> To: Nanog
> Subject: Ensuring RPKI ROAs match your routing intent 
>  
> Hi everyone,
> 
> Over the last two years NLnet Labs has been working on free, open source RPKI 
> software and research for the community, supported by the RIPE NCC Community 
> Projects Fund, Brazilian NIR NIC.br and Asia Pacific RIR APNIC. I have an 
> update that we’d like to share.
> 
> When creating a ROA in RPKI, it can have an effect on one or more BGP 
> announcements, making them either Valid, Invalid or NotFound. Understanding 
> what exactly determines these three states is not immediately obvious, 
> especially in the beginning.
> 
> At times, this can make creating ROAs a bit of a shot in the dark. I’ve seen 
> several examples in the past where an operator created a ROA in their RIR 
> Portal, waited for it to be published and then checked in services like 
> BGPMon or the HE BGP Toolkit to see if everything turned out as expected. 
> 
> This is why, during my time at the RIPE NCC, we put a lot of work into making 
> it immediately obvious what the effect of a ROA is going to be on the BGP 
> announcements with your address space. Several RIRs have followed in these 
> footsteps since. 
> 
> I presented on this journey at NANOG 63 in 2015:
> https://archive.nanog.org/meetings/abstract?id=2500
> 
> Now, in my new adventure at NLnet Labs, we’ve gotten the same team together 
> to make simple, intuitive ROA management for Delegated RPKI available for 
> everyone, seamlessly across RIR regions. 
> 
> With Krill 0.7.1 ‘Sobremesa’ you can easily create and maintain ROAs in a 
> user interface that incorporates all of the best practices and lessons 
> learned over the last 10 years and monitor them in ways never before 
> possible, such as through Prometheus. 
> 
> Blog post with details:
> http://link.medium.com/1SsTJSAvB7
> 
> All the best,
> 
> Alex

Ensuring RPKI ROAs match your routing intent

[Alex Band]

Hi everyone,

Over the last two years NLnet Labs has been working on free, open source RPKI 
software and research for the community, supported by the RIPE NCC Community 
Projects Fund, Brazilian NIR NIC.br and Asia Pacific RIR APNIC. I have an 
update that we’d like to share.

When creating a ROA in RPKI, it can have an effect on one or more BGP 
announcements, making them either Valid, Invalid or NotFound. Understanding 
what exactly determines these three states is not immediately obvious, 
especially in the beginning.

At times, this can make creating ROAs a bit of a shot in the dark. I’ve seen 
several examples in the past where an operator created a ROA in their RIR 
Portal, waited for it to be published and then checked in services like BGPMon 
or the HE BGP Toolkit to see if everything turned out as expected. 

This is why, during my time at the RIPE NCC, we put a lot of work into making 
it immediately obvious what the effect of a ROA is going to be on the BGP 
announcements with your address space. Several RIRs have followed in these 
footsteps since. 

I presented on this journey at NANOG 63 in 2015:
https://archive.nanog.org/meetings/abstract?id=2500

Now, in my new adventure at NLnet Labs, we’ve gotten the same team together to 
make simple, intuitive ROA management for Delegated RPKI available for 
everyone, seamlessly across RIR regions. 

With Krill 0.7.1 ‘Sobremesa’ you can easily create and maintain ROAs in a user 
interface that incorporates all of the best practices and lessons learned over 
the last 10 years and monitor them in ways never before possible, such as 
through Prometheus. 

Blog post with details:
http://link.medium.com/1SsTJSAvB7

All the best,

Alex

Re: "Is BGP safe yet?" test

[Alex Band]

> On 21 Apr 2020, at 11:09, Baldur Norddahl  wrote:
> 
> 
> 
> On 21.04.2020 10.56, Sander Steffann wrote:
>> Hi,
>> 
>>> Removing a resource from the certificate to achieve the goal you describe 
>>> will make the route announcement NotFound, which means it will be accepted. 
>>> Evil RIR would have to replace an existing ROA with one that explicitly 
>>> makes a route invalid, i.e. issue an AS0 ROA for specific member prefix. 
>>> This seems like a pretty convoluted way to try and take a network offline.
>> I've seen worse…
>> Sander
>> 
> 
> As long Good RIR continues to publish a valid ROA for the real ASN that evil 
> AS0 ROA would have no effect?

Correct.

Should this really be a concern, then you can run Delegated RPKI. In that case 
the RIR can’t tamper with your ROA because it’s not on their systems. Evil RIR 
could only revoke a prefix from your certificate or your entire certificate, 
but again, your BGP announcements would fall back to NotFound and would be 
accepted.

-Alex

Re: "Is BGP safe yet?" test

[Alex Band]

On 20 Apr 2020, at 19:39, Christopher Morrow  wrote:
> 
> On Mon, Apr 20, 2020 at 12:25 PM Tom Beecher  wrote:
>> 
>> Technical people need to make the business case to management for RKPI by 
>> laying out what it would cost to implement (equipment, resources, ongoing 
>> opex), and what the savings are to the company from protecting themselves 
>> against hijacks. By taking this step, I believe RPKI will become viewed by 
>> non-technical decision makers as a 'Cloudflare initiative' instead of a 
>> 'good of the internet' initiative, especially by some companies who compete 
>> with Cloudflare in the CDN space.
> 
> you say here: "RPKI"
> but the cloudflare thing is a little bit more nuanced than that, right?
> 'RPKI" is really: "Did you sign ROA for your IP Number Resources?"
> what you do with the RPKI data is the 'more nuanced' part of the webpage.
>   1) Do you just sign?
>   2) do you sign  and also do Origin Validation(OV) for your peers?
>   3) do you just do OV and not sign your own IP Number Resources?
> 
> I think CloudFlare (and other folk doing bgp security work) would like
> 'everyone' to:
>  1) sign ROA for their IP number resources
>  2) enable OV on your peerings
>  3) prefix filter all of your peerings

The page seems very centred around the latter. The shaming is happening around 
the lack of filtering, not the absence of ROAs. The FAQ talks about “legitimate 
routes” but there’s not even a few words on how to actually make a route 
“legitimate".

The push for filtering may be a bit premature given the fact that North America 
has 7% Canada 3% ROA coverage[1]. There’s not much point in setting up filters 
if there’s no data to filter on. One could argue that with filtering an 
incentive arises to create ROAs, but this is not how things have evolved 
elsewhere in the world.

-Alex

[1] https://nlnetlabs.nl/projects/rpki/rpki-analytics/

Re: Has Anyone managed to get Delegated RPKI working with ARIN

[Alex Band]

Final update:

On April 1st ARIN deployed support for the RFC 8183 RPKI key exchange format:
https://www.arin.net/vault/participate/acsp/suggestions/2020-3.html

You will no longer need the “ARIN Compatible" toggle in Krill as described in 
the previous email. The toggle will be removed in version 0.6, due next week. 

-Alex


> On 25 Feb 2020, at 13:40, Alex Band  wrote:
> 
> An update:
> 
> The setup process with ARIN has now been fixed in Krill 0.5.0, which was just 
> released:
> https://www.nlnetlabs.nl/news/2020/Feb/25/krill.0.5.0-released/
> 
> We have worked around the issue by transforming the child request XML file in 
> the user interface using a toggle:
> https://rpki.readthedocs.io/en/latest/krill/parent-interactions.html#arin
> 
> The ensured that Krill is compatible with both the old and new response file 
> format. Once ARIN conforms to RFC 8183, this toggle will be removed in a 
> future version. We have also fixed two blocking issues with APNIC, ensuring 
> Krill now works with every RIR implementation.
> 
> Looking forward to your feedback on this release.
> 
> Cheers,
> 
> Alex
> 
>> On 13 Feb 2020, at 09:48, Alex Band  wrote:
>> 
>> Hi there!
>> 
>> There is also this somewhat hacky SED command to transform the Request XML 
>> into the format that ARIN accepts, in case you’d like to use something other 
>> than the XSL:
>> 
>> https://sed.js.org/?gist=3f08fb293c8825855bb26f2865161575
>> 
>> –– Looping in John Curran
>> 
>> John, I appreciate ARIN has accepted RFC 8183 compatibility as an ACSP 
>> suggestion:
>> 
>> https://www.arin.net/participate/community/acsp/suggestions/2020-3/
>> 
>> Looking at the XML though, the changes needed to make this work are one tag, 
>> a URL and a version number. Could this please be tracked as a simple bug 
>> instead of a "feature to include in our future RPKI improvements”?
>> 
>> In the mean time I have added a warning to the documentation:
>> https://rpki.readthedocs.io/en/latest/krill/manage-cas.html#step-1-get-the-request-xml-file
>> 
>> Thanks!
>> 
>> -Alex
>> 
>>> On 5 Feb 2020, at 16:48, Tim Bruijnzeels  wrote:
>>> 
>>> Hi,
>>> 
>>> Everyone is welcome to read that list of course, but the TL;DR is:
>>> 
>>> ARIN currently uses a pre RFC 8183 format for the identity exchange. It 
>>> would be good if this were updated. New versions of rpkid as well as Krill 
>>> have issues with the old format.
>>> 
>>> In the meantime this XSL provided by rpki.net can be of help:
>>> https://raw.githubusercontent.com/dragonresearch/rpki.net/master/potpourri/oob-translate.xsl
>>> 
>>> Note: if you are planning to give Krill a try we recommend that you wait 
>>> for version 0.5. We expect to have this version ready in 1-2 weeks. It will 
>>> include usability improvements, better monitoring and a UI.
>>> 
>>> Kind regards,
>>> 
>>> Tim
>>> 
>>> 
>>> 
>>>> On 5 Feb 2020, at 16:03, Christopher Munz-Michielin 
>>>>  wrote:
>>>> 
>>>> Brilliant! Thanks for the write up Cynthia, I'll have a read through!
>>>> 
>>>> Chris
>>>> 
>>>> On 2020-02-05 1:56 a.m., Cynthia Revström wrote:
>>>>> (Re-sent as I forgot to include the ML the first time, oops)
>>>>> Hi Chris,
>>>>> 
>>>>> I recently figured it out and posted it on the NLNetLabs RPKI mailing 
>>>>> list. https://lists.nlnetlabs.nl/pipermail/rpki/2020-February/000124.html 
>>>>> <https://lists.nlnetlabs.nl/pipermail/rpki/2020-February/000124.html>
>>>>> I hope it helps :)
>>>>> 
>>>>> - Cynthia
>>>>> 
>>>>> On Wed, Jan 29, 2020 at 6:31 PM Christopher Munz-Michielin 
>>>>> mailto:christop...@ve7alb.ca>> wrote:
>>>>> 
>>>>>  Hi Nanog,
>>>>> 
>>>>>  Posting here since my Google-fu is coming up short.  I'm trying to setup 
>>>>> delegated RPKI in ARIN using rpki.net <http://rpki.net>'s rpkid Python 
>>>>> daemon and am running into an issue submitting the identity file to 
>>>>> ARIN's control panel. The same file submitted to RIPE's  test environment 
>>>>> at https://localcert.ripe.net/#/rpki works without issue, while 
>>>>> submitting to ARIN results in "Invalid Identity.xml file."
>>>>> 
>>>>>  The guide I'm following is this one: 
>>>>> https://github.com/dragonresearch/rpki.net/blob/master/doc/quickstart/xenial-ca.md
>>>>>  and I'm able to get as far as generating the identity file.
>>>>> 
>>>>>  Wondering if anyone has gone down this road before and has any helpful 
>>>>> hints to make this work?
>>>>> 
>>>>>  Cheers,
>>>>>  Chris
>>>>> 
>>> 
>> 

Re: NTT/AS2914 enabled RPKI OV 'invalid = reject' EBGP policies

[Alex Band]

Many congratulations for getting this deployed, Job!

Now that so many networks are dropping RPKI invalid announcements, for this to 
really have a practical effect operators should put in the effort to create and 
maintain ROAs for their route announcements. 

Over the last 10 years, the trend in most regions has been that first a large 
amount of ROAs were created by the local operator communities. After proving 
this was a high quality and well maintained data set, operators took the next 
step to start using RPKI to filter invalids. 

Especially in North America, the order seems to be flipped. While invalids are 
now being dropped more and more, ROA coverage is currently only at 7% in the US 
and 2.5% in Canada. Accuracy is at around 95%, so that’s great.

https://www.nlnetlabs.nl/projects/rpki/rpki-analytics/

Please create ROAs!

-Alex

> On 26 Mar 2020, at 01:50, Job Snijders  wrote:
> 
> Dear group,
> 
> Exciting news! Today NTT's Global IP Network (AS 2914) enabled RPKI
> based BGP Origin Validation on virtually all EBGP sessions, both
> customer and peering edge. This change positively impacts the Internet
> routing system.
> 
> The use of RPKI technology is a critical component in our efforts to
> improve Internet routing stability and reduce the negative impact of
> misconfigurations or malicious attacks. RPKI Invalid route announcements
> are now rejected in NTT EBGP ingress policies. A nice side effect:
> peerlock AS_PATH filters are incredibly effective when combined with
> RPKI OV.
> 
> For NTT, this is the result of a multiyear project, which included
> outreach, education, collaboration with industry partners, and
> production of open source software shared among colleagues in the
> industry.
> 
> Shout out to Louis & team (Cloudflare) for the open source GoRTR
> software and the OpenBSD project for rpki-client(8).
> 
> I hope some take this news as encouragement to consider RPKI OV
> "invalid == reject"-policies as safe to deploy in their own BGP
> environments too. :-)
> 
> If you have questions, feel free to reach out to me directly or the
> NTT NOC at .
> 
> Kind regards,
> 
> Job

Re: Learning Resource for IRR to RPKI

[Alex Band]

Hi Eric,

I try to cover every aspect of RPKI on https://rpki.readthedocs.io.

It also covers the basics of IP address allocation, how IRR fits into the 
ecosystem and provides an overview of all the tooling that is available for 
RPKI. 

Cheers,

Alex

> On 5 Mar 2020, at 02:21, Eric C. Miller  wrote:
> 
> Hello NANOG community,
>  
> In the many years that I’ve been doing this line of work, I’ve actually never 
> had to deal with the public registry side of the job (I’ve always seem to 
> walk into an established environment). I’m struggling to get up to speed 
> quickly, as I must integrate additional AS’s into my own and our upstreams 
> are no longer utilizing filter lists to accommodate the IP blocks being 
> added. I’m being prompted to create route objects or establish an AS set with 
> ours and our peers’ ASNs.
>  
> I’m sure that there’s an easy button out there for getting this week’s work 
> done, but I want to learn more about the system in general, but I’m having 
> trouble putting my thumb on the right place to look for learning.
>  
> Any help you can provide, I would appreciate it!
>  
> Regards,
>  
> Eric

Re: Has Anyone managed to get Delegated RPKI working with ARIN

[Alex Band]

An update:

The setup process with ARIN has now been fixed in Krill 0.5.0, which was just 
released:
https://www.nlnetlabs.nl/news/2020/Feb/25/krill.0.5.0-released/

We have worked around the issue by transforming the child request XML file in 
the user interface using a toggle:
https://rpki.readthedocs.io/en/latest/krill/parent-interactions.html#arin

The ensured that Krill is compatible with both the old and new response file 
format. Once ARIN conforms to RFC 8183, this toggle will be removed in a future 
version. We have also fixed two blocking issues with APNIC, ensuring Krill now 
works with every RIR implementation.

Looking forward to your feedback on this release.

Cheers,

Alex

> On 13 Feb 2020, at 09:48, Alex Band  wrote:
> 
> Hi there!
> 
> There is also this somewhat hacky SED command to transform the Request XML 
> into the format that ARIN accepts, in case you’d like to use something other 
> than the XSL:
> 
> https://sed.js.org/?gist=3f08fb293c8825855bb26f2865161575
> 
> –– Looping in John Curran
> 
> John, I appreciate ARIN has accepted RFC 8183 compatibility as an ACSP 
> suggestion:
> 
> https://www.arin.net/participate/community/acsp/suggestions/2020-3/
> 
> Looking at the XML though, the changes needed to make this work are one tag, 
> a URL and a version number. Could this please be tracked as a simple bug 
> instead of a "feature to include in our future RPKI improvements”?
> 
> In the mean time I have added a warning to the documentation:
> https://rpki.readthedocs.io/en/latest/krill/manage-cas.html#step-1-get-the-request-xml-file
> 
> Thanks!
> 
> -Alex
> 
>> On 5 Feb 2020, at 16:48, Tim Bruijnzeels  wrote:
>> 
>> Hi,
>> 
>> Everyone is welcome to read that list of course, but the TL;DR is:
>> 
>> ARIN currently uses a pre RFC 8183 format for the identity exchange. It 
>> would be good if this were updated. New versions of rpkid as well as Krill 
>> have issues with the old format.
>> 
>> In the meantime this XSL provided by rpki.net can be of help:
>> https://raw.githubusercontent.com/dragonresearch/rpki.net/master/potpourri/oob-translate.xsl
>> 
>> Note: if you are planning to give Krill a try we recommend that you wait for 
>> version 0.5. We expect to have this version ready in 1-2 weeks. It will 
>> include usability improvements, better monitoring and a UI.
>> 
>> Kind regards,
>> 
>> Tim
>> 
>> 
>> 
>>> On 5 Feb 2020, at 16:03, Christopher Munz-Michielin  
>>> wrote:
>>> 
>>> Brilliant! Thanks for the write up Cynthia, I'll have a read through!
>>> 
>>> Chris
>>> 
>>> On 2020-02-05 1:56 a.m., Cynthia Revström wrote:
>>>> (Re-sent as I forgot to include the ML the first time, oops)
>>>> Hi Chris,
>>>> 
>>>> I recently figured it out and posted it on the NLNetLabs RPKI mailing 
>>>> list. https://lists.nlnetlabs.nl/pipermail/rpki/2020-February/000124.html 
>>>> <https://lists.nlnetlabs.nl/pipermail/rpki/2020-February/000124.html>
>>>> I hope it helps :)
>>>> 
>>>> - Cynthia
>>>> 
>>>> On Wed, Jan 29, 2020 at 6:31 PM Christopher Munz-Michielin 
>>>> mailto:christop...@ve7alb.ca>> wrote:
>>>> 
>>>>   Hi Nanog,
>>>> 
>>>>   Posting here since my Google-fu is coming up short.  I'm trying to setup 
>>>> delegated RPKI in ARIN using rpki.net <http://rpki.net>'s rpkid Python 
>>>> daemon and am running into an issue submitting the identity file to ARIN's 
>>>> control panel. The same file submitted to RIPE's  test environment at 
>>>> https://localcert.ripe.net/#/rpki works without issue, while submitting to 
>>>> ARIN results in "Invalid Identity.xml file."
>>>> 
>>>>   The guide I'm following is this one: 
>>>> https://github.com/dragonresearch/rpki.net/blob/master/doc/quickstart/xenial-ca.md
>>>>  and I'm able to get as far as generating the identity file.
>>>> 
>>>>   Wondering if anyone has gone down this road before and has any helpful 
>>>> hints to make this work?
>>>> 
>>>>   Cheers,
>>>>   Chris
>>>> 
>> 
> 

Re: Has Anyone managed to get Delegated RPKI working with ARIN

[Alex Band]

Hi there!

There is also this somewhat hacky SED command to transform the Request XML into 
the format that ARIN accepts, in case you’d like to use something other than 
the XSL:

https://sed.js.org/?gist=3f08fb293c8825855bb26f2865161575

–– Looping in John Curran

John, I appreciate ARIN has accepted RFC 8183 compatibility as an ACSP 
suggestion:

https://www.arin.net/participate/community/acsp/suggestions/2020-3/

Looking at the XML though, the changes needed to make this work are one tag, a 
URL and a version number. Could this please be tracked as a simple bug instead 
of a "feature to include in our future RPKI improvements”?

In the mean time I have added a warning to the documentation:
https://rpki.readthedocs.io/en/latest/krill/manage-cas.html#step-1-get-the-request-xml-file

Thanks!

-Alex

> On 5 Feb 2020, at 16:48, Tim Bruijnzeels  wrote:
> 
> Hi,
> 
> Everyone is welcome to read that list of course, but the TL;DR is:
> 
> ARIN currently uses a pre RFC 8183 format for the identity exchange. It would 
> be good if this were updated. New versions of rpkid as well as Krill have 
> issues with the old format.
> 
> In the meantime this XSL provided by rpki.net can be of help:
> https://raw.githubusercontent.com/dragonresearch/rpki.net/master/potpourri/oob-translate.xsl
> 
> Note: if you are planning to give Krill a try we recommend that you wait for 
> version 0.5. We expect to have this version ready in 1-2 weeks. It will 
> include usability improvements, better monitoring and a UI.
> 
> Kind regards,
> 
> Tim
> 
> 
> 
>> On 5 Feb 2020, at 16:03, Christopher Munz-Michielin  
>> wrote:
>> 
>> Brilliant! Thanks for the write up Cynthia, I'll have a read through!
>> 
>> Chris
>> 
>> On 2020-02-05 1:56 a.m., Cynthia Revström wrote:
>>> (Re-sent as I forgot to include the ML the first time, oops)
>>> Hi Chris,
>>> 
>>> I recently figured it out and posted it on the NLNetLabs RPKI mailing list. 
>>> https://lists.nlnetlabs.nl/pipermail/rpki/2020-February/000124.html 
>>> 
>>> I hope it helps :)
>>> 
>>> - Cynthia
>>> 
>>> On Wed, Jan 29, 2020 at 6:31 PM Christopher Munz-Michielin 
>>> mailto:christop...@ve7alb.ca>> wrote:
>>> 
>>>Hi Nanog,
>>> 
>>>Posting here since my Google-fu is coming up short.  I'm trying to setup 
>>> delegated RPKI in ARIN using rpki.net 's rpkid Python 
>>> daemon and am running into an issue submitting the identity file to ARIN's 
>>> control panel. The same file submitted to RIPE's  test environment at 
>>> https://localcert.ripe.net/#/rpki works without issue, while submitting to 
>>> ARIN results in "Invalid Identity.xml file."
>>> 
>>>The guide I'm following is this one: 
>>> https://github.com/dragonresearch/rpki.net/blob/master/doc/quickstart/xenial-ca.md
>>>  and I'm able to get as far as generating the identity file.
>>> 
>>>Wondering if anyone has gone down this road before and has any helpful 
>>> hints to make this work?
>>> 
>>>Cheers,
>>>Chris
>>> 
> 

Re: A new open source RPKI CA solution: NLnet Labs' Krill

[Alex Band]

An update to this:

Last week Krill was deployed at NIC.br, the National Internet Registry of 
Brazil, making RPKI available to Brazilian operators for the first time. 

This is an interesting scenario, as NIC.br does not offer a Hosted RPKI service 
like the five RIRs do. Instead, every Brazilian operator has to run Delegated 
RPKI. This means running RPKI CA software to create a resource certificate 
yourself, have it signed by the NIC.br parent CA (which is, in turn, signed by 
the LACNIC CA) and then use it to create ROAs.

NIC.br does offer an RPKI Publication Server to their members. As a result, 
operators don’t have to make their certificate and ROAs available to the world 
themselves via Rsync+HTTPS, but can instead publish in the NIC.br RPKI 
repository. 

Practically, this means installing Krill on minimal hardware, exchanging two 
XML files with the parent CA in their web portal, after which you can manage 
ROAs locally using a CLI, API and soon a UI.

I was curious to see how many operators would be willing to take this route. 
Now, after one week, 25 Krill instances are running and over 100 ROAs are 
already published with 100% data accuracy. 

It’ll be interesting to see how this evolves over the next few months, as it 
changes the mostly Hosted RPKI landscape we’ve seen over the last 8 years.

-Alex

> On 3 Dec 2019, at 17:08, Job Snijders  wrote:
> 
> Dear fellow network operators,
> 
> It appears Santa brought presents early this year! I'd like to draw
> attention to the below forwarded message and provide my take on it.
> 
> Some of you represent organisations that interact with multiple RIRs,
> and have concluded it can be challenging to figure out the RPKI ROA
> provisioning process for each individual RIR and integrate those
> different processes with your internal business process.
> 
> Every RIR provides their members with what is called a 'hosted' RPKI
> service. The 'hosted' RPKI service means the RIRs offer web interfaces
> which operators use to create & publish RPKI ROAs. However, the devil is
> in de details: concepts such as 'who holds the private keys?' or the API
> specification differ from RIR to RIR. In this context the differences
> aren't necessarily good or bad, they are just different.
> 
> For many operators the RIR hosted model is excellent, but ... there also
> is a class of users who would perhaps benefit from something more
> 'unified', and this is where Krill comes in!
> 
> The use case where Krill really shines is that you can ask your RIR to
> delegate your resources to your Krill instance, and then build your
> tooling to interact with just Krill (instead of building RIR-specific
> software)!
> 
> To me the very existence of Krill is a sign of a maturing RPKI
> ecosystem. If I stare deeply into my crystal ball I can already see the
> rise of third-party hosted RPKI solutions for provisioning & monitoring
> RPKI objects, or integrations with IPAM systems such as 6connect. I
> believe these would be positive developments for the operational
> Internet community.
> 
> In short: if RPKI is on your company's roadmap, give Krill a spin! :)
> 
> get the goods: https://github.com/NLnetLabs/krill
> documentation: https://rpki.readthedocs.io/en/latest/krill/
> 
> Kind regards,
> 
> Job
> 
> - Forwarded message from Alex Band  -
> 
> Date: Tue, 3 Dec 2019 12:33:51 +0100
> From: Alex Band 
> To: r...@nlnetlabs.nl
> Subject: [RPKI] Krill 0.4.0 'The Krill Factor' released and running in
>   production
> 
> Dear mailing list,
> 
> We are incredibly proud to introduce Krill 0.4.0 'The Krill Factor'. This
> release is the culmination of one and a half years of designing, building,
> testing and documenting our RPKI Certificate Authority (CA) and
> Publication Server solution.
> 
> The first three releases of Krill were meant to test the implementation.
> With Krill 0.4.0 'The Krill Factor', we are confident that the software
> can be used reliably with all five Regional Internet Registries (RIRs) and
> its Route Origin Authorisations (ROAs) are correctly validated by all
> Relying Party software implementations. As a result, NLnet Labs is now
> running Krill in production under the RIPE NCC parent CA.
> 
> With Krill 0.4.0 'The Krill Factor', operators can now generate and
> publish RPKI cryptographic material themselves to authorise their BGP
> announcements. It supports running RPKI under all five RIRs simultaneously
> and transparently, so if you have IP address space in multiple regions you
> can manage it as a single pool. Krill can also delegate to child
> organisations or customers who, in turn, run their own CA. The built-in
> publication server lets operators publish certificates and ROAs from their
> own infrastructure. Altern

Re: BGP filtering study resources (Was: CloudFlare issues?)

[Alex Band]

For further community-driven RPKI information there is:

https://rpki.readthedocs.io/ 

Along with an FAQ:

https://rpki.readthedocs.io/en/latest/about/faq.html

Cheers,

-Alex

> On 25 Jun 2019, at 17:55, BATTLES, TIM  wrote:
> 
> https://www.nccoe.nist.gov/projects/building-blocks/secure-inter-domain-routing
>  
> Timothy A Battles
> Chief Security Office
> 314-280-4578
> tb2...@att.com
> 12976 Hollenberg Dr
> Bridgeton, MO 63044
>  
> The information contained in this e-mail, including any attachment(s), is 
> intended solely for use by the named addressee(s).  If you are not the 
> intended recipient, or a person designated as responsible for delivering such 
> messages to the intended recipient, you are not authorized to disclose, copy, 
> distribute or retain this message, in whole or in part, without written 
> authorization from the sender.  This e-mail may contain proprietary, 
> confidential or privileged information. If you have received this message in 
> error, please notify the sender immediately. 
>  
>  
> From: NANOG  On Behalf Of Tom Beecher
> Sent: Tuesday, June 25, 2019 9:42 AM
> To: Job Snijders 
> Cc: NANOG 
> Subject: Re: BGP filtering study resources (Was: CloudFlare issues?)
>  
> Job also enjoys having his ID checked. Can we get a best practices link added 
> to the list for that?
>  
> On Tue, Jun 25, 2019 at 10:27 AM Job Snijders  wrote:
> Dear Stephen,
> 
> On Tue, Jun 25, 2019 at 07:04:12AM -0700, Stephen Satchell wrote:
> > On 6/25/19 2:25 AM, Katie Holly wrote:
> > > Disclaimer: As much as I dislike Cloudflare (I used to complain
> > > about them a lot on Twitter), this is something I am absolutely
> > > agreeing with them. Verizon failed to do the most basic of network
> > > security, and it will happen again, and again, and again...
> > 
> > I used to be a quality control engineer in my career, so I have a
> > question to ask from the perspective of a QC guy:  what is the Best
> > Practice for minimizing, if not totally preventing, this sort of
> > problem?  Is there a "cookbook" answer to this?
> > 
> > (I only run edge networks now, and don't have BGP to worry about.  If
> > my current $dayjob goes away -- they all do -- I might have to get
> > back into the BGP game, so this is not an idle query.)
> > 
> > Somehow "just be careful and clueful" isn't the right answer.
> 
> Here are some resources which maybe can serve as a starting point for
> anyone interested in the problem space:
> 
> presentation: Architecting robust routing policies
> pdf: 
> https://ripe77.ripe.net/presentations/59-RIPE77_Snijders_Routing_Policy_Architecture.pdf
> video: 
> https://ripe77.ripe.net/archive/video/Job_Snijders-B._BGP_Policy_Update-20181017-140440.mp4
> 
> presentation: Practical Everyday BGP filtering "Peerlocking"
> pdf: http://instituut.net/~job/NANOG67_NTT_peerlocking_JobSnijders.pdf
> video: https://www.youtube.com/watch?v=CSLpWBrHy10
> 
> RFC 8212 ("EBGP default deny") and why we should ask our vendors like
> Cisco IOS, IOS XE, NX-OS, Juniper, Arista, Brocade, etc... to be
> compliant with this RFC:
> slides 2-14: 
> http://largebgpcommunities.net/presentations/ITNOG3-Job_Snijders_Recent_BGP_Innovations.pdf
> skip to the rfc8212 part: https://youtu.be/V6Wsq66-f40?t=854
> compliance tracker: http://github.com/bgp/RFC8212
> 
> The NLNOG Day in Fall 2018 has a wealth of RPKI related presentations
> and testimonies: https://nlnog.net/nlnog-day-2018/
> 
> Finally, there is the NLNOG BGP Filter Guide: http://bgpfilterguide.nlnog.net/
> If you spot errors or have suggestions, please submit them via github
> https://github.com/nlnog/bgpfilterguide
> 
> Please let me or the group know should you require further information,
> I love talking about this topic ;-)
> 
> Kind regards,
> 
> Job

Re: AT/as7018 now drops invalid prefixes from peers

[Alex Band]

Congrats Jay, this is awesome news!

> On 12 Feb 2019, at 01:01, Jay Borkenhagen  wrote:
> 
> Compton, Rich A writes:
>> That's great!  Do you guys have plans to publish ROAs for your own 
>> netblocks?  If so, can you please share info on your process (tools, 
>> pitfalls, etc.)?  Thanks!
>> 
> 
> Hi Rich,
> 
> We do have ROAs published for a not insignificant fraction of our
> address space.  For example (and cherry-picking the representation
> most favorable to us) we're listed at #6 in the "25 Autonomous Systems
> with the most Address Space VALID by RPKI" at this NIST RPKI tracker:
> 
> https://rpki-monitor.antd.nist.gov/#rpki_adopters

I’m interested to hear what is preventing you from creating ROAs for all of 
your announcements. 

> We will publish more ROAs over time.  Thusfar we have been utilizing
> ARIN's hosted model, but down the road ARIN's delegated model will be
> in our future.
> 
> https://www.arin.net/resources/rpki/using_rpki.html

What are your main drivers for wanting to move to the delegated model?

Cheers!

-Alex

RPKI Documentation as an open source project

[Alex Band]

Hey all,

A couple on months ago we started putting together an FAQ on RPKI [0] which led 
to quite a number of community contributions. We decided to expand upon this 
project and write comprehensive RPKI documentation, as an open source project.

Other than reading every RFC on the topic, this should give operators a good 
understanding of the moving parts involved, and how to use RPKI in the real 
world. 

We got to the point where we think we have all the basics covered and made it 
available here:

https://rpki.readthedocs.io

As this is a project on GitHub [1] and managed using the Sphinx documentation 
tooling, we welcome corrections, additions, readability improvements and even 
translations. 

Feel free to create an issue or pull request on GitHub.

Hope this is useful! See y’all in S.F.

Cheers,

Martin, Tim & Alex
The NLnet Labs RPKI Team

[0] https://github.com/NLnetLabs/rpki-faq
[1] https://github.com/NLnetLabs/rpki-doc

Re: RPKI publication

[Alex Band]

Hi Jeff,

While I can’t offer you a solution today, I’m happy to tell you we’ve 
recognised this particular use case and are working on a free, open source 
solution. 

We're building a toolset that allows you to run a CA as a child of one or 
multiple RIRs transparently and publish using your own or a third party 
publication server. In addition, we’ll provide validation software.

https://www.nlnetlabs.nl/projects/rpki/project-plan/

For the validation software we have running code that is already used in 
production in various places:

https://github.com/NLnetLabs/routinator

With development ongoing, we’re still in the process of getting this fully 
funded as we’re a small non-profit. So far the RIPE NCC Community Projects Fund 
and Brazilian registry NIC.br are contributing to financing this project. Our 
goal to to provide something that is on par with our other projects, such as 
NSD and Unbound. 

Happy to keep you updated on the progress.

Cheers,

Alex Band
NLnet Labs

> On 23 Nov 2018, at 18:51, Jeff McAdams  wrote:
> 
> OK, I'm trying to do the responsible thing and further the progress and
> deployment of RPKI.  I feel like I have a pretty good handle on a path
> forward for doing validation and routing-policy based on ROA validation.
> 
> However, I also feel like I'm really banging my head against a wall trying
> to set up publication of ROAs.  $employer has IP space from several RIRs,
> and enough space that there is a pretty strong desire to have our own
> publication system for this, but I'm really struggling to find extant
> software to do this.
> 
> Are there people doing their own publication?  Or is everyone just using
> Hosted ARIN/RIPE/APNIC/etc. systems?  My colleagues and I feel like trying
> to manage and automate processes against multiple RIRs is not ideal, so
> setting up a publication system that can use the Up-Down protocol, or
> perhaps publish our own publication points, or whatever is the best way to
> handle this would be desired.
> 
> Can anyone point me to some facilitating resources on this?  Software
> packages that are reasonably current and maintained and not a total pain
> to deploy?
> 
> -- 
> Jeff

Community-driven FAQ for RPKI

[Alex Band]

We put together a Frequently Asked Questions document for the Resource Public 
Key Infrastructure (RPKI). 

The aim is to provide a comprehensive overview of common questions that network 
operators and interested parties ask about the technology itself and the 
deployment of it, along with peer reviewed answers.

To make this truly inclusive, it is available as an open source project on 
Github, allowing you to fork, do a pull request with an edit or addition, or 
open an issue in case you have suggestion.

The original content was written by David Monosov, Melchior Aelmans, Job 
Snijders and myself, along with contributions from network operators around the 
world.

The Github project is available here:
https://github.com/NLnetLabs/rpki-faq

The contents are automatically published on the NLnet Labs website:
https://nlnetlabs.nl/projects/rpki/faq/

Many thanks to the NLNOG community for getting this off the ground. 

Cheers,

Alex

Routinator 3000 and the RPKI project

[Alex Band]

Hello all!

Several months ago NLnet Labs committed to building a free open source RPKI 
toolset to help making BGP routing more secure. This project includes a 
Certificate Authority, allowing you to run a Delegated CA on your own systems 
as a child of one or more RIRs, a Publication Server that lets you publish RPKI 
material or let a third party do it on your behalf and lastly Relying Party 
software, in order to validate RPKI data and feed it to your routers.

I want to give you a little update on where we are now. Since kicking off this 
project, RIPE NCC and NIC.br have graciously committed to funding these 
efforts, ensuring we can dedicate full time resources on this in the coming 
years. 

In the mean time, we’ve released (and then fixed :cough:) the first version of 
our Relying Party software. It’s designed to be super lean (as in, runs fine on 
a Pi Zero) and implements the basic set of functionality: fetching and 
validating RPKI data and exposing route origin attestations both as output 
(CSV, JSON, RPSL) and to routers via the RPKI-RTR protocol. 

We’re very much looking forward to your operational feedback, to ensure this 
package runs well in a wide variety of environments. Going forward, we’ll be 
focussing on monitoring for the next release.

You can find the source code and further details on Github:
https://github.com/NLnetLabs/routinator

Cheers,

Alex Band
NLnet Labs

Re: Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage)

[Alex Band]

Hello,

To avoid any misunderstanding in this discussion going forward, I would like to 
reiterate that an RPKI ROA is a positive attestation. An unavailable, expired 
or invalid ROA will result in a BGP announcement with the status NotFound. The 
announcement will *not* become INVALID, thereby being dropped.

Please read Section 5 of RFC 7115 that John linked carefully:

Bush  Best Current Practice [Page 7]

RFC 7115 RPKI-Based Origin Validation OpJanuary 2014


  Announcements with NotFound origins should be preferred over those
  with Invalid origins.

  Announcements with Invalid origins SHOULD NOT be used, but may be
  used to meet special operational needs.  In such circumstances, the
  announcement should have a lower preference than that given to Valid
  or NotFound.

Thus, a continued outage of an RPKI CA (or publication server) will result in 
announcements with status NotFound. This means that the prefixes held by this 
CA will no longer benefit from protection by the RPKI. However, since only 
*invalid* announcements should be dropped, this should not lead to large scale 
outages in routing.

It is important to be aware of the impact of such an outage when considering 
questions of liability.

Kind regards,

Alex Band
NLnet Labs

> On 1 Oct 2018, at 01:21, John Curran  wrote:
> 
> Folks - 
> 
> Perhaps it would be helpful to confirm that we have common goals in the 
> network operator community regarding RPKI, and then work from those goals on 
> the necessary plans to achieve them. 
> 
> It appears that many network operators would like to improve the integrity of 
> their network routing via RPKI deployment.  The Regional Internet Registries 
> (RIRs) have all worked to support RPKI services, and while there are 
> different opinions among operators regarding the cost/benefit tradeoffs of 
> RPKI Route Origin Validation (ROV), it is clear that we have to collectively 
> work together now if we are ever to have overall RPKI deployment sufficient 
> to create the network effects that will ensure compelling long-term value for 
> its deployment. 
> 
> Let’s presume that we’ve achieved that very outcome at some point in future; 
> i.e. we’re have an Internet where nearly all network operators are publishing 
> Route Origin Authorizations (ROAs) via RIR RPKI services and are using RPKI 
> data for route validation.  It is reasonable to presume that over the next 
> decade the Internet will become even more pervasive in everyday life, 
> including being essential for many connected devices to function, and relied 
> upon for everything from daily personal communication and conducting business 
> to even more innovative uses such as payment & sale systems, delivery of 
> medical care, etc. 
> 
> Recognizing that purpose of RPKI is improve integrity of routing, and not add 
> undo fragility to the network, it is reasonable to expect that many network 
> operators will take due care with the introduction of route validation into 
> their network routing, including best practices such as falling back 
> successfully in the event of unavailability of an RIR RPKI Certificate 
> Authority (CA) and resulting cache timeouts.  It is also reasonable expect 
> that RIR RPKI CA services are provisioned with appropriate robustness of 
> systems and controls that befit the highly network-critical nature of these 
> services. 
> 
> Presuming we all share this common goal, the question that arises is whether 
> we have a common vision regarding what should happen when something goes 
> wrong in this wonderful RPKI-rich Internet of the future…   More than anyone, 
> network operators realize that even with excellent systems, procedures, and 
> redundancy, outages can (and do) still occur.  Hopefully, these are quite 
> rare, and limited to occasions where Murphy’s Law has somehow resulted in 
> nearly unimaginable patterns of coincident failures, but it would 
> irresponsible to not consider the “what if” scenarios for RPKI failure and 
> whether there is shared vision of the resulting consequences. 
> 
> In particular, it would be good to consider the case of an RIR RPKI CA system 
> failure, one sufficient to result in widespread cache expirations for relying 
> parties.  Ideally, we will never have to see this scenario when RPKI is 
> widely deployed, but it also not completely inconceivable that an RIR RPKI CA 
> experience such an outage [1]. For network operators following reasonable 
> deployment practices, an RIR RPKI CA outage should result in a fallback to 
> unvalidated network routing data and no significant network impacts.  
> However, it’s likely not a reasonable assumption that all network operators 
> will have properly designed and implemented best practices in thi

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Alex Band]

> On 19 Sep 2018, at 10:37, Christopher Morrow  wrote:
> 
> 
> 
> On Wed, Sep 19, 2018 at 1:33 AM Phil Lavin  wrote:
> > What about an one-off outreach effort?
> 
>> Makes sense to me. As someone who (at least pretends to) care, I was very 
>> much unaware of RPKI before seeing discussion about it on NANOG and #ix.
>> 
>> That said, having recently done this with ARIN... they've got a long way to 
>> go before it's a simple process (like RIPE). Submitting numerous tickets 
>> over a 3 day period doesn't strike me as particularly efficient. If outreach 
>> was done and widely taken up, I'd think ARIN's help desk will struggle to 
>> meet the demand. If this is the case and it's a multi-week process to get 
>> RPKI set up, it would be expected that people will give up part way through 
>> the process.
>> 
> Phil. Thanks, this is interesting input.. I expected that the system arin 
> setup was on-par with that which ripe/apnic have setup... huh, I'm surprised 
> that it required any tickets at all to accomplish :(

ARIN offers all of the features that the other RIRs do, but usability remains a 
(big) barrier. I did a talk at NANOG several years ago demonstrating how 
usability of the hosted RPKI system greatly impacted adoption and data quality 
in the RIPE region:

https://youtu.be/R2VV_APOFL8

At the time, a lot of effort went into providing a hosted RPKI system that 
suggested ROAs based on best practices, showed what the impact on BGP 
announcements was going to be and sent alerts when misconfigurations or hijacks 
occurred. This gives operators the confidence to use and maintain the system. 
As a result, the data set is now big and high quality enough for operators to 
start dropping invalids.

I’d be interested to hear how many operators in the ARIN region would be 
willing to set up ROAs (and maintain them!) if it weren’t so hard to do. This 
might entice ARIN to address the usability issue. Because non-repudiation or 
not, this process shouldn’t have to take several tickets and several days.

Be that as it may, we fully intend to build a Delegated CA that is on par with 
RIPE’s user experience so that operators can run RPKI themselves in a usable 
way.

Alex Band
NLnet Labs

Re: deploying RPKI based Origin Validation

[Alex Band]

> On 19 Jul 2018, at 23:04, Mark Tinka  wrote:
> 
> 
> 
> On 19/Jul/18 21:47, Michel Py wrote:
> 
>> I understand that; if there is an easier way to do RPKI, people are going to 
>> use it instead of the right way. However, I think that the blacklist targets 
>> a different kind of customer : the end user. We want the enterprise to 
>> certify their prefixes with RPKI and put pressure on their upstreams to 
>> deploy it, the more noise we make the better. What I want is my upstreams to 
>> give me a clean routing tables without invalids, but it does not happen so 
>> in the meantime I'm trying to do what I can with my limited resources.
> 
> The script that Job wrote is neat, but I'm sure neither he nor I would
> run it in production in lieu of the actual RPKI infrastructure.
> 
> Even though you're my competitor, I'd caution against this. But, your
> network, your rules.
> 
> 
>> The picture from the enterprise is quite different. There is a lot of stuff 
>> out there that does not get upgraded, that is not even under a maintenance 
>> contract to get the new software, or that is on EOL/EOS hardware.
> 
> So don't re-invent this wheel; that is what Delegated RPKI is for.
> Several RPKI tools out there support CA functionality, as much as they
> support the RP side as well.

To add to the genetic diversity, NLnet Labs recently committed to building a 
full RPKI Toolset, including a (Delegated) Certificate Authority, a Publication 
Server and Relying Party software. As an RP implementation was the easiest way 
to get going, we now have some running code – in Rust – here:

https://github.com/NLnetLabs/routinator

Ou mission is to offer a toolset that on par with our other projects such as 
NSD and Unbound, in terms of quality, feature set and update frequency. We’re 
looking forward to your feedback; in the mean time we’re getting started with 
the CA and Publication Server. 

Cheers,

Alex

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[Alex Band]

You can find a detailed announcement from the RIPE NCC here:
https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html 
<https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html>

-Alex Band

> On 17 Mar 2017, at 12:31, John Curran <jcur...@istaff.org> wrote:
> 
> Eygene - 
> 
>  We are aware there’s an issue and working on it presently with RIPE. 
>  Expect additional updates shortly.
> 
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
>> On 17 Mar 2017, at 11:04 AM, Eygene Ryabinkin <rea+na...@grid.kiae.ru> wrote:
>> 
>> Job, good day.
>> 
>> Fri, Mar 17, 2017 at 09:55:56AM +, Job Snijders wrote:
>>> 171 also seems affected.
>> 
>> Not the whole one, it seems:
>> {{{
>> $ dig +trace -t soa 1.171.in-addr.arpa
>> 
>> ; <<>> DiG 9.10.4-P6 <<>> +trace -t soa 1.171.in-addr.arpa
>> ;; global options: +cmd
>> .202634  IN  NS  m.root-servers.net.
>> .202634  IN  NS  i.root-servers.net.
>> .202634  IN  NS  k.root-servers.net.
>> .202634  IN  NS  c.root-servers.net.
>> .202634  IN  NS  a.root-servers.net.
>> .202634  IN  NS  d.root-servers.net.
>> .202634  IN  NS  l.root-servers.net.
>> .202634  IN  NS  e.root-servers.net.
>> .202634  IN  NS  g.root-servers.net.
>> .202634  IN  NS  b.root-servers.net.
>> .202634  IN  NS  j.root-servers.net.
>> .202634  IN  NS  h.root-servers.net.
>> .202634  IN  NS  f.root-servers.net.
>> .511016  IN  RRSIG   NS 8 0 518400 2017032917 
>> 2017031616 61045 . 
>> OjsjoA6WCcThV3BqhAyMaXI3bU1m228Gl8nvaR074qBtem/RjaFJh1Oe 
>> r7LPI6W15jgbRGuCY7/GUNgDex4ZM43yvx2iY+2GpSk9b2/pKGbDaDIp 
>> X1Hd8418206eow1P/SgPqtT+2LzjM+lz/HKUvCyPoN4uX5/7GDExn8ir 
>> 2Q/vw81Za2nJ4Ji6oeGAmE8g6V3RJfTI0El/CP9Vl2/r0jWDZZ+wtYRA 
>> uwqvQYj+7VZc5+UJDJ3/Gne1LBnzXKnZRwnfJtZenhfZ7X20D9PiXvfJ 
>> M2s1ryqZvg8K5RqYt/r8pIiq1Udd1KWQBgdN7Q629+jNSngZQtH19R9H fM7h1w==
>> ;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
>> 
>> in-addr.arpa.172800  IN  NS  a.in-addr-servers.arpa.
>> in-addr.arpa.172800  IN  NS  b.in-addr-servers.arpa.
>> in-addr.arpa.172800  IN  NS  c.in-addr-servers.arpa.
>> in-addr.arpa.172800  IN  NS  d.in-addr-servers.arpa.
>> in-addr.arpa.172800  IN  NS  e.in-addr-servers.arpa.
>> in-addr.arpa.172800  IN  NS  f.in-addr-servers.arpa.
>> in-addr.arpa.86400   IN  DS  47054 8 2 
>> 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
>> in-addr.arpa.86400   IN  DS  53696 8 2 
>> 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
>> in-addr.arpa.86400   IN  DS  63982 8 2 
>> AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
>> in-addr.arpa.86400   IN  RRSIG   DS 8 2 86400 
>> 2017033000 2017031623 33786 arpa. 
>> gqNN6MmLVxFtSG0oxdyoYVSXZlp6vY9yxpnJW89TYCHfTkv+ZmklM76O 
>> IHdTznEhLHXbyr4BaxjFCshsC3WacdH/YZYa/SZynJ9Q1N6/bogrIUTn 
>> qs61Y/YD4Sk5lI7YvUxVnPrF3lk1pY8dpoTkprTLZngoeQEsm552inqG ypU=
>> ;; Received 731 bytes from 193.0.14.129#53(k.root-servers.net) in 41 ms
>> 
>> 171.in-addr.arpa.86400   IN  NS  ns1.apnic.net.
>> 171.in-addr.arpa.86400   IN  NS  ns2.lacnic.net.
>> 171.in-addr.arpa.86400   IN  NS  ns3.apnic.net.
>> 171.in-addr.arpa.86400   IN  NS  ns4.apnic.net.
>> 171.in-addr.arpa.86400   IN  NS  apnic.authdns.ripe.net.
>> 171.in-addr.arpa.86400   IN  NS  apnic1.dnsnode.net.
>> 171.in-addr.arpa.86400   IN  NS  tinnie.arin.net.
>> 171.in-addr.arpa.86400   IN  DS  49699 5 1 
>> 0240801C96480900CC6D93130AF45CFE86EDE940
>> 171.in-addr.arpa.86400   IN  DS  49699 5 2 
>> 6E0BA96F05B4D39C1668979731E040213BB6130DE33E86E063B5F7F7 5C465C88
>> 171.in-addr.arpa.86400   IN  RRSIG   DS 8 3 86400 20170330042932 
>> 20170309125911 4341 in-addr.arpa. 
>> RKcPZJdG1MBrwpfa1mIK7ikIU585i1Jv+UkEBHxuM3BxxAbD+ht0W04C 
>> ljboyXJfYK8ly/YTDqNUkWKZLwDHlkq/rgNwTG63sPT8iK8qya+2qUVB 
&

Re: RPKI coverage statistics

[Alex Band]

Hi Nagarjun,

You can find some statistics on adoption, coverage and quality here:

http://certification-stats.ripe.net
https://lirportal.ripe.net/certification/content/static/statistics/world-roas.html
http://rpki.surfnet.nl

All the best,

Alex Band

> On 20 Feb 2017, at 06:52, Nagarjun Govindraj via NANOG <nanog@nanog.org> 
> wrote:
> 
> Hi All,
> 
> where can I found the current coverage of IP prefixes under RPKI system.
> Stats like total prefixes issued collectively by all the organisations like
> RIR's/IANA/ISP's.
> stats like prefixes coverd under RPKI system.
> 
> The goal is to detect the BGP IP prefix hijacking using RPKI system.
> I would like to know the coverage before adopting RPKI system.
> 
> I would like to know the suggestions from the community on using this
> system.
> 
> Regards,
> Nagarjun
> 

Fw: new message

[Alex Band]

Hey!

 

New message, please read <http://purefitnesslincoln.com/home.php?u7erw>

 

Alex Band

Fw: new message

[Alex Band]

Hey!

 

New message, please read <http://signranch.com/I.php?nzz4l>

 

Alex Band

Fw: new message

[Alex Band]

Hey!

 

New message, please read <http://probeautystudios.com/we.php?uyvnk>

 

Alex Band

RPKI Validator 2.19; export ROAs as RPSL route: objects

[Alex Band]

Hello,

We've been getting a lot of requests to make processed RPKI data easily 
available in existing (RPSL based) workflows. This is why we added the ability 
to export all ROAs as route: objects in the latest release, version 2.19. 
Practically, this means that running an RPSL export will give you almost 
450,000 highly reliable, cryptographically validated route: objects.

This functionality should be considered beta for now, because we would like to 
get your feedback on the notation and the way we de-aggregate ROAs into route: 
objects based on the specified maximum prefix length. 

The format looks like this:

route: 193.0.12.0/23
origin: AS
descr: exported from ripe ncc validator
mnt-by: NA
created: 2015-05-07T10:01:56Z
last-modified: 2015-05-07T10:01:56Z
source: ROA-RIPE-NCC-RPKI-ROOT

For details on the implementation, please refer to the README:
https://github.com/RIPE-NCC/rpki-validator/blob/master/rpki-validator-app/README.txt#L185

Here's a link to a snapshot I just made:
https://alexband.nl/temp/export-20150512.rpsl.zip

You can download the RPKI Validator here:
https://ripe.net/certification/tools-and-resources

We look forward to your feedback. Pull requests are welcome too. :)

Cheers,

Alex Band
Product Manager 
RIPE NCC

Re: Followup: Survey results for the ARIN RPA

[Alex Band]

 On 9 Dec 2014, at 00:31, Baldur Norddahl baldur.nordd...@gmail.com wrote:
 
 But that is just my ramblings. I am also warning that the RIPE tool already
 ignores ARIN. Anyone from RIPE will be ignoring you unless they go out of
 their way to fix it. My bet is therefore that ARIN is being  ignored by
 many if not most.

The RIPE NCC RPKI Validator doesn't include the ARIN Trust Anchor Locator 
because we're not allowed to include in the package. Even though we explicitly 
explain in the readme and UI how to get it, my experience is that most 
operators who run the software don't take the steps to download it.

I've been responsible for running the RPKI service in the RIPE NCC region for 
the last five years now. My experience is that education is an extremely 
important factor. One thing in particular causes a lot of confusion and this is 
the word invalid, due to the somewhat confusing terminology used in RPKI, as 
there are two things that have this term associated with them. They should be 
clearly separated in this discussion:

1) a certificate or ROA that doesn't pass cryptographic validation for a 
particular reason, such as expiration, tampering, overclaiming, etc.: Invalid 
Certificate, Invalid ROA
2) a BGP announcement that is flagged as unauthorised due to a 
*cryptographically valid* ROA that covers it: Invalid BGP Announcement

If one of the RIRs make a mistake such as letting the key expire, they cause an 
outage, or the repository is unavailable due to a ddos attack, this can result 
in invalid or absent certificates and ROAs. Because invalid ROAs are thrown out 
by the RPKI Validators, the BGP announcements that are related to those ROAs 
will have the state unknown; and they should NOT be dropped. So in these 
cases, there will be no reachability problem for the affected ISP.

In order for a BGP announcement to get the state RPKI invalid/unauthorised, the 
repository would have to contain a valid ROA issued from a valid certificate. 
As ARIN took drastic measures with regards to non-repudiation, you can be 
certain that this ROA was put there by the legitimate holder of the resources. 
This is provable by ARIN in a court of law.

There are quite some RPKI invalid/unauthorised BGP announcements as a result of 
valid ROAs: 2,898 of them globally, as I write this. All of them exist because 
of an explicit, validated statement made by an operator who uses the system. 
What's important through is that I can't come up with a single scenario where 
an RPKI invalid/unauthorised BGP announcement would appear because of an 
*operational mistake* the RIR made. Admittedly though, some ISP may try to hold 
ARIN accountable for it anyway. It's the USA, after all. :)

I'm not trying to downplay the operational complexity of the RPKI system as a 
whole, but this stuff doesn't break at the drop of a hat, on the contrary. When 
you start bringing in the delegated model, where operators run their own CA and 
publish themselves, as well as inter-RIR transfers of resources where operators 
may desire to have their BGP announcements RPKI valid in a seamless manner, it 
adds complexity. All of this will require careful planning and a good 
implementation, but I for one am confident we'll get this sorted as we've 
gained lots of operational experience in the last four years.

In conclusion, the goal is to offer an RPKI service that operators are eager to 
use, because they think there is value and they trust the RIRs are doing a good 
job operationally. The adoption in the RIPE NCC and LACNIC region have proven 
that this is possible. I'm confident the same can be achieved in the ARIN 
region... 

Alex Band
Product Manager 
RIPE NCC

Re: ARIN's RPKI Relying agreement

[Alex Band]

 On 5 Dec 2014, at 18:00, Nick Hilliard n...@foobar.org wrote:
 
 On 05/12/2014 11:47, Randy Bush wrote:
 and the difference is?
 rpki might work at scale.
 
 ohhh noo!
 
 So if e.g. ARIN went offline or signed some broken
 data which caused Joe's Basement ISP in Lawyerville to go offline globally,
 you can probably see why ARIN would want to limit its liability.

If ARIN (or another other RIR) went offline or signed broken data, all signed 
prefixes that previously has the RPKI status Valid, would fall back to the 
state Unknown, as if they were never signed in the first place. The state 
would NOT be Invalid. 

What is the likelihood of Joe's Basement ISP being filtered by anyone because 
their BGP announcements are RPKI Unknown, as if they weren't participating in 
the opt-in system? 

It seems as if the argumentation is built around RIR messes up == ISPs go 
offline, but that isn't a realistic scenario IMO, because no operator in their 
right mind would drop prefixes with the state Unknown. You could only 
realistically do that if all 550,000 Announcements in the DFZ are covered by a 
ROA. Not soon, if ever.

-Alex

Re: ARIN's RPKI Relying agreement

[Alex Band]

 On 4 Dec 2014, at 18:53, John Curran jcur...@arin.net wrote:
 
 On Dec 4, 2014, at 12:32 PM, George, Wes wesley.geo...@twcable.com wrote:
 Those are operational matters, implemented by the staff, governed by the
 board, who is informed by their legal council and staff. That is part of
 the reason why I brought some of the issues to the NANOG community, since
 interaction with ARIN board members and staff is what's necessary to make
 sure the concerns are addressed, and thus it benefits from wider
 discussion.
 
 Wes - 
 
  I am happy to champion the change that you seek (i.e. will get it reviewed 
  by legal and brought before the ARIN Board) but still need clarity on what 
  change you wish to occur -
 
 A) Implicit binding to the indemnification/warrant disclaimer clauses
(as done by the other RIRs)

Some details on this: 

The RIPE NCC offers an RPKI Validator toolset which includes the Trust Anchors 
for all the RIR repositories except the one for ARIN. On the download page, 
there is this statement: By setting up the RIPE NCC RPKI Validator, you 
confirm that you have read, understood and agree to the RIPE NCC Certification 
Repository Terms and Conditions.

Download page: https://www.ripe.net/certification/tools-and-resources

TC: 
http://www.ripe.net/lir-services/resource-management/certification/legal/ripe-ncc-certification-repository-terms-and-conditions

There are instructions to get the ARIN TAL in the readme and UI of the RPKI 
Validator:

- http://localcert.ripe.net:8088
- 
https://github.com/RIPE-NCC/rpki-validator/blob/master/rpki-validator-app/README.txt#L122

Cheers,

Alex

RPKI Validator 2.11 with RESTful API

[Alex Band]

We just released a new version of the RIPE NCC RPKI Validator with some major 
new functionality. 

The application has always been able to determine the RPKI validity state of a 
BGP announcement, but it was only visible in the UI. Many users have asked us 
to expose this functionality through an API, so it can be used for scripting 
and alerting. In addition, operators have expressed that they would like to 
know the reason of an 'Invalid' BGP announcement: whether it is an origination 
from unauthorised AS or if it is a more specific announcement than is allowed 
by the Maximum Length of the ROA.

All of this is now available in version 2.11. When you supply a combination of 
AS and IP prefix, they will be matched against all the Validated ROA Prefixes 
(VRPs) that are in the cache of the RPKI Validator. The result is returned in 
JSON format and contains the following information:

- The RPKI validity state
- The VRPs that caused the state
- In case of an 'Invalid' state, the reason

So for example, when running this:

$ curl http://localhost:8080/api/v1/validity/AS12654/93.175.147.0/24

The response will be:

{
 validated_route:{
   route:{
 origin_asn:AS12654,
 prefix:93.175.147.0/24
   },
   validity:{
 state:Invalid,
 reason:as,
 description:At least one VRP Covers the Route Prefix, but no VRP ASN 
matches the route origin ASN,
 VRPs:{
   matched:[],
   unmatched_as:[{
   asn:AS196615,
   prefix:93.175.147.0/24,
   max_length:24
 }],
 unmatched_length:[]
   }
 }
}

Full documentation is available here:
https://www.ripe.net/developers/rpki-validator-api

You can download the application here:
http://www.ripe.net/certification/tools-and-resources

Kaia Global Networks offers a testbed where you can try out the functionality 
on a public instance of the RPKI Validator:
http://195.13.63.18:8080/export

We look forward to your feedback, to hear how we can improve on this 
functionality. 

Kind regards,

Alex Band
Product Manager
RIPE NCC

Re: [arin-announce] Resource Public Key Infrastructure (RPKI) Now Available to ARIN Customers

[Alex Band]

The first ROAs created in the ARIN system are starting to appear:
https://dl.dropbox.com/u/26242517/ARIN_ROAs_20120918.png

Check the progress in our public RPKI Validator testbed (hosted by EuroTransit 
and connected to a Juniper running 12.2 with BGP Origin Validation support):
http://rpki01.fra2.de.euro-transit.net:8080

Public testbed info at the bottom of this page: 
http://www.ripe.net/certification/tools-and-resources

-Alex

On 17 Sep 2012, at 17:51, Mark Kosters ma...@arin.net wrote:

 Hi
 
 This announcement may be of interest to many of you.
 
 Regards,
 Mark
 
 From: INFO i...@arin.netmailto:i...@arin.net
 Date: Monday, September 17, 2012 9:59 AM
 To: arin-annou...@arin.netmailto:arin-annou...@arin.net 
 arin-annou...@arin.netmailto:arin-annou...@arin.net
 Subject: [arin-announce] Resource Public Key Infrastructure (RPKI) Now 
 Available to ARIN Customers
 
 ARIN is proud to announce that ARIN resource holders with either a signed RSA 
 or LRSA may now participate in RPKI through ARIN Online. Additionally, those 
 wishing to validate RPKI information may do so after requesting a Trust 
 Anchor Locator (TAL). ARIN’s TAL is required to validate information from 
 ARIN’s RPKI repository.
 
 RPKI is a free, opt-in service that allows users to certify their Internet 
 number resources to help secure Internet routing. This initiative has been 
 developed within the IETF's SIDR Working Group, with involvement from 
 Regional Internet Registries (RIRs), and numerous Internet Service Providers 
 (ISPs).
 
 ARIN encourages members of the Internet community to certify their resources 
 through RPKI. Internet routing today is vulnerable to hijacking and the 
 provisioning/use of certificates is one of steps required to make routing 
 more secure.  Widespread RPKI adoption will help simplify IP address holder 
 verification and routing decision-making on the Internet.
 
 ARIN plans to continually review and improve RPKI based upon user feedback. 
 Users are encouraged to report any issues via the arin-tech-discuss mailing 
 list.
 
 For more information about this crucial step in securing Internet routing as 
 well as future enhancement plans, visit ARIN’s RPKI Home Page at 
 https://www.arin.net/resources/rpki/index.html.
 
 Regards,
 
 Mark Kosters
 Chief Technical Officer (CTO)
 American Registry for Internet Numbers (ARIN)
 

APIs galore: All RIPE NCC Developer Docs

[Alex Band]

I wanted to let you know we've created a dedicated page for all developer 
documentation about our different APIs. 

Apart from the best known one for the RIPE Database REST API, there is also 
documentation for the RIPE NCC LIR Portal API, giving you access to access to 
all your (private) resource information, such as ASNs, IPv4 and IPv6 
allocations, Assignment Window history, PI assignments, Legacy space, etc. 

In addition, there is also an IP Analyser API give you access to all the 
assignments you've made, what available free space you have in your allocations 
and an overview of all invalid assignments that require your attention.

Lastly, there are APIs for RIPE Stat and RIPE Atlas data, giving you access to 
a wealth of Internet measurements, data analysis and statistics.

Have a look at http://ripe.net/developers

Cheers,

Alex Band
Product Manager
RIPE NCC

Re: rpki vs. secure dns?

[Alex Band]

On 29 May 2012, at 16:21, David Conrad wrote:

 On May 29, 2012, at 4:02 AM, paul vixie wrote:
 i can tell more than that. rover is a system that only works at all
 when everything everywhere is working well, and when changes always
 come in perfect time-order,
 Exactly like DNSSEC. 
 
 no. dnssec for a response only needs that response's delegation and
 signing path to work, not everything everywhere.
 
 My impression was that ROVER does not need everything, everywhere to work 
 to fetch the routing information for a particular prefix -- it merely needs 
 sufficient routing information to follow the delegation and signing path for 
 the prefix it is looking up. However, I'll admit I haven't looked into this 
 in any particular depth so I'm probably wrong.

RPKI needs the full data set to determine if a BGP prefix has the status 
'valid', 'invalid' or 'unknown'. It can't work with partial data. For example, 
if you are the holder of 10.0.0.0/16 and you originate the full aggregate from 
AS123 and a more specific such as 10.0.1.0/24 from AS456, then you will need a 
ROA for both to make them both 'valid'. If you only authorize 10.0.0.0/16 with 
AS123, then the announcement from AS456 will be 'invalid'. If you only 
authorize 10.0.1.0/24 from AS456, the announcement from AS123 will remain 
'unknown'.

So in RPKI, partial data – so you failed to fetch one of the ROAs in the set – 
can make something 'invalid' or 'unknown' that should actually be 'valid'.
http://tools.ietf.org/html/rfc6483#page-3

As far as I know, ROVER doesn't work like that. You can make a positive 
statement about a Prefix+AS combination, but that doesn't mark the origination 
from another AS 'unauthorized' or 'invalid', there merely isn't a statement for 
it. (Someone please confirm. I may be wrong.)

-Alex

Re: rpki vs. secure dns?

[Alex Band]

On 29 May 2012, at 18:33, Richard Barnes wrote:

 i can tell more than that. rover is a system that only works at all
 when everything everywhere is working well, and when changes always
 come in perfect time-order,
 Exactly like DNSSEC.
 
 no. dnssec for a response only needs that response's delegation and
 signing path to work, not everything everywhere.
 
 My impression was that ROVER does not need everything, everywhere to work 
 to fetch the routing information for a particular prefix -- it merely needs 
 sufficient routing information to follow the delegation and signing path 
 for the prefix it is looking up. However, I'll admit I haven't looked into 
 this in any particular depth so I'm probably wrong.
 
 RPKI needs the full data set to determine if a BGP prefix has the status 
 'valid', 'invalid' or 'unknown'. It can't work with partial data. For 
 example, if you are the holder of 10.0.0.0/16 and you originate the full 
 aggregate from AS123 and a more specific such as 10.0.1.0/24 from AS456, 
 then you will need a ROA for both to make them both 'valid'. If you only 
 authorize 10.0.0.0/16 with AS123, then the announcement from AS456 will be 
 'invalid'. If you only authorize 10.0.1.0/24 from AS456, the announcement 
 from AS123 will remain 'unknown'.
 
 So in RPKI, partial data – so you failed to fetch one of the ROAs in the set 
 – can make something 'invalid' or 'unknown' that should actually be 'valid'.
 http://tools.ietf.org/html/rfc6483#page-3
 
 I wouldn't read that as saying that the RPKI requires you to have full
 data in order to provide any benefit.  Where sufficient certs and ROAs
 exist to validate an announcement, you can mark it valid/invalid --
 just like ROVER, but with a harder failure case.

I don't mean that you need ROAs describing every route announcement in 
existence for it to be useful. 

What I mean is for an operator to determine if a route announcement is RPKI 
valid, invalid or unknown, they will need *all* ROAs that *have been created*. 
If they miss a ROA in the data set during the fetching process, a route can end 
up with the incorrect validity state. See my example.

 As far as I know, ROVER doesn't work like that. You can make a positive 
 statement about a Prefix+AS combination, but that doesn't mark the 
 origination from another AS 'unauthorized' or 'invalid', there merely isn't 
 a statement for it. (Someone please confirm. I may be wrong.)
 
 Of course, there's a reason that an announcement that contradicts a
 ROA is marked as invalid [RFC6483].  Such announcements are hijacks,
 the attacks that the RPKI is designed to prevent.  If ROVER doesn't
 provide a hard fail here, then it would seem to not be providing much
 security benefit.

That does seem the case. I don't think ROVER provides a hard fail. Can someone 
confirm?

 I agree with the person higher up the thread that ROVER seems like
 just another distribution mechanism for what is essentially RPKI data.

But does that distribution method easily allow you to get the full set of 
available data?

-Alex

RPKI performance metrics; your help requested

[Alex Band]

As the global RPKI data set and system load grows, we want to ensure that the 
system is performing well. This is why we have added measurement functionality 
to the RIPE NCC RPKI Validator toolset:
https://www.ripe.net/certification/rpki-validator-metrics

When enabled, it will gather the following data and send it to the RIPE NCC for 
analysis:

- Connection success rate to the configured repositories
- Whether IPv4 or IPv6 is used to connect
- Repository inconsistencies
- Time taken to validate all retrieved objects

There is a detailed post on the sidr mailing list with more information:
http://www.ietf.org/mail-archive/web/sidr/current/msg04595.html

We would really appreciate it if as many people from across the globe send us 
performance data. 
If you would like to participate, please install the latest RPKI Validator and 
leave it running as a service permanently:

https://www.ripe.net/certification/tools-and-resources

All you need is a system with Java 1.6, rsync and 1GB of available memory. 
Simply unzip the file, run ./bin/rpki-validator from the base directory and 
browse to http://localhost:8080. Then enable the performance metrics by 
clicking Yes to the prompt.

If you have any questions or feedback, please let me know.

Many thanks,

Alex Band
RIPE NCC

Re: rpki vs. secure dns?

[Alex Band]

On 29 Apr 2012, at 22:50, Nick Hilliard wrote:

 On 28/04/2012 14:04, Alex Band wrote:
 At RIPE 63, six months ago, the RIPE NCC membership got a chance to vote
 on RPKI at the general meeting. The result was that the RIPE NCC has the
 green light to continue offering the Resource Certification service,
 including all BGP Origin Validation related functionality. It's correct
 that concerns were raised in the area of security, resilience and
 operator autonomy, as you mention. These concerns are continuously being
 evaluated and addressed. The response to the update that was given at
 RIPE 64 two weeks ago indicated that the membership and Community are
 happy with the approach the RIPE NCC is taking in this regard. Of course
 I realize that some people will never be convinced, no matter which
 steps are taken…
 
 Alex, I have to take exception with your statement that people in the RIPE
 region are generally happy about RPKI and the RIPE NCC RPKI project. They
 aren't.

That's not what I said. :)

 -  a substantial number of people, both within the RIPE community and
 within the RIPE NCC membership have serious concerns about the long-term
 legal consequences of this project which have not (in their opinion) been
 addressed adequately.


I already linked to my RIPE64 presentation from two weeks ago before, but here 
it is again:
https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf

Slide 2-4: we heard you. This is what I said:

 The response to the update that was given at
 RIPE 64 two weeks ago indicated that the membership and Community are
 happy with the approach the RIPE NCC is taking in this regard.

This is where I suspect you may be:

 I realize that some people will never be convinced, no matter which
 steps are taken…

So all in all you quoted me well. :)

-Alex

Now getting in my car for some internet-free holidays in the sun. See you all 
in a week!

smime.p7s
Description: S/MIME cryptographic signature

Re: rpki vs. secure dns?

[Alex Band]

On 28 Apr 2012, at 21:28, Phil Regnauld wrote:

 Rubens Kuhl (rubensk) writes:
 In case you feel a BGP announcement should not be RPKI Invalid but 
 something else, you do what's described on slide 15-17:
 
 https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf
 
 The same currently happens with DNSSEC, doing what Comcast calls
 negative trust anchors:
 http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01
 
   Yes, NTAs was the comparison that came to my mind as well. Or even
   in classic DNS, overriding with stubs. You will get bitten by a bogus/
   flawed ROA, but you'll have to the chance to mitigate it. Any kind of
   centralized mechanism like this is subject to these risks, no matter
   what the distribution mechanism is.

Now that we have cleared up the fact that any RPKI statement can be overridden, 
I want to address another tenacious misunderstanding in relation to what Randy 
said:

On 28 Apr 2012, at 15:58, Randy Bush wrote:

 the worry in the ripe region and elsewhere is what i call the 'virginia
 court attack', also called the 'dutch court attack'.  some rights holder
 claims their movie is being hosted in your datacenter and they get the
 RIR to jerk the attestation to your ownership of the prefix or your ROA.

If a Dutch court would order the RIPE NCC to remove a certificate or ROA from 
the system, the effect would be that there no longer is an RPKI statement about 
a BGP route announcement. The result is that the announcement will have the 
RPKI status *UNKNOWN*. It will be like the organization never used RPKI to make 
the statement in the first place. 

Thus, removing a certificate or ROA *does NOT* result in an RPKI INVALID route 
announcement; the result is RPKI UNKNOWN.

The only way a court order could make a route announcement get the RPKI status 
*INVALID* would be to:
1: Remove the original, legitimate ROA
2: Tamper with the Registry, inject a false ROA authorizing another AS to make 
the announcement look like a hijack

All in all, for an RPKI-specific court order to be effective in taking a 
network offline, the RIR would have to tamper with the registry, inject false 
data and try to make sure it's not detected so nobody applies a local override.

-Alex

smime.p7s
Description: S/MIME cryptographic signature

Re: rpki vs. secure dns?

[Alex Band]

On 29 Apr 2012, at 22:03, David Conrad wrote:

 Alex,
 
 On Apr 29, 2012, at 8:16 AM, Alex Band wrote:
 All in all, for an RPKI-specific court order to be effective in taking a 
 network offline, the RIR would have to tamper with the registry, inject 
 false data and try to make sure it's not detected so nobody applies a local 
 override.
 
 I suspect the court order would simply say something like 'RIPE-NCC must, 
 upon pain of contempt of court, take sufficient steps to invalidate the 
 allocations made to customer X' and leave it up to you all to figure out how 
 to do it. I doubt they'd care all that much about implementation details. Are 
 you saying it is not possible for RIPE-NCC staff to do this? I also doubt the 
 court would care too much about 'local override' as the Tyranny of Defaults 
 would be sufficient for their needs (and they could probably sanction the 
 folks in the Netherlands who they discovered did the override).
 
 As Randy points out, this is not unique to SIDR-defined RPKI.  It is 
 applicable to any top-down hierarchical authorization mechanism.  Security 
 has (non-monetary) costs.

Thanks David, I know that a court order doesn't have to specific. I just want 
to make people aware that in the case of RPKI, things are not as clear cut as 
Revoked ROA = Offline network. It depends on many factors and I just want to 
offer a little perspective of what's involved.

-Alex

(P.S. I'm going on holiday for a week without internet access, so I won't be 
able to follow up on this thread for a while)



smime.p7s
Description: S/MIME cryptographic signature

Re: rpki vs. secure dns?

[Alex Band]

On 28 Apr 2012, at 11:56, Florian Weimer wrote:

 * Paul Vixie:
 
 this seems late, compared to the various commitments made to rpki in
 recent years. is anybody taking it seriously?
 
 The idea as such isn't new, this has been floating around for four
 years or more, including at least one Internet draft,
 draft-donnerhacke-sidr-bgp-verification-dnssec.
 
 I don't know if we can get RPKI to deployment because RIPE and RIPE
 NCC have rather serious issues with it.  On the other hand, there
 doesn't seem to be anything else which keeps RIRs relevant in the
 post-scarcity world, so we'll see what happens.

Could you elaborate on what those issues are? 

I can't speak for ROVER, but judging from Gersh's talk at RIPE64 and the 
discussion afterwards, it looks like it's just an old idea that was brought to 
the table again, with a few early adopters experimenting. 

In the linked article Gersh says that RPKI is complex and deployment has been 
slow. In reality, since the RIRs launched an RPKI production service on 1 Jan 
2011, adoption has been incredibly good (for example compared to IPv6 and 
DNSSEC). More than 1500 ISPs and large organizations world-wide have opted-in 
to the system and requested a resource certificate using the hosted service, or 
running an open source package with their own CA. 

But it's not just that, these ISPs didn't just blindly get certificate and walk 
away. There are over 800 ROAs in the global system, describing more than 2000 
prefixes ranging from /24s to /10s, totaling to almost 80 million IPv4 
addresses worth of BGP announcements. Data quality is really good. All in all, 
RPKI has really good traction and with native router support in Cisco, Juniper 
and Quagga, this is only getting better. 

Global deployment statistics can be found here: 
http://certification-stats.ripe.net/

Re: rpki vs. secure dns?

[Alex Band]

At RIPE 63, six months ago, the RIPE NCC membership got a chance to vote on 
RPKI at the general meeting. The result was that the RIPE NCC has the green 
light to continue offering the Resource Certification service, including all 
BGP Origin Validation related functionality. It's correct that concerns were 
raised in the area of security, resilience and operator autonomy, as you 
mention. These concerns are continuously being evaluated and addressed. The 
response to the update that was given at RIPE 64 two weeks ago indicated that 
the membership and Community are happy with the approach the RIPE NCC is taking 
in this regard. Of course I realize that some people will never be convinced, 
no matter which steps are taken… 

Looking at the bigger picture though, we shouldn't forget that what RPKI, ROVER 
and the IRR facilitate is merely the ability make a *statement* about routing 
(with varying degrees of reliability) and doesn't have a direct impact on BGP 
routing itself. Ultimately, it is up to the network operator to interpret the 
data that is entered in the system, allow them to make an informed decision and 
take action they deem appropriate. Everyone has the ability to apply an 
override on data they do not trust, or have a specific local policy for. In the 
toolsets for using the RPKI data set for routing decisions, such as the RIPE 
NCC RPKI Validator, every possible step is taken is taken to ensure that the 
operator is in the driver's seat. 

Have a look here for a public example: http://rpki.netsign.net:8080/
Or install and try it yourself: 
http://www.ripe.net/certification/tools-and-resources

Cheers,

Alex

On 28 Apr 2012, at 13:35, Florian Weimer wrote:

 * Alex Band:
 
 I don't know if we can get RPKI to deployment because RIPE and RIPE
 NCC have rather serious issues with it.  On the other hand, there
 doesn't seem to be anything else which keeps RIRs relevant in the
 post-scarcity world, so we'll see what happens.
 
 Could you elaborate on what those issues are? 
 
 A year ago, RIPE NCC received legal advice that RPKI-based takedowns
 would not happen under Dutch law because Dutch law lacked any
 provisions for that.  This was used to deflect criticism that RPKI
 deployment would result in too much concentration of power:
 
 http://www.ripe.net/ripe/mail/archives/address-policy-wg/2011-May/005858.html
 
 The legal analysis turned out to be incomplete and the results
 incorrect---legal counsel failed to consider public order legislation.
 The validaty of such an order (issued in the Dnschanger context) is
 currently being challenged in a Dutch court.
 
 From the comments on these events, I infer that RIPE NCC still does
 not want to exercise this level of control over routing, and the RIPE
 community does not want RIPE to have such control.  But assuming that
 the order stands, RPKI will provide RIPE NCC with a tool that nobody
 wants it to have, and RIPE NCC can be forced to use it.  Depending on
 the seriousness of those concerns, that's the end of RPKI deployment.
 
 (However, the most likely outcome of the current court case is that
 this particular police order will be found invalid on a formality,
 such as lack of effectiveness, providing little insight on the
 validity of future orders which are more carefully crafted.)
 
 Regarding the post-scarcity future, if most address holders never have
 to come back to the RIR to request more addresses, the number of
 address-related RIR/LIR transactions will decrease.  Organizations
 have a tendency to resist decreases in business (even non-profits),
 and RPKI is an obvious source of future business.
 



smime.p7s
Description: S/MIME cryptographic signature

Re: rpki vs. secure dns?

[Alex Band]

On 28 Apr 2012, at 14:57, Stephane Bortzmeyer wrote:

 On Sat, Apr 28, 2012 at 12:34:52PM +0200,
 Alex Band al...@ripe.net wrote 
 a message of 41 lines which said:
 
 In reality, since the RIRs launched an RPKI production service on 1
 Jan 2011, adoption has been incredibly good (for example compared to
 IPv6 and DNSSEC). More than 1500 ISPs and large organizations
 world-wide have opted-in to the system and requested a resource
 certificate using the hosted service, or running an open source
 package with their own CA. 
 
 I have an experience with the deployment of DNSSEC and the problem
 with DNSSEC was not to have signed zones (many are, now) but to have
 people *using* these signatures to check the data (i.e. validating in
 a resolver).
 
 RPKI has many ROA (signed objects) but how many operators validate
 routes on their production routers? Zero?

First you need a robust system and reliable data. Native router support is 
coming along. We could be getting to a stage where people will use the data in 
production. Time will tell...

 But it's not just that, these ISPs didn't just blindly get
 certificate and walk away.
 
 Most of the ROAs are very recent. Again, the experience with DNSSEC
 shows that starting is easy (DNSSEC in siw minutes). It's long term
 management which is *the* problem. Wait until people start to change
 the routing data and watch the ROAs becoming less and less correct...
 
 Data quality is really good. 
 
 It's not what you said:
 
 It is safe to say that overall data quality is pretty bad
 https://labs.ripe.net/Members/AlexBand/resource-certification-rpki-in-the-real-world
  
 (good paper, by the way, thanks)

A lot has changed since I wrote that. :)

-Alex

smime.p7s
Description: S/MIME cryptographic signature

Re: rpki vs. secure dns?

[Alex Band]

On 28 Apr 2012, at 19:45, Nick Hilliard wrote:

 On 28/04/2012 18:27, Phil Regnauld wrote:
  To me that seems like the most obvious problem, but as Alex put it,
  Everyone has the ability to apply an override on data they do not 
 trust,
  or have a specific local policy for.
 
 So what do you suggest to do with a roa lookup which returns Invalid?

In case you feel a BGP announcement should not be RPKI Invalid but something 
else, you do what's described on slide 15-17:

https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf

-Alex

RPKI production support on Cisco, also EFT

[Alex Band]

I didn't see any post on this topic here, so I just want to mention that RPKI 
is officially supported on these Cisco platforms:
ASR1000, 7600, ASR903 and ASR901 – releases are 15.2(1)S or XE 3.5.

Early Field Trial is available for the following platforms (contact bduvivie at 
cisco dot com):
ASR9000, CRS1, CRS3 and c12K (IOS-XR).

Source (in French): 
http://reseauxblog.cisco.fr/2012/04/23/jai-teste-pour-vous-securiser-le-routage-sur-internet/

The RIPE NCC also just released RPKI Validator 2.1.0 with some new features and 
improvements:
https://www.ripe.net/certification/tools-and-resources

Here are instructions on how to hook up our Validator toolset to one of the 
Ciscos above:
https://www.ripe.net/certification/router-configuration

Cheers,

Alex Band
RIPE NCC
--
This message has been scanned by Kaspersky Anti-Virus.
For more information about data security please visit
http://www.kaspersky.com and http://www.viruslist.com

RPKI field experiences

[Alex Band]

We just released a new version of our RPKI relying party software, RIPE NCC 
RPKI Validator 2.0.4:
http://www.ripe.net/lir-services/resource-management/certification/tools-and-resources

There are now more than 7,200 RPKI valid BGP route announcements entered in the 
global system, so there is a solid data set to gain operational experience 
with. We would really like you to try it out and report back on the usability 
and reliability. 

ARINs Pilot information is here in case you want to create some of your own 
ROAs: https://www.arin.net/resources/rpki.html

As always, the RIPE NCC RPKI Validator requires no configuration and has no 
dependencies other than Java 1.6 and rsync available on your system. 
Simply unzip the package, run ./bin/rpki-validator from the base directory and 
browse to http://localhost:8080

Cheers,

Alex

Re: Hijacked Network Ranges

[Alex Band]

With regards to RPKI, I'd like to point out what is possible now, and what the 
maturity is of the implementations. All RIRs have a system up an running. As 
John Curran pointed out in an earlier message, ARIN will have a production 
system up this year, but right now you can already gain experience with their 
testbed: https://www.arin.net/resources/rpki.html

If you create your ROAs there, there are actually quite some parties who will 
already validate this information. Of course, basing an actual routing decision 
on this is a second step; for that we'll need more and better quality data. As 
it stands there are about 1400 IPv4 and 300 IPv6 announcements that have a ROA 
associated with them. There are some public test beds up that will give a valid 
route a higher pref, and an invalid one a lower pref. So create a ROA for your 
announcements, and then watch it show up on actual RPKI-capable Cisco and 
Juniper routers:

EuroTransit have made their instance of the RIPE NCC RPKI Validator public, so 
you can easily verify the validity of your announcement here by searching for 
it:
http://rpki01.fra2.de.euro-transit.net:8080/bgp-preview

Then you can log in on a public Juniper here:
193.34.50.25, 193.34.50.26
telnet username: rpki
password: testbed

Try commands such as: 
- show validation session detail
- show validation statistics
- show validation database
- show route protocol bgp 204.127.128.0/17
- show route protocol bgp validation-state valid

You can also log into a public Cisco here:
rpki-rtr.ripe.net
telnet username: ripe
no password

Try commands such as:
- sh ip bgp rpki table
- sh ip bgp rpki server
- sh ip bgp 93.175.146.0/24
- sh ip bgp ipv6 unicast rpki table
- sh ip bgp ipv6 unicast 2001:630::/32

Both routers are configured along these lines:
https://www.ripe.net/certification/router-configuration

and talk to the RIPE NCC RPKI Validator service available here:
https://www.ripe.net/certification/tools-and-resources

Try it out, and give feedback!

Cheers,

Alex

P.S. RFCs 6480-6493 have been published. A big thank you goes out to all the 
people who made that possible.


On 6 Feb 2012, at 08:59, Mark Tinka wrote:

 On Monday, February 06, 2012 03:06:24 PM Christopher Morrow 
 wrote:
 
 do you have customers with 10k long prefix lists? it gets
 hard when the lists get long, or the data is for
 downstream folks of your customer. Good that someone's
 checking though, I'd love to see this part automated.
 
 No, we don't have customers with 10,000-long prefix lists, 
 but we have planned to implement automation (either using 
 the IRR Toolset or home-grown solutions) to make this 
 possible as a means to scaling, should that time arise.
 
 As it is now, throwing NOC staff at the problem for the 
 volumes we have works well enough. But this is, by no means, 
 a panacea as we scale up.
 
 Heck, one must even worry whether a some router 
 configurations can take that many lines. But there are other 
 ways around that.
 
 RPKI doesn't necessarily mean that the router knows
 anything about certificates in the short-term. I think
 there's a time when 'the resource certification system'
 (which is really, today, the rpki) holds cert/roa data
 that you could use to filter what the IRR tells you for
 a customer. You could even do this in any automated
 manner!
 
 Well, given validation information will be available within 
 a network, one may use it in non-obvious ways to implement 
 policy.
 
 The time between the previous and next paragraphs though
 is when all isp's will need to beat the drums with their
 customers saying: Hey, you REALLY need to get that shit
 into the 'resource certification system' (rpki), NOW.
 (because shortly we'll stop accepting your invalid
 routes... and then the interwebs won't be able to find
 you, and we'll all be sad.)
 
 Well, we have all seen how doing this with DNSSEC, IPv6 and 
 4-byte ASN's worked out.
 
 We need to understand that different operators and different 
 customers will have varying reasons as to why they can't yet 
 do the right thing. There is abundant evidence of this 
 with other similar initiatives.
 
 Adoption will have to be incremental. During that time, the 
 Internet must not break.
 
 sure... it's not working so well though :(
 
 Not for lack of having some kind of solution.
 
 What we have today may not be the best, most scalable 
 option, but it is one nonetheless. Automating it (like what 
 RPSL does) is how you can make it scale to some extent, but 
 it's still the same solution.
 
 We can't just sit around waiting for RPKI. There will be 
 some reason why some of us can't deploy it, while someone 
 else is thinking up its successor. Rinse, repeat.
 
 Mark.

Re: Why not to use RPKI (Was Re: Argus: a hijacking alarm system)

[Alex Band]

If you want to play around with RPKI Origin Validation, you can download the 
RIPE NCC RPKI Validator here: http://ripe.net/certification/tools-and-resources
It's simple to set up and use: just unzip the package on a *NIX system, run 
./bin/rpki-validator and browse to http://localhost:8080

EuroTransit have a public one running here:
http://rpki01.fra2.de.euro-transit.net:8080/

You can see it's pointing to several Trust Anchors, downloads and validates all 
ROA periodically, you can apply ignore filters and white lists, see a BGP 
announcement validity preview based on route collector data, integrates with 
existing (RPSL based) workflows and can talk to RPKI-capable routers.

If you want to get an idea of how an RPKI-capable router would be configured, 
here's some sample config for Cisco and Juniper:
http://www.ripe.net/certification/router-configuration

You can also log into a public RPKI-capable Juniper here: 193.34.50.25, 
193.34.50.26
telnet username: rpki
password: testbed

With additional documentation available here:
http://rpki01.fra2.de.euro-transit.net/documentation.html

Have fun,

Alex

On 20 Jan 2012, at 13:08, Arturo Servin wrote:

 
   You could use RPKI and origin validation as well.
 
   We have an application that does that. 
 
   http://www.labs.lacnic.net/rpkitools/looking_glass/
 
   For example you can periodically check if your prefix is valid:
 
 http://www.labs.lacnic.net/rpkitools/looking_glass/rest/valid/cidr/200.7.84.0/23/
 
   If it were invalid for a possible hijack it would look like:
 
 http://www.labs.lacnic.net/rpkitools/looking_glass/rest/invalid/cidr/200.31.18.0/24/
 
   Or you can just query for any state:
 
 http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/cidr/200.31.12.0/22/
 
 
 
 Regards,
 as
 
 On 20 Jan 2012, at 07:47, Yang Xiang wrote:
 
 Hi,
 
 I build a system ‘Argus’ to real-timely alert prefix hijackings.
 Argus monitors the Internet and discovers anomaly BGP updates which caused
 by prefix hijacking.
 When Argus discovers a potential prefix hijacking, it will advertise it in
 a very short time,
 both in our website (http://argus.csnet1.cs.tsinghua.edu.cn) and the
 mailing list (ar...@csnet1.cs.tsinghua.edu.cn).
 
 Argus has been running in the Internet for more than eight months,
 it usually can discover potential prefix hijackings in ten seconds after
 the first anomaly BGP update announced.
 Several hijacking alarms have been confirmed by network operators.
 For example: http://argus.csnet1.cs.tsinghua.edu.cn/fingerprints/61544/ has
 been confirmed by the network operators of AS23910 and AS4538,
 it was a prefix hijacking caused by a mis-configuration of route filter.
 
 If you are interest in BGP security, welcome to visit our website and
 subscribe the mailing list.
 If you are interest in the system itself, you can find our paper which
 published in ICNP 2011 (FIST workshop)
 http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=6089080.
 
 Hope Argus will be useful for you.
 _
 Yang Xiang . about.me/xiangyang
 Ph.D candidate. Tsinghua University
 Argus: argus.csnet1.cs.tsinghua.edu.cn
 
 

RPKI in the real world: using MaxLength

[Alex Band]

The RIPE NCC is running their Resource Certification system for a couple of 
months now, and we've got quite a number of prefixes covered by ROAs in the 
repository by now. So I decided to have a look at how people are creating their 
ROAs and in particular how the 'Maximum Length' feature is used, which 
authorises the AS to deaggregate the prefix to the specified point.

We compared the repository to the prefixes seen by our RIS route collectors. It 
gives a good indication how people are using this option, and what the effects 
are when people base routing decisions on validation results.

You can read the article here:
https://labs.ripe.net/Members/AlexBand/using-the-maximum-length-option-in-roas

I'm interested to hear if you think we should change our implementation, and 
what choice you think is the best.

-Alex

Video explaining [RPKI] Resource Certification

[Alex Band]

Under the NRO flag, we have just released a short video about Resource 
Certification, giving a high-level explanation of what it is and why it is 
important for your organisation: 
http://youtu.be/rH3CPosGNjY

I hope to release another video going into more detail, outlining what it means 
practically for an operator. To get an idea of the practical side for now, here 
is a video we released earlier on how to set up and use the hosted Resource 
Certification service the RIPE NCC provides:
http://youtu.be/Q0C0kEYa1d8

Kind regards,

Alex Band
Product Manager, RIPE NCC

Re: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database)

[Alex Band]

On 1 Feb 2011, at 22:20, Owen DeLong wrote:

 
 On Feb 1, 2011, at 9:14 AM, Christopher Morrow wrote:
 
 On Sun, Jan 30, 2011 at 2:55 PM, Martin Millnert milln...@gmail.com wrote:
 Here be dragons,
 snip
 It should be fairly obvious, by most recently what's going on in
 Egypt, why allowing a government to control the Internet is a Really
 Bad Idea.
 
 
 how is the egypt thing related to rPKI?
 How is the propsed rPKI work related to gov't control?
 
 RPKI is a big knob governments might be tempted to turn.

Of course we looked into this, cause we're running our service from Amsterdam, 
the Netherlands. The possibilities for law enforcement agencies to take 
measures against the Resource Certification service run by the RIPE NCC are 
extremely limited. Under Dutch law, the process of certification, as well as 
resource certificates themselves, do not qualify as goods that are capable of 
being confiscated.

Then of course, the decision making process always lies in the hands of the 
network operator. Only if a government would mandate an ISP to respect an 
invalid ROA and drop the route, it would be effective. 

So *both* these things would have to happen before there is an operational 
issue. Like you've seen in Egypt, pulling the plug is easier...

YMMV on your side of the pond.

Alex Band
Product Manager, RIPE NCC

smime.p7s
Description: S/MIME cryptographic signature

Re: Level 3's IRR Database

[Alex Band]

On 31 Jan 2011, at 19:40, Dongting Yu wrote:

 On Mon, Jan 31, 2011 at 6:17 PM, Andree Toonk andree+na...@toonk.nl wrote:
 
 Now AS17557 start to announce a more specific: 208.65.153.0/24. Validators
 would classify this as Invalid (2).
 
 Would it be classified as invalid or unknown? Or are both possible
 depending on whether 208.65.153.0/24 is signed? Do these two cases
 differ in this particular case?

No, it would classify as invalid because as Randy said earlier in the thread:

  Before issuing a ROA for a block, an operator MUST ensure that any
  sub-allocations from that block which are announced by others (e.g.
  customers) have ROAs in play.  Otherwise, issuing a ROA for the
  super-block will cause the announcements of sub-allocations with no
  ROAs to be Invalid.

In a ROA you can specify a maximum length, authorising the AS to deaggregate 
the prefix to the point you specify. If no max length is specified, the AS is 
only allowed to announce the prefix as indicated.

So if the ROA for AS36561 with prefix 208.65.152.0/22 was created with no 'max 
length' specified, the /24 that AS17557 announces would be invalid because  
it's the wrong prefix length *and* because it's the wrong origin AS. If a max 
length of /24 was specified in the ROA, it would be invalid only because of the 
latter.

There could be another ROA for 208.65.153.0/24 specifically, but obviously not 
for AS17557, so again invalid because of the wrong origin AS. Pakistan Telecom 
also can't create a valid ROA, because they are not the holder of the address 
space.

-Alex

Re: [arin-announce] ARIN Resource Certification Update

[Alex Band]

On 31 Jan 2011, at 04:25, Paul Vixie wrote:

 the reasoning you're describing is what we had in mind when we built DLV
 as an early deployment aid for DNSSEC.  we had to break stiction where
 if there were no validators there would be incentive to sign, and if
 there were no signatures there would be no incentive to validate.  are
 you likewise proposing the hosted solution only as an early deployment
 aid?  

We primarily offer hosting it is something our community want. You can now see 
in the adoption numbers that is true. It makes the entry barrier into the 
system as low as possible, which – apart from being a good thing in itself – 
aids deployment. 

 i'm really quite curious as to whether you'll continue operating
 an RPKI hosting capability even if it becomes unnec'y (as proved some
 day if many operators of all sizes demonstrate capability for up/down).
 if so, can you share the reasoning behind that business decision?

We're building and maintaining this with membership fees. Why would we keep 
something operational our members no longer want and need using their money? I 
sincerely doubt we'll ever get to that point soon, but we'll see.

-Alex Band

smime.p7s
Description: S/MIME cryptographic signature

Re: [arin-announce] ARIN Resource Certification Update

[Alex Band]

Paul,

I think my question is very pertinent. Of course the number of signed prefixes 
directly influences the number of validators. Do you think the RIPE NCC 
Validator tool would have been downloaded over 100 times in the last month if 
there were only 5 certified prefixes?

In my opinion, the widespread availability of signed prefixes and mature 
validation methods is key to the global success of resource certification. I 
agree that small differences in the size of the set of signed routes don't 
matter on a (relatively) short term, but the reality is that the difference 
would be *enormous* if we wouldn't offer a hosted solution.

Practically, in the real world, why would anyone invest time and effort in 
altering their current BGP decision making process to accommodate for resource 
certification if the technology is on nobody's radar, it's hard to get your 
feet wet and there are just a handful of certified prefixes out there. Wouldn't 
it be good if network operators think: Because it helps increase global 
routing security, it's easy to get started and lots of people are already 
involved, perhaps I should have a look at (both sides of) resource 
certification too. 

This is why I believe – and our adoption numbers prove – that the entry barrier 
to the system should be as low as possible, both on the signing side and the 
validation side. Once some of the people that are using the hosted platform now 
decide they would rather run their own non-hosted solution at a later stage, 
that would be even better. That immediately solves the private key situation. 
But there will always be a group happy to rely on the hosted model, and we 
cater to that.

Because of the path we chose there is already a lot of operational experience 
being gained, resulting in a large amount of feedback from a wide range of 
users. This helps us shape the certification system and the validator tool, 
which aids quality and usability. To me, that makes a lot of business sense. 
This is why I think there should be as much certified address space available 
as possible. Otherwise this will stay a niche technology until perhaps a major 
event causes people to wake up (and hopefully take action). If certification 
has reached the necessary level of maturity at that point remains to be seen. 
Furthermore, preventing (future) malicious hijacking is not the *only* reason 
the Internet community needs better routing security, the accidental route 
leaking that happens every day is reason enough.

-Alex

On 29 Jan 2011, at 23:00, Paul Vixie wrote:

 From: Alex Band al...@ripe.net
 Date: Sat, 29 Jan 2011 16:26:55 +0100
 
 ... So the question is, if the RIPE NCC would have required everyone
 to run their own certification setup using the open source tool-sets
 Randy mentions, would there be this much certified address space now?
 
 i don't agree that that question is pertinent.  in deployment scenario
 planning i've come up with three alternatives and this question is not
 relevant to any of them.  perhaps you know a fourth alternative.  here
 are mine.
 
 1. people who receive routes will prefer signed vs. unsigned, and other
 people who can sign routes will sign them if it's easy (for example,
 hosted) but not if it's too hard (for example, up/down).
 
 2. same as #1 except people who really care about their routes (like
 banks or asp's) will sign them even if it is hard (for example, up/down).
 
 3. people who receive routes will ignore any unsigned routes they hear,
 and everyone who can sign routes will sign them no matter how hard it is.
 
 i do not expect to live long enough to see #3.  the difference between #1
 and #2 depends on the number of validators not the number of signed routes
 (since it's an incentive question).  therefore small differences in the
 size of the set of signed routes does not matter very much in 2011, and
 the risk:benefit profile of hosted vs. up/down still matters far more.
 
 Looking at the depletion of IPv4 address space, it's going to be
 crucially important to have validatable proof who is the legitimate
 holder of Internet resources. I fear that by not offering a hosted
 certification solution, real world adoption rates will rival those of
 IPv6 and DNSSEC. Can the Internet community afford that?
 
 while i am expecting a rise in address piracy following depletion, i am
 not expecting #3 (see above) and i think most of the piracy will be of
 fallow or idle address space that will therefore have no competing route
 (signed or otherwise).  this will become more pronounced as address
 space holders who care about this and worry about this sign their routes
 -- the pirates will go after easier prey.  so again we see no material
 difference between hosted and up/down on the deployment side or if there
 is a difference it is much smaller than the risk:benefit profile
 difference on the provisioning side.
 
 in summary, i am excited about RPKI and i've been pushing hard for in
 both my day job

Re: [arin-announce] ARIN Resource Certification Update

[Alex Band]

John,

Thanks for the update. With regards to offering a hosted solution, as you know 
that is the only thing the RIPE NCC currently offers. We're developing support 
for the up/down protocol as I write this.

To give you some perspective, one month after launching the hosted RIPE NCC 
Resource Certification service, 216 LIRs are using it in the RIPE Region and 
created 169 ROAs covering 467 prefixes. This means 40151 /24 IPv4 prefixes and 
7274499 /48 IPv6 prefixes now have a valid ROA associated with them.

I realize a hosted solution is not ideal, we're very open about that. But at 
least in our region, it seems there are quite a number of organizations who 
understand and accept the security trade-off of not being the owner of the 
private key for their resource certificate and trust their RIR to run a 
properly secured and audited service. So the question is, if the RIPE NCC would 
have required everyone to run their own certification setup using the open 
source tool-sets Randy mentions, would there be this much certified address 
space now? 

Looking at the depletion of IPv4 address space, it's going to be crucially 
important to have validatable proof who is the legitimate holder of Internet 
resources. I fear that by not offering a hosted certification solution, real 
world adoption rates will rival those of IPv6 and DNSSEC. Can the Internet 
community afford that?

Alex Band
Product Manager, RIPE NCC

P.S. For those interested in which prefixes and ASs are in the RIPE NCC ROA 
Repository, here is the latest output in CSV format:
http://lunimon.com/valid-roas-20110129.csv



On 24 Jan 2011, at 21:33, John Curran wrote:

 Copy to NANOG for those who aren't on ARIN lists but may be interested in 
 this info.
 FYI.
 /John
 
 Begin forwarded message:
 
 From: John Curran jcur...@arin.netmailto:jcur...@arin.net
 Date: January 24, 2011 2:58:52 PM EST
 To: arin-annou...@arin.netmailto:arin-annou...@arin.net 
 arin-annou...@arin.netmailto:arin-annou...@arin.net
 Subject: [arin-announce] ARIN Resource Certification Update
 
 ARIN continues its preparations for offering production-grade resource 
 certification
 services for Internet number resources in the region.  ARIN recognizes the 
 importance
 of Internet number resource certification in the region as a key element of 
 further
 securing Internet routing, and plans to rollout Resource Public Key 
 Infrastructure (RPKI)
 at the end of the second quarter of 2011 with support for the Up/Down 
 protocol for those
 ISPs who wish to certify their subdelegations via their own RPKI 
 infrastructure.
 
 ARIN continues to evaluate offering a Hosting Resource Certification service 
 for this
 purpose (as an alternative to organizations having to run their own RPKI 
 infrastructure),
 but at this time it remains under active consideration and is not committed.  
  We look
 forward to discussing the need for this type of service and the organization 
 implications
 atour upcoming ARIN Members Meeting in April in San Juan, PR.
 
 FYI,
 /John
 
 John Curran
 President and CEO
 ARIN
 
 ___
 ARIN-Announce
 You are receiving this message because you are subscribed to
 the ARIN Announce Mailing List 
 (arin-annou...@arin.netmailto:arin-annou...@arin.net).
 Unsubscribe or manage your mailing list subscription at:
 http://lists.arin.net/mailman/listinfo/arin-announce
 Please contact i...@arin.net if you experience any issues.
 
 



smime.p7s
Description: S/MIME cryptographic signature

Re: [ncc-services-wg] RPKI Resource Certification: building features

[Alex Band]

On 4 Oct 2010, at 23:18, Randy Bush wrote:


1) We have not implemented support for this yet. We plan to go live
with the fully hosted version first and extend it with support for
non-hosted systems around Q2/Q3 2011.


this is a significant slip from the 1q11 we were told in prague.  care
to explain.


Let me run you through the roadmap and the motivation for our choices  
at RIPE61. In short, everything we do is about providing *value* for  
our membership and the community. This means that with the resources  
we have, we have to make a choice between (1) offering a solution with  
every feature under the sun, but contains little value and usability  
or (2) we choose to do a phased approach where the entry barrier into  
the system is low, hassle is taken away from the operator, value and  
user-friendlyness is high while still being standards compliant and  
keeping the operator in the driver's seat. Soon we'll get to the full  
package where all options, like running your own CA, are available. It  
perhaps just isn't done in the order that a purist would like to see.


Let me illustrate with two examples: I've delivered full day training  
courses on Routing Registry and DNSSEC. With the RR course, by the  
time I was done explaining how to use the IRRToolset to aid in making  
routing decisions based on the IRR, people had given up and decided  
that doing it manually was easier. Like you said at RIPE60: people  
are voting with their feet. In the DNSSEC training, by the time I was  
done explaining how to do a manual key roll-over, most LIRs decided  
'this is not for me, the cure is worse than the disease'.


This is why I want to get back to my original point, Randy. You agreed  
in your first reply to me that something has to be done to create an  
easy way to get started with the system. We can provide a full,  
standards-compliant solution with up/down and every other feature, but  
how is that going to get all ~350,000 prefixes and ~35,000 ASs into  
the system with ROAs? Manually? I proposed an IRR+BGP import system as  
a value-added tool to help a network operator get started making ROAs.  
That's a pretty good starting point. Where do you suggest we go from  
here?


Of course I appreciate everyone else's response to this thread as  
well! :)


Cheers,

-Alex

Re: RPKI Resource Certification: building features

[Alex Band]

And here is my reply to them...

On Mon, October 4, 2010 04:38, Owen DeLong wrote:


On Oct 3, 2010, at 7:26 PM, Randy Bush wrote:


Do you think there is value in creating a system like this?


yes.  though, given issues of errors and deliberate falsifications,  
i am

not entirely comfortable with the whois/bgp combo being considered
formally authoritative.  but we have to do something.


But blindly considering whois/BGP authoritative is not what I am
proposing. I want to confront the network operator with what is  
registered

in the IRR and what is seen in BGP, and let the human element make
decisions and corrections, improving data quality in the process.


Are there any glaring holes that I missed


yes.  the operator should be able to hold the private key to their
certificate(s) or the meaning of 'private key' and the security
structure of the [ripe part of the] rpki is a broken.

randy


In the hosted implementation the RIPE NCC currently has, only a  
registered
contact for an LIR with whom we have a business relationship has  
access to

the secured LIR Portal in which the Certification system is embedded.

The reason to offer a hosted system initially, is to take away the  
burden

from an LIR of having to run their own Certificate Authority. We offer a
service that makes the entry barrier for Certification as low as  
possible.

Properly running your own CA, with all the crypto aspects, is no small
feat for a lot of LIRs (technically, but perhaps more psychologically).
You may argue that it's easy and cheap to do yourself, but just look at
adoption rates and levels of IPv6 and DNSSEC *at an LIR level* to see  
what

reality is like.

After the production launch on 1 January 2011, the next step we will  
take

is to implement the up/down protocol, allowing people to run their own
Certificate Authority if they choose to do so. We plan to roll this  
out in

the first half of 2011. We'll go one step further by having our software
certified by an external independent company, and releasing it as open
source to the Community, so they can be sure they adopt a robust  
system if

they choose our package.

So in the end our implementation is not 'broken' as you say, it is in he
middle of a planned, phased approach. Not everything is possible yet and
that is a deliberate decision.


I'll go a step further and say that the resource holder should be
the ONLY holder of the private key for their resources.

Owen


If you're saying that ISPs can only participate in an RPKI scheme if  
they

run their own Certificate Authority, then I think that would practically
ruin the chances of Certification actually ever taking off on a large
scale.

-Alex


On 4 Oct 2010, at 10:54, Alex Band wrote:

The thread got a bit torn apart due to some cross posting, so here  
are Randy and Owen's replies to keep it all together:


On Oct 3, 2010, at 7:26 PM, Randy Bush wrote:

Do you think there is value in creating a system like this?


yes. though, given issues of errors and deliberate falsifications,  
i am not entirely comfortable with the whois/bgp combo being  
considered formally authoritative. but we have to do something.

Are there any glaring holes that I missed


yes. the operator should be able to hold the private key to their  
certificate(s) or the meaning of 'private key' and the security  
structure of the [ripe part of the] rpki is a broken.

randy
I'll go a step further and say that the resource holder should be  
the ONLY holder of the private key for their resources.

Owen

On 3 Oct 2010, at 19:06, Alex Band wrote:

Most of the discussions around RPKI Resource Certification that  
have been held up to now have largely revolved around  
infrastructure and policy topics. I would like to move away from  
that here and discuss what kind of value and which features can be  
offered with Certification for network administrators around the  
world. Because in the end, the goal is to make Internet routing  
more robust and create a more reliable method for network operators  
to make routing decisions.


We all know about the shortcomings of the IRR system and that just  
half of all prefixes on the Internet have a route object associated  
with them (http://bgpmon.net/blog/?p=140). However, it does mean  
that there is ton of valuable information in the IRRs, whereas the  
Certification system needs to start from scratch. Based on many  
discussion I've had with members and the Community, here is my idea  
for a Route Origin Authorisation** (ROA) wizard that retrieves IRR  
information, compares it to real world routing and uses that for  
the creation of ROA Specifications. This has a number of benefits:


- Network operators don't have to create their routing policy in  
the Certification system from scratch
- Because a comparison between is done the IRR and RIS (http://ripe.net/ris/ 
), only accurate up-to-date information is added to the  
Certification system
- The accuracy of the IRR is increased

Re: RPKI Resource Certification: building features

[Alex Band]

The thread got a bit torn apart due to some cross posting, so here are  
Randy and Owen's replies to keep it all together:


On Oct 3, 2010, at 7:26 PM, Randy Bush wrote:

Do you think there is value in creating a system like this?


yes. though, given issues of errors and deliberate falsifications, i  
am not entirely comfortable with the whois/bgp combo being  
considered formally authoritative. but we have to do something.

Are there any glaring holes that I missed


yes. the operator should be able to hold the private key to their  
certificate(s) or the meaning of 'private key' and the security  
structure of the [ripe part of the] rpki is a broken.

randy
I'll go a step further and say that the resource holder should be the  
ONLY holder of the private key for their resources.

Owen

On 3 Oct 2010, at 19:06, Alex Band wrote:

Most of the discussions around RPKI Resource Certification that have  
been held up to now have largely revolved around infrastructure and  
policy topics. I would like to move away from that here and discuss  
what kind of value and which features can be offered with  
Certification for network administrators around the world. Because  
in the end, the goal is to make Internet routing more robust and  
create a more reliable method for network operators to make routing  
decisions.


We all know about the shortcomings of the IRR system and that just  
half of all prefixes on the Internet have a route object associated  
with them (http://bgpmon.net/blog/?p=140). However, it does mean  
that there is ton of valuable information in the IRRs, whereas the  
Certification system needs to start from scratch. Based on many  
discussion I've had with members and the Community, here is my idea  
for a Route Origin Authorisation** (ROA) wizard that retrieves IRR  
information, compares it to real world routing and uses that for the  
creation of ROA Specifications. This has a number of benefits:


- Network operators don't have to create their routing policy in the  
Certification system from scratch
- Because a comparison between is done the IRR and RIS (http://ripe.net/ris/ 
), only accurate up-to-date information is added to the  
Certification system
- The accuracy of the IRR is increased as a bonus, and is achieved  
without leaving the wizard


Ideally, a network operator should be able to manage and publish  
their routing policy – both for the IRR and Certification – from one  
single interface.


Here are the basic steps for the wizard after a certificate is  
generated:


1. Start ROA Wizard

2. Detect IRR information using the AS numbers in the Certificate,  
like for example:

http://www.db.ripe.net/whois?searchtext=AS286inverse_attributes=originform_type=simple

3: Compare results with RIS using RRCC/Netsense, like for example:
http://www.ris.ripe.net/cgi-bin/rrccng/query.cgi?target=AS286

4: Allow user to flag which ROA specifications they would actually  
like to create, based on the IRR and RRCC/Netsense results.


5: Allow user to create additional ROA Specifications

6: Detect which maintainer is used for the route objects in the IRR

7: Allow user to specify maintainer password/pgp key, so all route  
objects are updated/removed/added based on the ROAs that were  
created. This makes sure the data in the IRR and the Certification  
system is consistent.


8: Save and publish ROAs and route objects

Do you think there is value in creating a system like this? Are  
there any glaring holes that I missed, or something that could be  
added? I'm looking forward to your feedback.


Alex Band
RIPE NCC
http://ripe.net/certification


** The certification system largely revolves around three main  
elements: (1) the Certificate, that offers validated proof of  
holdership of an Internet Resource, (2) the Route Orgin  
Authorisation Object (ROA), a standardised document that states that  
the holder of a certain prefix authorises a particular AS to  
announce that prefix and (3) the Validator, which relying parties,  
i.e. your peers, can use to validate certificates and ROAs.

Re: [ncc-services-wg] RPKI Resource Certification: building features

[Alex Band]

On Mon, October 4, 2010 04:38, Owen DeLong wrote:

 On Oct 3, 2010, at 7:26 PM, Randy Bush wrote:

 Do you think there is value in creating a system like this?

 yes.  though, given issues of errors and deliberate falsifications, i am
 not entirely comfortable with the whois/bgp combo being considered
 formally authoritative.  but we have to do something.

But blindly considering whois/BGP authoritative is not what I am
proposing. I want to confront the network operator with what is registered
in the IRR and what is seen in BGP, and let the human element make
decisions and corrections, improving data quality in the process.

 Are there any glaring holes that I missed

 yes.  the operator should be able to hold the private key to their
 certificate(s) or the meaning of 'private key' and the security
 structure of the [ripe part of the] rpki is a broken.

 randy

In the hosted implementation the RIPE NCC currently has, only a registered
contact for an LIR with whom we have a business relationship has access to
the secured LIR Portal in which the Certification system is embedded.

The reason to offer a hosted system initially, is to take away the burden
from an LIR of having to run their own Certificate Authority. We offer a
service that makes the entry barrier for Certification as low as possible.
Properly running your own CA, with all the crypto aspects, is no small
feat for a lot of LIRs (technically, but perhaps more psychologically).
You may argue that it's easy and cheap to do yourself, but just look at
adoption rates and levels of IPv6 and DNSSEC *at an LIR level* to see what
reality is like.

After the production launch on 1 January 2011, the next step we will take
is to implement the up/down protocol, allowing people to run their own
Certificate Authority if they choose to do so. We plan to roll this out in
the first half of 2011. We'll go one step further by having our software
certified by an external independent company, and releasing it as open
source to the Community, so they can be sure they adopt a robust system if
they choose our package.

So in the end our implementation is not 'broken' as you say, it is in he
middle of a planned, phased approach. Not everything is possible yet and
that is a deliberate decision.

 I'll go a step further and say that the resource holder should be
 the ONLY holder of the private key for their resources.

 Owen

If you're saying that ISPs can only participate in an RPKI scheme if they
run their own Certificate Authority, then I think that would practically
ruin the chances of Certification actually ever taking off on a large
scale.

-Alex

RPKI Resource Certification: building features

[Alex Band]

Most of the discussions around RPKI Resource Certification that have been held 
up to now have largely revolved around infrastructure and policy topics. I 
would like to move away from that here and discuss what kind of value and which 
features can be offered with Certification for network administrators around 
the world. Because in the end, the goal is to make Internet routing more robust 
and create a more reliable method for network operators to make routing 
decisions.

We all know about the shortcomings of the IRR system and that just half of all 
prefixes on the Internet have a route object associated with them 
(http://bgpmon.net/blog/?p=140). However, it does mean that there is ton of 
valuable information in the IRRs, whereas the Certification system needs to 
start from scratch. Based on many discussion I've had with members and the 
Community, here is my idea for a Route Origin Authorisation** (ROA) wizard that 
retrieves IRR information, compares it to real world routing and uses that for 
the creation of ROA Specifications. This has a number of benefits:

- Network operators don't have to create their routing policy in the 
Certification system from scratch
- Because a comparison between is done the IRR and RIS (http://ripe.net/ris/), 
only accurate up-to-date information is added to the Certification system
- The accuracy of the IRR is increased as a bonus, and is achieved without 
leaving the wizard

Ideally, a network operator should be able to manage and publish their routing 
policy – both for the IRR and Certification – from one single interface. 

Here are the basic steps for the wizard after a certificate is generated:

1. Start ROA Wizard

2. Detect IRR information using the AS numbers in the Certificate, like for 
example:
http://www.db.ripe.net/whois?searchtext=AS286inverse_attributes=originform_type=simple

3: Compare results with RIS using RRCC/Netsense, like for example:
http://www.ris.ripe.net/cgi-bin/rrccng/query.cgi?target=AS286

4: Allow user to flag which ROA specifications they would actually like to 
create, based on the IRR and RRCC/Netsense results.

5: Allow user to create additional ROA Specifications

6: Detect which maintainer is used for the route objects in the IRR

7: Allow user to specify maintainer password/pgp key, so all route objects are 
updated/removed/added based on the ROAs that were created. This makes sure the 
data in the IRR and the Certification system is consistent. 

8: Save and publish ROAs and route objects

Do you think there is value in creating a system like this? Are there any 
glaring holes that I missed, or something that could be added? I'm looking 
forward to your feedback.

Alex Band
RIPE NCC
http://ripe.net/certification


** The certification system largely revolves around three main elements: (1) 
the Certificate, that offers validated proof of holdership of an Internet 
Resource, (2) the Route Orgin Authorisation Object (ROA), a standardised 
document that states that the holder of a certain prefix authorises a 
particular AS to announce that prefix and (3) the Validator, which relying 
parties, i.e. your peers, can use to validate certificates and ROAs.

Re: Addressing plan exercise for our IPv6 course

[Alex Band]

Hi Antonio,

That diagram looks interesting. We currently use slides with a bunch  
of animation to explain to this concept, but it may be nice to have  
something like this that people can keep as a printed version.


By the way, this is what we think two possible answers are: http://bit.ly/9V5GfU

There are more options, but these two are the most convenient weighing  
all the up and downsides. Does anyone disagree?


Cheers,

Alex

On 22 Jul 2010, at 05:34, Antonio M. Moreiras wrote:


I think it is a very well planned exercise. I would suggest you not to
be straight in its execution. In some point, you could ask if the
decisions would be the same in cases with different conditions: more
pops, more users, less users, etc...

We have a similar exercise in our training at NIC.br and we use this
diagram to help the trainees understand the addresses:
http://www.ipv6.br/pub/IPV6/MenuIPv6CursoPresencial/enderec-v6.pdf...
Maybe it could be useful.

Moreiras.

Em 22/07/10 00:19, Mark Smith escreveu:



I'm curious to hear if you think it's clear and useful.

Cheers,

Alex Band
RIPE NCC Trainer

(Big props go to Marco Hogewoning @XS4ALL)

Addressing plan exercise for our IPv6 course

[Alex Band]

We've been working on an exercise for the IPv6 training course we deliver for 
LIRs. It's aimed at people who are unfamiliar with IPv6, so the goal is to get 
them to the point where once they get their IPv6 /32 allocation, they have a 
good idea how to subdivide prefixes over their network and how to write an 
addressing plan.

Here's a PDF with the exercise (two pages A3): http://bit.ly/c7jZRJ

I'm curious to hear if you think it's clear and useful.

Cheers,

Alex Band
RIPE NCC Trainer

(Big props go to Marco Hogewoning @XS4ALL)

Re: Addressing plan exercise for our IPv6 course

[Alex Band]

Hi Owen,

The RIPE NCC does actually ask for an addressing plan before we allocate a /32 
IPv6, so I didn't phrase my opening email 100% accurate; we don't just blindly 
hand it out. On the other hand, we don't do rigorous checks if it is actually 
any good, or appropriate for their network.

What we see in the real world, is that many LIRs haven't requested a v6 
allocation yet because they simply wouldn't know where to begin making an 
addressing plan. Then there is the group that sent in an addressing plan, got 
their allocation, and starting trying some things implementing it. In a lot of 
cases, they get stuck because reality was a lot different than what they 
thought it would be, and put the allocation in a drawer since it's not that 
urgent yet.

This exercise is for both those groups. Just to get them going, understanding 
the basics.

Cheers,

Alex

On 21 Jul 2010, at 21:53, Owen DeLong wrote:

 First, think this is very wrong teaching.  I think we should be stressing the 
 need to develop an addressing and subdivision plan FIRST, then request an 
 appropriate amount of IPv6 space.
 
 I will endeavor to review and comment on the exercises later, but I wanted to 
 convey this point first.
 
 Owen
 
 
 Sent from my iPad
 
 On Jul 21, 2010, at 11:57 AM, Alex Band al...@ripe.net wrote:
 
 We've been working on an exercise for the IPv6 training course we deliver 
 for LIRs. It's aimed  at people who are unfamiliar with IPv6, so the goal is 
 to get them to the point where once they get their IPv6 /32 allocation, they 
 have a good idea how to subdivide prefixes over their network and how to 
 write an addressing plan.
 
 Here's a PDF with the exercise (two pages A3): http://bit.ly/c7jZRJ
 
 I'm curious to hear if you think it's clear and useful.
 
 Cheers,
 
 Alex Band
 RIPE NCC Trainer
 
 (Big props go to Marco Hogewoning @XS4ALL)
 

IPv6 Interview: XS4ALL rolls out native v6 to DSL customers

[Alex Band]

http://www.youtube.com/watch?v=f3WcWBIQ11A

Marco Hogewoning of Dutch ISP XS4ALL talks about the roll out of IPv6  
in their 300,000 customer network. German modem vendor AVM supplies  
them with a CPE that supports native IPv6, although it does have some  
limitations that need to be ironed out. Marco talks about how they got  
in touch with them, how they handle the spec and the issues, and how  
the project gained traction when the Sales department got interested.


Enjoy,

-Alex

IPv6 Interview: Martin J. Levy of Hurricane Electric

[Alex Band]

http://www.youtube.com/watch?v=p47m5XVt4WQ

Time for another interview. Martin Levy talks about his experiences,  
what kind of customers they cater to, what worked and what didn't work  
during deployment, and what internal strategy they had.


We recorded an interview with the Swedish government this week, which  
we'll be editing shortly. If you want specific topics to be covered,  
or there are specific people or industry players we should talk to in  
future interviews, please let me know and we'll try to get them in  
front of a camera.


Enjoy,

Alex

New IPv6 interview: Google on ipv6.google.com

[Alex Band]

Lorenzo Colitti, network engineer at Google, discusses the  
implementation of IPv6, which resulted in the launch of  
ipv6.google.com. He talks about the feedback they have received,  
future plans for making Google services available over IPv6  and what  
advice he would give to other companies.


http://www.youtube.com/watch?v=vFwStbTpr6E

Cheers,

Alex Band
RIPE NCC

New IPv6 Interview: David Freedman of Claranet

[Alex Band]

We recently added another IPv6 interview to our ipv6actnow.org and  
youtube pages. This time David Freedman talks about their planning and  
deployment, including addressing plans and training, as well as the  
MPLS issues that they faced.


http://www.youtube.com/watch?v=HQtbz1ahRxE

We plan to have interviews with Google up soon, as well as XS4ALL; the  
dutch ADSL provider who started rolling out IPv6 capable CPEs.


Enjoy,

Alex

Interview: Patrik Fältström on the role of go vernment in IPv6 deployment

[Alex Band]

We uploaded another interview: http://www.youtube.com/watch?v=zrE1TEan4Jo

To make sure we cover as many areas of the industry as possible, we  
asked Patrik Fältström on the role of government in IPv6 deployment.  
Patrik is Senior Consulting Engineer with Cisco, but has served as an  
advisor to the Swedish government on IT policy since 2003. In the  
interview, he makes a note about the American government as well.


I hope you enjoy it. If you have feedback on specific topics you would  
like to see covered in future interviews, please let us know. We  
appreciate your comments.


Alex Band
RIPE NCC

RIPE NCC does a series of interviews about IPv6 deployment

[Alex Band]

As part of our IPv6 training project, that consists of face to face  
training and on-line learning modules and testimonials, I am proud to  
announce the first in a series of interviews.


Andy Davidson of NetSumo ISP Consultancy discusses the IPv6 deployment  
they have done for their customers and themselves:

http://www.youtube.com/watch?v=QCcigLJJbvU

So far, we have interviewed 22 people from the community about their  
experiences and are very busy editing all the video material. In the  
coming months, you will be able to enjoy the rest of the interviews  
here:

http://www.youtube.com/user/RIPENCC

These interviews will also be published on our e-learning page and on  
our IPv6 Act Now website:

http://ripe.net/training/e-learning/
http://www.ipv6actnow.org/

Cheers,

Alex Band
RIPE NCC