From martin at nlnetlabs.nl Tue Dec 3 11:28:03 2019 From: martin at nlnetlabs.nl (Martin Hoffmann) Date: Tue, 3 Dec 2019 12:28:03 +0100 Subject: [RPKI] =?utf-8?b?Um91dGluYXRvciAwLjYuNCDigJhKZWVwZXJz4oCZIHJl?= =?utf-8?q?leased?= Message-ID: <20191203122803.2a6db0e0@glaurung.nlnetlabs.nl> Dear mailing list, already Friday we released Routinator 0.6.4 ?Jeepers? with an important fix for an issue in 0.6.3 that caused it to get stuck entirely on occasion. Because of this, we suggest to not use version 0.6.3. Older versions are not affected by this issue. You can find more information about the release at https://github.com/NLnetLabs/routinator/releases/t4g/v0.6.3 Happy Routinating! On behalf of the NLnet Labs RPKI Team, Martin From alex at nlnetlabs.nl Tue Dec 3 11:33:51 2019 From: alex at nlnetlabs.nl (Alex Band) Date: Tue, 3 Dec 2019 12:33:51 +0100 Subject: [RPKI] Krill 0.4.0 'The Krill Factor' released and running in production Message-ID: <9F57DB13-25A8-460B-9F61-41AB63C6B981@nlnetlabs.nl> 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. Alternatively, you can use a third party which offers RPKI publication as a service. In short, all essential functions to run RPKI yourself using Krill are now available. Krill can be managed using a Command Line Interface (CLI), as well as an Application Programming Interface (API). An optional web-based user interface is currently being developed as a separate project, named Lagosta. With Krill 0.4.0 'The Krill Factor' data storage and the API are now stable, allowing for seamless updates going forward. This release serves as a starting point for further development throughout 2020 and beyond, where we will work on features such as high availability and support for just-in-time authorisations integrated tightly with internal routing management. Starting with Krill 0.4.0 and Routinator 0.6.0 we are offering commercial support for our RPKI software solutions, in case this is a requirement for your organisation or if you want to support the future development of the software. The service-level agreement (SLA) contract and security policy is on par with our DNS software NSD and Unbound. End of support for the software will be publicly announced two years in advance. Krill is licensed under the Mozilla Public License 2.0. Routinator and all libraries that are built to support the RPKI toolset are licensed under the BSD 3-Clause License. Once again, We would like to extend our gratitude to NIC.br, the RIPE NCC Community Projects Fund, the Dutch National Cyber Security Centre and the Mozilla Open Source Support Fund for financially supporting the development of Krill, as well as our Relying Party software package Routinator. In addition, our thanks go out to DigitalOcean for offering their cloud infrastructure for our automated test platform, Fastly for their CDN services, as well as Juniper, Cisco and Nokia for providing us with virtual routers for testing. These organisations make it possible for us to develop free, open source software in a sustainable way. Please reach out to us if you want to join this effort. On behalf of the NLnet Labs RPKI Team, Alex From job at ntt.net Sun Dec 8 17:43:37 2019 From: job at ntt.net (Job Snijders) Date: Sun, 8 Dec 2019 18:43:37 +0100 Subject: [RPKI] transcient differences between rpki-client and routinator Message-ID: <20191208174337.GG73790@hanna.meerval.net> Dear group, (kristaps, claudio in CC) I am running rpki-client and routinator in tandem every 15 minutes: the output of both tools (based on the same input fetched with rsync) is compared, and if the same the pipeline proceeds to publication a 'export.json' file - if not, an error is produced and a human (me) alerted. The rsync data was fetched around Thu 05 Dec 2019 13:30:12 UTC rpki-client (first) and routinator (second) were done at Thu 05 Dec 2019 13:34:54 UTC The flow is as following: - rpki-client fetches all rsync data - rpki-client runs its validation, spits it out as json, this is converted to cvs for easier comparing - routinator runs with '-n' and .rpki-cache/repository/rsync is symlinked to the rpki-client directory (/var/cache/rpki-client/), also spits out json which is converted to csv a snapshot of the data of that run is available here http://instituut.net/~job/rpki-repository.6E17IG9pm.tar.gz the script that runs tools one after the other and compares the output is available here: https://gist.github.com/job/ea11fc59b2411e042eaad1c1b0213c74 Now, what is very curious to me is that based on the same data input, rpki-client and routinator don't /always/ produce the same output. I'd say that it seems that 80% of the time they have the same output, and 20% of the time there are minute differences such as below: hanna:~ job$ diff rpki-repository.6E17IG9pm/export-routinator.cvs rpki-repository.6E17IG9pm/export-rpki-client.cvs 34792d34791 < AS207036,200.1.154.0/24,24,lacnic Does any one have an idea what can explain these differences? Is there perhaps some timestamp difference in an intermediate certificate where routinator decides that the ROA for 200.1.154.0/24 is not valid, or is there some check that rpki-client is maybe skipping over? What made '200.1.154.0/24,24,AS207036' valid in the eyes of rpki-client, but not in the eyes of routinator? Kind regards, Job From martin at nlnetlabs.nl Mon Dec 9 11:06:53 2019 From: martin at nlnetlabs.nl (Martin Hoffmann) Date: Mon, 9 Dec 2019 12:06:53 +0100 Subject: [RPKI] transcient differences between rpki-client and routinator In-Reply-To: <20191208174337.GG73790@hanna.meerval.net> References: <20191208174337.GG73790@hanna.meerval.net> Message-ID: <20191209120653.44fa49b9@glaurung.nlnetlabs.nl> Hi Job! Job Snijders wrote: > > The rsync data was fetched around Thu 05 Dec 2019 13:30:12 UTC > rpki-client (first) and routinator (second) were done at Thu 05 Dec > 2019 13:34:54 UTC [...] > > a snapshot of the data of that run is available here > http://instituut.net/~job/rpki-repository.6E17IG9pm.tar.gz The snapshot seems to be from around 2019-12-05 22:30 UTC. There still is a failure to decode one AFRINIC manifest but that doesn?t seem to be time related. Seems to be a ROA for AS0 on, among other things, 196.10.140.0/24, if I translated the BIT STRING correctly. > the script that runs tools one after the other and compares the output > is available here: > https://gist.github.com/job/ea11fc59b2411e042eaad1c1b0213c74 > > Now, what is very curious to me is that based on the same data input, > rpki-client and routinator don't /always/ produce the same output. I'd > say that it seems that 80% of the time they have the same output, and > 20% of the time there are minute differences such as below: > > hanna:~ job$ diff rpki-repository.6E17IG9pm/export-routinator.cvs > rpki-repository.6E17IG9pm/export-rpki-client.cvs 34792d34791 > < AS207036,200.1.154.0/24,24,lacnic > > Does any one have an idea what can explain these differences? Is there > perhaps some timestamp difference in an intermediate certificate where > routinator decides that the ROA for 200.1.154.0/24 is not valid, or is > there some check that rpki-client is maybe skipping over? What made > '200.1.154.0/24,24,AS207036' valid in the eyes of rpki-client, but not > in the eyes of routinator? Isn?t it the other way around? At least I thought the "<" points to the side where the line actually is? In any case, Routinator does accept it: | m at glaurung:/tmp/foo$ faketime "2019-12-05 23:30" \ | > routinator --disable-rrdp -t ~/.rpki-cache/newtals/ -r /tmp/foo/ \ | > vrps -nf csv | grep 200.1.154.0 | AS207036,200.1.154.0/24,24,lacnic Kind regards, Martin From claudio at openbsd.org Mon Dec 9 12:33:19 2019 From: claudio at openbsd.org (Claudio Jeker) Date: Mon, 9 Dec 2019 13:33:19 +0100 Subject: [RPKI] transcient differences between rpki-client and routinator In-Reply-To: <20191209120653.44fa49b9@glaurung.nlnetlabs.nl> References: <20191208174337.GG73790@hanna.meerval.net> <20191209120653.44fa49b9@glaurung.nlnetlabs.nl> Message-ID: <20191209123319.GA29008@diehard.n-r-g.com> On Mon, Dec 09, 2019 at 12:06:53PM +0100, Martin Hoffmann wrote: > Hi Job! > > Job Snijders wrote: > > > > The rsync data was fetched around Thu 05 Dec 2019 13:30:12 UTC > > rpki-client (first) and routinator (second) were done at Thu 05 Dec > > 2019 13:34:54 UTC > > [...] > > > > a snapshot of the data of that run is available here > > http://instituut.net/~job/rpki-repository.6E17IG9pm.tar.gz > > The snapshot seems to be from around 2019-12-05 22:30 UTC. There still > is a failure to decode one AFRINIC manifest but that doesn?t seem to be > time related. Seems to be a ROA for AS0 on, among other things, > 196.10.140.0/24, if I translated the BIT STRING correctly. > > > the script that runs tools one after the other and compares the output > > is available here: > > https://gist.github.com/job/ea11fc59b2411e042eaad1c1b0213c74 > > > > Now, what is very curious to me is that based on the same data input, > > rpki-client and routinator don't /always/ produce the same output. I'd > > say that it seems that 80% of the time they have the same output, and > > 20% of the time there are minute differences such as below: > > > > hanna:~ job$ diff rpki-repository.6E17IG9pm/export-routinator.cvs > > rpki-repository.6E17IG9pm/export-rpki-client.cvs 34792d34791 > > < AS207036,200.1.154.0/24,24,lacnic > > > > Does any one have an idea what can explain these differences? Is there > > perhaps some timestamp difference in an intermediate certificate where > > routinator decides that the ROA for 200.1.154.0/24 is not valid, or is > > there some check that rpki-client is maybe skipping over? What made > > '200.1.154.0/24,24,AS207036' valid in the eyes of rpki-client, but not > > in the eyes of routinator? > > Isn?t it the other way around? At least I thought the "<" points to the > side where the line actually is? > > In any case, Routinator does accept it: > > | m at glaurung:/tmp/foo$ faketime "2019-12-05 23:30" \ > | > routinator --disable-rrdp -t ~/.rpki-cache/newtals/ -r /tmp/foo/ \ > | > vrps -nf csv | grep 200.1.154.0 > | AS207036,200.1.154.0/24,24,lacnic > The reason why rpki-client did not accept this ROA is because the CRL is bad: rpki-client: repository.lacnic.net/rpki/lacnic/8bb5ab6a-b91f-439b-bdfb-eb3c43470d36/17ccf2e528990c3d8b0172b3372656083e3ddf4f.crl: bad message digest and therefore the certificate for the roa could not be verified: rpki-client: repository.lacnic.net/rpki/lacnic/8bb5ab6a-b91f-439b-bdfb-eb3c43470d36/0c2f7644106123110d3619cf85dd4440bdc67119.roa: unable to get certificate CRL In dir repository.lacnic.net/rpki/lacnic/8bb5ab6a-b91f-439b-bdfb-eb3c43470d36/ there is the mft, crl and roa we are interested in. Looking at 17ccf2e528990c3d8b0172b3372656083e3ddf4f.mft we see it references the CRL and ROA with the following hashes: 1: 0c2f7644106123110d3619cf85dd4440bdc67119.roa hash g6bCSNza52glKOZfjbxZHZ/FwgYMJSVnFRLtEklyH7Q= 2: 17ccf2e528990c3d8b0172b3372656083e3ddf4f.crl hash 1OOBfzIFTAUAsD7LTLVFKi9WxdTy2d+ht+wXIo4TOuw= But sha256 tells us this: SHA256 (0c2f7644106123110d3619cf85dd4440bdc67119.roa) = g6bCSNza52glKOZfjbxZHZ/FwgYMJSVnFRLtEklyH7Q= SHA256 (17ccf2e528990c3d8b0172b3372656083e3ddf4f.crl) = XSmoaab95/UuLUEbokJahsRSiMU6QIrwuLUNDV/giIM= As you can see the hash for the CRL is totally wrong and this is why rpki-client is dropping the ROA because the certificate validation fails since the CRL could not be loaded. I have seen this happen on a few occasions that lacnic publishes MFTs with bad checksums. I guess somebody should talk to them to understand why this happens. Also why does routinator not fail for this ROA? I find it dangerous to fail open in such a case. It mostly disables revocation. -- :wq Claudio From job at ntt.net Mon Dec 9 12:42:23 2019 From: job at ntt.net (Job Snijders) Date: Mon, 9 Dec 2019 13:42:23 +0100 Subject: [RPKI] transcient differences between rpki-client and routinator In-Reply-To: <20191209120653.44fa49b9@glaurung.nlnetlabs.nl> References: <20191208174337.GG73790@hanna.meerval.net> <20191209120653.44fa49b9@glaurung.nlnetlabs.nl> Message-ID: On Mon, 9 Dec 2019 at 12:07, Martin Hoffmann wrote: > > Now, what is very curious to me is that based on the same data input, > > rpki-client and routinator don't /always/ produce the same output. I'd > > say that it seems that 80% of the time they have the same output, and > > 20% of the time there are minute differences such as below: > > > > hanna:~ job$ diff rpki-repository.6E17IG9pm/export-routinator.cvs > > rpki-repository.6E17IG9pm/export-rpki-client.cvs 34792d34791 > > < AS207036,200.1.154.0/24,24,lacnic > > > > Does any one have an idea what can explain these differences? Is there > > perhaps some timestamp difference in an intermediate certificate where > > routinator decides that the ROA for 200.1.154.0/24 is not valid, or is > > there some check that rpki-client is maybe skipping over? What made > > '200.1.154.0/24,24,AS207036' valid in the eyes of rpki-client, but not > > in the eyes of routinator? > > Isn?t it the other way around? At least I thought the "<" points to the > side where the line actually is? Yes, routinator has produced a VRP for 200.1.154.0/24 - while rpki-client did not produce a VRP covering that prefix. The ? > | m at glaurung:/tmp/foo$ faketime "2019-12-05 23:30" \ > | > routinator --disable-rrdp -t ~/.rpki-cache/newtals/ -r /tmp/foo/ \ > | > vrps -nf csv | grep 200.1.154.0 > | AS207036,200.1.154.0/24,24,lacnic Yeah - see Claudio?s email. It appears that there is a difference in the validation process between routinator and rpki-client, we need to understand what the correct (and safe) way of handling this particular input data is. Kind regards, Job Ps. I wasn?t aware of ?faketime? as a utility! Thanks - that is very useful :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Mon Dec 9 12:53:14 2019 From: job at ntt.net (Job Snijders) Date: Mon, 9 Dec 2019 13:53:14 +0100 Subject: [RPKI] transcient differences between rpki-client and routinator In-Reply-To: References: <20191208174337.GG73790@hanna.meerval.net> <20191209120653.44fa49b9@glaurung.nlnetlabs.nl> Message-ID: On Mon, 9 Dec 2019 at 13:42, Job Snijders wrote: > Isn?t it the other way around? At least I thought the "<" points to the >> side where the line actually is? > > Oops! You are right, I worded it wrong in my original email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at nlnetlabs.nl Tue Dec 10 10:10:36 2019 From: martin at nlnetlabs.nl (Martin Hoffmann) Date: Tue, 10 Dec 2019 11:10:36 +0100 Subject: [RPKI] transcient differences between rpki-client and routinator In-Reply-To: <20191209123319.GA29008@diehard.n-r-g.com> References: <20191208174337.GG73790@hanna.meerval.net> <20191209120653.44fa49b9@glaurung.nlnetlabs.nl> <20191209123319.GA29008@diehard.n-r-g.com> Message-ID: <20191210111036.46f37e8a@glaurung.nlnetlabs.nl> Claudio Jeker wrote: > > The reason why rpki-client did not accept this ROA is because the CRL > is bad: > > rpki-client: > repository.lacnic.net/rpki/lacnic/8bb5ab6a-b91f-439b-bdfb-eb3c43470d36/17ccf2e528990c3d8b0172b3372656083e3ddf4f.crl: > bad message digest Ah, right. Routinator doesn?t check the manifest hash of a CRL. > Also why does routinator not fail for this ROA? I find it dangerous > to fail open in such a case. It mostly disables revocation. Initially, this was an oversight on my part. Job made a good point about consistency between different implementations, so I will fix it. However, I believe this is not a problem because there is no gain from using CRLs in RPKI. The purpose of the CRL is to protect against replay of revoked certificates or, in RPKI, revoked published objects. But because these objects are registered with their hash in the manifest, one would also need to replay an old manifest, which would then contain the hash of the old CRL and one could replay that, too. Also, there is a weird circular dependency. The manifest?s EE certificate points to a CRL which I need to check in order for the manifest to be valid, but this CRL is not valid unless its hash on the very same manifest is valid. The upshot is that, unless I am missing something, you can?t revoke a manifest with the CRL that is delivered with itself and, transitively, any object that is mentioned on the manifest. If that were true, then CRLs only serve to make the system more brittle, increased its overhead, and make it harder to implement because of the requirement to revoke everything all the time. But, this indeed is probably a discussion for SIDROPS and, as said, I?ll fix Routinator for now. Kind regards, Martin From tim at nlnetlabs.nl Tue Dec 10 11:43:52 2019 From: tim at nlnetlabs.nl (Tim Bruijnzeels) Date: Tue, 10 Dec 2019 08:43:52 -0300 Subject: [RPKI] transcient differences between rpki-client and routinator In-Reply-To: <20191210111036.46f37e8a@glaurung.nlnetlabs.nl> References: <20191208174337.GG73790@hanna.meerval.net> <20191209120653.44fa49b9@glaurung.nlnetlabs.nl> <20191209123319.GA29008@diehard.n-r-g.com> <20191210111036.46f37e8a@glaurung.nlnetlabs.nl> Message-ID: <727C3BBF-A056-4B7F-9D89-E40246F4FE6A@nlnetlabs.nl> Hi, > On 10 Dec 2019, at 07:10, Martin Hoffmann wrote: > > Claudio Jeker wrote: >> >> The reason why rpki-client did not accept this ROA is because the CRL >> is bad: >> >> rpki-client: >> repository.lacnic.net/rpki/lacnic/8bb5ab6a-b91f-439b-bdfb-eb3c43470d36/17ccf2e528990c3d8b0172b3372656083e3ddf4f.crl: >> bad message digest > > Ah, right. Routinator doesn?t check the manifest hash of a CRL. > >> Also why does routinator not fail for this ROA? I find it dangerous >> to fail open in such a case. It mostly disables revocation. > > Initially, this was an oversight on my part. Job made a good point > about consistency between different implementations, so I will fix it. > > However, I believe this is not a problem because there is no gain from > using CRLs in RPKI. The purpose of the CRL is to protect against replay > of revoked certificates or, in RPKI, revoked published objects. But > because these objects are registered with their hash in the manifest, > one would also need to replay an old manifest, which would then contain > the hash of the old CRL and one could replay that, too. > > Also, there is a weird circular dependency. The manifest?s EE > certificate points to a CRL which I need to check in order for the > manifest to be valid, but this CRL is not valid unless its hash on the > very same manifest is valid. > > The upshot is that, unless I am missing something, you can?t revoke a > manifest with the CRL that is delivered with itself and, transitively, > any object that is mentioned on the manifest. > > If that were true, then CRLs only serve to make the system more > brittle, increased its overhead, and make it harder to implement > because of the requirement to revoke everything all the time. > All of the above.. You can revoke the manifest EE if you really want to shoot yourself in an essential body part. You can also revoke other any other current object, but RFC 6481 (ResCert Repository Structure) says that the repository contains all current valid, non-revoked objects. So, you should not (normative language unclear) publish anything that is invalid, and you should publish everything that is. Also all objects refer back to a CRL, but there must (again normative language unclear) be only one CRL ever for a signing key - so here we have another locus for messing things up. > But, this indeed is probably a discussion for SIDROPS and, as said, I?ll > fix Routinator for now. Historically - even before my time with RPKI so >10 years - there were no manifests. Just CRLs. Then people realised that this would be very insecure wrt replay. So the MFTs were invented. However, the use of MFT in validation left many things open to 'local policy', such as what to do w.r.t. stale, hash mismatch etc. I never liked this, because it leads to confusion and differences between how RPs deal with things. All in all I wish that manifest would just be treated as the current signed list of everything, and then CRLs are not needed at all. They do not add security because they are signed by the same key that signs the manifest EE, they just introduce additional ways to break things - and they lead to knee jerk confusion. There was resistance to this stance when I brought it up ages ago (I forgot when) so I didn't push.. but we could rekindle the discussion. As a side note: I believe the CRLs do add value if we were to publish any RPKI signed things outside of the RPKI repository. Like an RPKI signed object that I can give to someone else, or for 'naked' EE certificate which might be used to sign other things, such as RPSL (RFC 7909). We don't see those things in the wild yet, but there it would make sense that you can verify whether something has been revoked. But if we only used it for this purpose the CRLs could be much shorter, and could be long lived: just issue when needed and update the MFT hash. This would reduce some of the churn that we see in repos. Kind regards Tim > > Kind regards, > Martin > -- > RPKI mailing list > RPKI at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/rpki From jeroen at nlnetlabs.nl Tue Dec 10 14:02:07 2019 From: jeroen at nlnetlabs.nl (Jeroen Koekkoek) Date: Tue, 10 Dec 2019 15:02:07 +0100 Subject: [RPKI] Mailing list migration Message-ID: <5b37f4bcf96a94bab40a13e0defdf5118d2aaeed.camel@nlnetlabs.nl> Hi all, On December 16th 2019 the rpki mailing list will be migrated to a different provider. The oppertunity will also be used to move the mailing list to the dedicated lists.nlnetlabs.nl subdomain. You will automatically be subscribed to the new list and care is taken to make the transition as smooth as possible. During the migration though, the mailing list may be unreachable. From December 16th 2019 please direct questions to rpki at lists.nlnetlabs.nl and ensure any filters you may have configured are updated to recognize the address. Best regards, Jeroen Koekkoek, NLnet Labs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From tim at nlnetlabs.nl Tue Dec 10 14:48:08 2019 From: tim at nlnetlabs.nl (Tim Bruijnzeels) Date: Tue, 10 Dec 2019 11:48:08 -0300 Subject: [RPKI] transcient differences between rpki-client and routinator In-Reply-To: <24047.44184.242932.188686@oz.mt.att.com> References: <20191208174337.GG73790@hanna.meerval.net> <20191209120653.44fa49b9@glaurung.nlnetlabs.nl> <20191209123319.GA29008@diehard.n-r-g.com> <20191210111036.46f37e8a@glaurung.nlnetlabs.nl> <727C3BBF-A056-4B7F-9D89-E40246F4FE6A@nlnetlabs.nl> <24047.44184.242932.188686@oz.mt.att.com> Message-ID: Hi Jay > On 10 Dec 2019, at 11:32, Jay Borkenhagen wrote: > >> But, this indeed is probably a discussion for SIDROPS and, as said I'll >> fix Routinator for now. > > Hi Martin, > Hi Tim, > > Was the VRP inconsistency that Job noticed a transient that's now in > the past? > > If not, I would like to request that Routinator's behavior not be > changed until some consensus emerges from that SIDROPS discussion. I believe that Martin said he would. > > Routinator's current behavior appears to match that of RIPE's > rpki-validator-3, and the MIRO RPKI Browser output seems to agree as > well. (I do not yet have a rpki-client or LACNIC Fort running here.) The issue itself is transient. It happens when there is a disagreement between the MFT, CRL and similar issues nay occur if there is a mismatch with the other content of the directory (file missing, wrong hash). These things can occur when objects are not updated in synchrony, or even if they are.. if published and retrieved through rsync mismatches may happen as a result of a race condition between retrieving things, and them being updated. I am not 100% sure how rsyncd deals with this, but I believe that it does not keep open file handles for all the content, so even writing to a new dir and renaming that may not solve this issue. I am not saying that RRDP is perfect, but it does at least offer the option of seeing all updates as a single delta. In fact this was one of the (many) reasons for inventing this as an alternative. Tim > > Thanks. > > Jay B. > From rpki at braeburn.org Tue Dec 10 14:55:46 2019 From: rpki at braeburn.org (Jay Borkenhagen) Date: Tue, 10 Dec 2019 09:55:46 -0500 Subject: [RPKI] transcient differences between rpki-client and routinator In-Reply-To: References: <20191208174337.GG73790@hanna.meerval.net> <20191209120653.44fa49b9@glaurung.nlnetlabs.nl> <20191209123319.GA29008@diehard.n-r-g.com> <20191210111036.46f37e8a@glaurung.nlnetlabs.nl> <727C3BBF-A056-4B7F-9D89-E40246F4FE6A@nlnetlabs.nl> <24047.44184.242932.188686@oz.mt.att.com> Message-ID: <24047.45554.895012.670174@oz.mt.att.com> Tim Bruijnzeels writes: > Hi Jay > > > On 10 Dec 2019, at 11:32, Jay Borkenhagen wrote: > > > >> But, this indeed is probably a discussion for SIDROPS and, as said I'll > >> fix Routinator for now. > > > > Hi Martin, > > Hi Tim, > > > > Was the VRP inconsistency that Job noticed a transient that's now in > > the past? > > > > If not, I would like to request that Routinator's behavior not be > > changed until some consensus emerges from that SIDROPS discussion. > > I believe that Martin said he would. > I thought Martin said "Change Routinator first, start SIDROPS discussion later." I was just arguing for "Start SIDROPS discussion, hope for speedy consensus, and then depending on the outcome possibly change Routinator." [Excuse my fubar sending my earlier note. I did CC the list on it, but it was held for moderation since I sent from a non-subscribed address.] Thanks! Jay B. From tim at nlnetlabs.nl Tue Dec 10 14:58:48 2019 From: tim at nlnetlabs.nl (Tim Bruijnzeels) Date: Tue, 10 Dec 2019 11:58:48 -0300 Subject: [RPKI] transcient differences between rpki-client and routinator In-Reply-To: <24047.45554.895012.670174@oz.mt.att.com> References: <20191208174337.GG73790@hanna.meerval.net> <20191209120653.44fa49b9@glaurung.nlnetlabs.nl> <20191209123319.GA29008@diehard.n-r-g.com> <20191210111036.46f37e8a@glaurung.nlnetlabs.nl> <727C3BBF-A056-4B7F-9D89-E40246F4FE6A@nlnetlabs.nl> <24047.44184.242932.188686@oz.mt.att.com> <24047.45554.895012.670174@oz.mt.att.com> Message-ID: <613708FF-AA04-4E22-A4AF-DFE2A035F8BD@nlnetlabs.nl> > On 10 Dec 2019, at 11:55, Jay Borkenhagen wrote: > > Tim Bruijnzeels writes: >> Hi Jay >> >>> On 10 Dec 2019, at 11:32, Jay Borkenhagen wrote: >>> >>>> But, this indeed is probably a discussion for SIDROPS and, as said I'll >>>> fix Routinator for now. >>> >>> Hi Martin, >>> Hi Tim, >>> >>> Was the VRP inconsistency that Job noticed a transient that's now in >>> the past? >>> >>> If not, I would like to request that Routinator's behavior not be >>> changed until some consensus emerges from that SIDROPS discussion. >> >> I believe that Martin said he would. >> > > I thought Martin said "Change Routinator first, start SIDROPS > discussion later." I was just arguing for "Start SIDROPS discussion, > hope for speedy consensus, and then depending on the outcome possibly > change Routinator." > Oh right, I misunderstood then. But I do not have high hopes of quick consensus, and even if then it would take time for RP software to be updated. Updating routinator first is probably the quickest path to consistency. > [Excuse my fubar sending my earlier note. I did CC the list on it, > but it was held for moderation since I sent from a non-subscribed > address.] > > Thanks! > > Jay B. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayb at braeburn.org Tue Dec 10 15:07:28 2019 From: jayb at braeburn.org (Jay Borkenhagen) Date: Tue, 10 Dec 2019 10:07:28 -0500 Subject: [RPKI] transcient differences between rpki-client and routinator In-Reply-To: <613708FF-AA04-4E22-A4AF-DFE2A035F8BD@nlnetlabs.nl> References: <20191208174337.GG73790@hanna.meerval.net> <20191209120653.44fa49b9@glaurung.nlnetlabs.nl> <20191209123319.GA29008@diehard.n-r-g.com> <20191210111036.46f37e8a@glaurung.nlnetlabs.nl> <727C3BBF-A056-4B7F-9D89-E40246F4FE6A@nlnetlabs.nl> <24047.44184.242932.188686@oz.mt.att.com> <24047.45554.895012.670174@oz.mt.att.com> <613708FF-AA04-4E22-A4AF-DFE2A035F8BD@nlnetlabs.nl> Message-ID: <24047.46256.64847.987642@oz.mt.att.com> Tim Bruijnzeels writes: > > I thought Martin said "Change Routinator first, start SIDROPS > > discussion later." I was just arguing for "Start SIDROPS discussion, > > hope for speedy consensus, and then depending on the outcome possibly > > change Routinator." > > > > Oh right, I misunderstood then. > > But I do not have high hopes of quick consensus, and even if then it would take time for RP software to be updated. > > Updating routinator first is probably the quickest path to consistency. > I want consistency, too, but among Routinator, rpki-validator-3, and rpki-client at least, and possibly other currently-supported RP implementations, too. Maybe there will be an impasse in SIDROPS and that consistency will not be achievable, but I think we should see first. Thanks! From job at ntt.net Tue Dec 10 16:21:52 2019 From: job at ntt.net (Job Snijders) Date: Tue, 10 Dec 2019 17:21:52 +0100 Subject: [RPKI] transcient differences between rpki-client and routinator In-Reply-To: <24047.46256.64847.987642@oz.mt.att.com> References: <20191208174337.GG73790@hanna.meerval.net> <20191209120653.44fa49b9@glaurung.nlnetlabs.nl> <20191209123319.GA29008@diehard.n-r-g.com> <20191210111036.46f37e8a@glaurung.nlnetlabs.nl> <727C3BBF-A056-4B7F-9D89-E40246F4FE6A@nlnetlabs.nl> <24047.44184.242932.188686@oz.mt.att.com> <24047.45554.895012.670174@oz.mt.att.com> <613708FF-AA04-4E22-A4AF-DFE2A035F8BD@nlnetlabs.nl> <24047.46256.64847.987642@oz.mt.att.com> Message-ID: <20191210162152.GB14275@hanna.meerval.net> On Tue, Dec 10, 2019 at 10:07:28AM -0500, Jay Borkenhagen wrote: > Tim Bruijnzeels writes: > > > I thought Martin said "Change Routinator first, start SIDROPS > > > discussion later." I was just arguing for "Start SIDROPS discussion, > > > hope for speedy consensus, and then depending on the outcome possibly > > > change Routinator." > > > > Oh right, I misunderstood then. > > > > But I do not have high hopes of quick consensus, and even if then > > it would take time for RP software to be updated. > > > > Updating routinator first is probably the quickest path to > > consistency. > > I want consistency, too, but among Routinator, rpki-validator-3, and > rpki-client at least, and possibly other currently-supported RP > implementations, too. Maybe there will be an impasse in SIDROPS and > that consistency will not be achievable, but I think we should see > first. It might be worthwhile to provide SIDROPS with a summary of our observations on transient issues, and a summary of how we resolved things in the validator space - ultimately the very phenomenon we are observing is due to a synchronicity issue on the RIR level - and I do believe that the validators don't need to be 'forgiving' to such issues. The issues appears to resolve themselves in a matter of hours, so applying 'stricter' validation doesn't ultimately impact the implications to production networks, because eventually the ROAs do become valid for transformation into VRPs anyhow. I think we've now exposing a bug or inefficiency on the RIR publication side of the house, and I believe the root cause must be addressed there. Kind regards, Job From alex at nlnetlabs.nl Fri Dec 13 14:19:01 2019 From: alex at nlnetlabs.nl (Alex Band) Date: Fri, 13 Dec 2019 11:19:01 -0300 Subject: [RPKI] Krill 0.4.1 'Fogo de Krill' Released Message-ID: <6FD9F479-0F75-460E-A831-61F4C6A99053@nlnetlabs.nl> Dear mailing list, We are happy to launch Krill 0.4.1 'Fogo de Krill'. This is a bug fix release and we recommend everyone running Krill to update to this version. Krill now powers the RPKI service that Brazilian National Internet Registry NIC.br offers. During the production launch we uncovered a corner case bug where certain resource sets were handled incorrectly. This has now been resolved. In addition, we added an additional safety measure to ensure that Krill does not allow impossible maximum length values for ROAs. You can find more information about the release at https://github.com/NLnetLabs/krill/releases/tag/v0.4.1 On behalf of the NLnet Labs RPKI Team, Alex From md at linux.it Sun Dec 29 15:15:55 2019 From: md at linux.it (Marco d'Itri) Date: Sun, 29 Dec 2019 16:15:55 +0100 Subject: [RPKI] [PATCH] routinator.service: restart the daemon on failure Message-ID: <20191229151555.313985-1-md@linux.it> RestartSec was a forgotten statement used while debugging: we actually want the daemon to be restarted on failure. --- etc/routinator.service | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/etc/routinator.service b/etc/routinator.service index 7bec3f9..bd77541 100644 --- a/etc/routinator.service +++ b/etc/routinator.service @@ -6,7 +6,7 @@ After=network.target [Service] ExecStart=/usr/bin/routinator --config=/etc/routinator/routinator.conf --syslog server Type=exec -RestartSec=0 +Restart=on-failure User=routinator AmbientCapabilities=CAP_NET_BIND_SERVICE CapabilityBoundingSet=CAP_NET_BIND_SERVICE -- 2.25.0.rc0 From md at linux.it Sun Dec 29 15:25:14 2019 From: md at linux.it (Marco d'Itri) Date: Sun, 29 Dec 2019 16:25:14 +0100 Subject: [RPKI] Bug#929024: ITP: routinator -- An RPKI Validator Message-ID: <20191229152514.GA314039@bongo.bofh.it> Updated Debian packaging is available in the git repository: https://salsa.debian.org/md/routinator/ . Building a real package will still require a few more crates to be packaged in Debian: ??? daemonize v0.4.1 ? ??? boxfnonce v0.1.1 ??? listenfd v0.3.3 ??? * ? ??? once_cell v1.2.0 ??? unwrap v1.2.1 and many more to be updated. -- ciao, Marco From md at Linux.IT Mon Dec 30 00:48:21 2019 From: md at Linux.IT (Marco d'Itri) Date: Mon, 30 Dec 2019 01:48:21 +0100 Subject: [RPKI] Bug#929024: ITP: routinator -- An RPKI Validator In-Reply-To: <20191229152514.GA314039@bongo.bofh.it> References: <20191229152514.GA314039@bongo.bofh.it> Message-ID: <20191230004821.GA358645@bongo.bofh.it> On Dec 29, Marco d'Itri via RPKI wrote: > Building a real package will still require a few more crates to be Right now I am stuck on rpki depending on a very old version of ring. The verification API has changed since then and I do not know enough Rust to update rpki. -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: