RPKI - whether BGP routes are signed about internet.nl HOT 13 CLOSED

My understanding is that the first correspond to the complete test and the second to checks done against individual servers.

Correct. Each entry in the DomainTestTls table is a test for a single server.

On second thought I am not sure if that (central DomainTestRPKI and separate WebTestRPKI and MailTestRPKI) would work nicely for the RPKI case.

In TLS you have all the different results per IP/server.
With RPKI you have just results for IPs based on roles; that more closely resembles the IPv6 results were you have separate sections for NS, MX, Web. I believe that way would be easier to "do as the IPv6 models do".

Hope that makes sense.

from internet.nl.

Hi @maertsen!
Sorry for the delayed response but you happened to ask right at the start of my vacation :).

I would be happy to give a small tour here.

Some guidance for enabling and configuring the batch functionality on an Internet.nl installation can be found at documentation/Batch.md.

I have updated (#594) the above documentation to also include some initial short information/guidance for developers.

If you need more information or have specific questions feel free to send them over and I can answer them or schedule a meeting if it is more convenient!

from internet.nl.

(merged the documentation, added a note to the 1.4 release notes)

from internet.nl.

@maertsen, sorry it seems I missed this, but replied to your email with information that would cover the above questions.

from internet.nl.

Decided by steeringcmte on 2017-01-19 to keep issue in icebox.

from internet.nl.

1. RPKI signing wil be 5th test category in the website test and in the mail test.
2. Test category name: "IP addresses signed (RPKI)"
3. Consisting of 2 sections: "name servers" and "web server" (website test) / "name servers" and "mail servers" (email test)
4. Each section has 2 subtests: 1) RPKI existence and 2) RPKI validity
5. In the first subtest we check if ROA's exist for all IPv4 and IPv6 addresses (i.e. per name server, web server, mail server). In the second subtest we test if the found ROA's are valid.
6. Results first subtest "PKI existence ":

• Good: all IP addreses have ROA's (i.e. all have either Valid or Invalid status)
• Bad: not all IP addresses have ROA's (i.e. some or all have NotFound status)
• Tech table: details on existence with the following columns: Name/web/mail server | IP address | RPKI existent (yes/no)

7. Results second subtest "PKI validity":

• Good: all lP addresses have Valid ROA's
• Bad: one or more IP addresses have Invalid ROA's
• Not applicable: if none of the IP addresses have ROA's (i.e. all IP addresses have NotFound status)
• Tech table details on validity: Name/web/mail server | IP address | Status (Valid, Invalid, NotFound)

8. We might want to score RPKI in a similar way as we score DNSSEC. "DNSSEC bogus" leads to a greater negative score than "no DNSSEC available". We could do something similar for RPKI Invalids. But let's start with making it a recommended test first (i.e. no impact on score and providing a warning when the subtest is failed).

Further notes:

• The displaying of the test results for RPKI will be quite similar to the "Mail server domain(s)" section in the DNSSEC subtest results in the mail.
• This change will also impact the API on our batch server.

from internet.nl.

Voor RPKI ROA test van RIPE zie https://stat.ripe.net/

from internet.nl.

Feature request for 1.5, add it to connection test too

from internet.nl.

Feature request for 1.5, add it to connection test too

This issue (#30) regards the checking of RPKI signing (valid ROA's). We could do that for all the IP addresses (IPv4 and IPv6) found in the website and mail test, but also in the connection test for the user's IP addresses. Furthermore we could add RPKI verification (i.e. filtering of invalid ROA's) to the connection test. I made a seperate issue for the connection test (#552).

from internet.nl.

I've started working on this issue, based on the initial POC by @sinteur and the design by @baknu in #30 (comment).

from internet.nl.

I'm having trouble understanding how to best store results. It confuses me that there seem to be two patterns in the current codebase. @sinteur or @gthess, would either of you be willing to give me some pointers how to best proceed?

The current dnssec and ipv6 checks respectively plug a DomeinTest{Dnssec,Ipv6} model in their probe, whereas the tls and appsecpriv checks respectively plug a WebTest{TLS, Appsecpriv} model in their probe. DomeinTest{Dnssec,Ipv6} inherit from BaseTestModel, WebTest{TLS, Appsecpriv} from DomainServersModel. The docstring for DomainServersModel states "A domain can have multiple servers (ie. IP adresses, mailservers). Use this class to map server results to domain.". The initial POC for this issue by @sinteur defines a WebTestRPKI and a DomainTestRPKI. My understanding is that the first correspond to the complete test and the second to checks done against individual servers.

So let's say I want to store results for the rpki web test, per the design described in #30. This means doing ROA checks for IP-addresses for both webservers and nameservers. This means DomainTestRPKI will now contain results for FQDNs providing either and possibly both functions. This does not seem to match the intent of the report generation code, which aggregates over the complete set of servers. The net result of this direction is that the subsection on nameservers in the frontend also includes webservers and vice-versa.

DomainTestIPv6 does things differently: using WebDomain, NsDomain and MxDomain instead of a subclass of DomainServersModel. However, this also means that the check does not use the shared check code to generate a summary report and duplicates a lot of that code.

Which way do you feel is preferable? I am interested to better understand the logic behind the existing models, I am quite sure I'm missing some important bits :)

from internet.nl.

I have running versions of both the website and e-mail tests in the front-end. They need some clean-up and could use some review. I'll post a RFC pull request for those bits once they're in shape. I feel accessibility for people barely familiar with RPKI should probably get special attention. I would be happy if someone else could work on the text/translations, which also ties into accessibility.

I have yet to start on the bulk test and could use an introduction to that part of the code base. Once I have sent in a pull request for review, that'll be my main focus.
@gthess is there any chance you would be willing to give a bit of a tour? When I spoke to @sinteur, he mentioned also being unfamiliar with the bulk api, so he might be interested too.

from internet.nl.

documentation/Batch.md states:

Of course you would need to change your celery configuration (nodes, queues) accordingly.

I'm afraid I discovered today that this is not simple enough for newcomers such as myself.

@gthess Can you document the celery start multi configuration used in production, so I can integrate it in the docker subdirectory? I spent a few fruitless hours chasing why domains submitted to the batch test never left status=registering before discovering I was missing a worker. I'd like to replicate production in dev.

from internet.nl.