Relying Party Resiliency Platform
The aim of this website is to experiment with RPKI repositories and certificate authorities, especially with the focus of causing unintended behaviour on relying party clients. I set up a couple of experiments to test relying party clients. You can test these scenarios too, by downloading one or more of the TALs below.
Your session ID is 0a507536-9b9e-4bd3-9456-295331d3b107. Use this session ID to check what your
relying party software is doing from the server's perspective by clicking the "View request data" link below.
It will start working once the first request comes in. This ID is randomly generated, and changes
everytime you visit the website. It is embedded in the TALs you download from this site, thus store it well.
Do not use any of these TALs in production! They are meant to cause interesting behaviour, and might break your server. You have been warned.
Running these TALs requires IPv6 support. Without IPv6 the hostname will not resolve. You can test whether IPv6 works by clicking here.
| Code | Description | Download |
|---|---|---|
| A | This repository contains a certificate that points to a repository ad infinitum. | Download the TAL |
| B | This repository returns a 429 response with a 1 day (86400 seconds) Retry-After value as header. | Download the TAL |
| C | This repository returns a 302 response with a redirect that never stops redirecting, but does not loop. | Download the TAL |
| D | This repository returns a gzip bomb, which is not valid XML. | Download the TAL |
| E | This repository keeps the connection open for a day before a response is returned, but does keep drip feeding new bytes to keep the connection alive. | Download the TAL |
| F | This repository serves a broken ROA with only an ASCII NUL character. | Download the TAL |
| G | This repository serves a billion laughs attack. | Download the TAL |
| H | This repository is both wide and deep (every child has 9 children). | Download the TAL |
| I | This repository contains a ROA that does not meet the requirements of a ROA. | Download the TAL |
| J | This repository contains ~2200 ROAs for one prefix, all with a different ASN. (Generating all ROAs takes ~10 minutes) | Download the TAL |
| K | This repository contains one ROA for 2200 prefixes, all with the same ASN. | Download the TAL |
| L | This repository links to 100 GiB of random data. | Download the TAL |
| M | This tries an XXE attack on an attribute. This should not be possible, as XXE are not allowed in attributes. | Download the TAL |
| N | This contains valid data with a stupendously long path. | Download the TAL |
| O | This contains valid data with a path that attempts to write to a folder up from where it should. | Download the TAL |
| P | This is a valid repository, nothing special. | Download the TAL |
| Q | This contains a large ASPA object. | Download the TAL |
Expected behaviour
One may ask what the expected behaviour is — what a relying party should do. Since these experiments do not reflect anything someone would realistically do, I think it is easier to answer the question what should not happen. Basically, anything strange that the subtree does should not affect the result of any other subtree (that is not a subset of the subtree). In other words, If you run this together with the normal TALs from the five RIRs, the program should still finish with the correct results for the five RIRs within a reasonable time (before the heat death of the universe, or before Soldier of Orange stops playing, whichever comes sooner). Do note that these repositories do not necessarily adhere to the RFCs - that is partially intentional, and partially a consequence of how things are set up.