nicmx/fort-validator

RPKI cache validator

FORT Validator

An RPKI Relying Party and RTR Server.

Documentation

• Home
• Installation
• Usage
• Arguments

Docker image

See the docker/ directory.

fort-validator's Issues

LibreSSL has some NIDs

There seems to be a clash, possibly related to openbsd/src@8d85952#diff-d64bddeabb929c29c96fb6e422d4f623b3ea8bd4e1ac006706c3f658252075d3

vurt$ make
Making all in src
make  all-am
clang -DHAVE_CONFIG_H -I.    -Wall -Wno-cpp -std=gnu11 -O2 -g   -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/include -MT fort-nid.o -MD -MP -MF .deps/fort-nid.Tpo -c -o fort-nid.o `test -f 'nid.c' || echo './'`nid.c
nid.c:8:12: error: expected identifier or '('
static int NID_rpkiManifest;
           ^
/usr/include/openssl/obj_mac.h:1908:27: note: expanded from macro 'NID_rpkiManifest'
#define NID_rpkiManifest                1010
                                        ^
nid.c:9:12: error: expected identifier or '('
static int NID_signedObject;
           ^
/usr/include/openssl/obj_mac.h:1913:27: note: expanded from macro 'NID_signedObject'
#define NID_signedObject                1011
                                        ^
nid.c:10:12: error: expected identifier or '('
static int NID_rpkiNotify;
           ^
/usr/include/openssl/obj_mac.h:1918:25: note: expanded from macro 'NID_rpkiNotify'
#define NID_rpkiNotify          1012
                                ^
nid.c:37:19: error: expression is not assignable
        NID_rpkiManifest = register_oid("1.3.6.1.5.5.7.48.10",
        ~~~~~~~~~~~~~~~~ ^
nid.c:43:19: error: expression is not assignable
        NID_signedObject = register_oid("1.3.6.1.5.5.7.48.11",
        ~~~~~~~~~~~~~~~~ ^
nid.c:49:17: error: expression is not assignable
        NID_rpkiNotify = register_oid("1.3.6.1.5.5.7.48.13",
        ~~~~~~~~~~~~~~ ^
6 errors generated.
*** Error 1 in src (Makefile:1914 'fort-nid.o')
*** Error 2 in src (Makefile:860 'all')
*** Error 1 in /home/job/source/FORT-validator (Makefile:389 'all-recursive': @fail=;  if (target_option=k; case ${target_option-} in  ?) ;;...)

Running as non-root

Hi,

I tried to make an ebuild (and the associated init file) for FORT, but I don’t see any option to change the user after the binding. If I use the start-stop-daemon, FORT can’t bind to port 323 as it’s less than 1024.
And of course, I don’t want to run FORT as root.

Regards,

Alarig

Probemas con TALs de RIPE y APNIC

Hola, estoy recibiendo los siguientes errores con los TALs de APNIC y RIPE, que terminar haciendo que FORT se detenga:

Dec 10 12:49:37 RPKI-Fort fort[12327]: Dec 10 12:49:37 ERR: /etc/fort/tal/apnic.tal: None of the URIs of the TAL '/etc/fort/tal/apnic.tal' yielded a successful traversal.
Dec 10 12:49:37 RPKI-Fort fort[12327]: Dec 10 12:49:37 ERR: /etc/fort/tal/ripe.tal: None of the URIs of the TAL '/etc/fort/tal/ripe.tal' yielded a successful traversal.

Volví a descargar los archivos TAL pero continúa el error.

Versión: 1.4.2-1
SO: Ubuntu 20.04

Les agradezco la ayuda.

RRDP files created at the same level that RSYNC files

Currently the RRDP resultant files are created and updated at the same level that the RSYNC repositories files (at --local-repository).

Quoting RFC 8182 section 3.4.2:

When a Relying Party encounters a "withdraw" element, or a
"publish" element where an object is replaced, in a delta that it
retrieves from a Repository Server, it MUST verify that the object
to be withdrawn or replaced was retrieved from this same
Repository Server before applying the appropriate action. Failing
to do so will leave the Relying Party vulnerable to malicious
Repository Servers instructing it to delete or change arbitrary
objects.

Also, a reference from sidrops mail archive: [Sidrops] RRDP and rsync URIs

The URIs from the publish/withdraw RRDP elements shouldn't be "mapped" to the same directory tree at --local-repository; the proposal is to use some kind of workspace to locally store and read such elements.

Separate validation logs from operation logs

Some people have manifested annoyance over the large volume of complaints that Fort logs due to issues found in the RPKI tree:

(sample excerpt)
WRN: rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2694/rXp9fDjcCAhxxza7mMddsMJ8uMc.roa: Serial number '661' is not unique. (Also found in 'rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2694/5Rs-Pc07Y_zNasRoTeJVfORvmOE.roa'.)
WRN: rsync://rpki.cnnic.cn/rpki/A9162E3D0000/497/cOev3xoFWdNyUTYsMDI5Egl8PQ8.roa: Serial number '6BD' is not unique. (Also found in 'rsync://rpki.cnnic.cn/rpki/A9162E3D0000/497/4BqXb84YtfqpHX1W1oGcKGi_jYs.roa'.)
WRN: rsync://rpki.cnnic.cn/rpki/A9162E3D0000/561/R_8KCa9pc3fNftjCdSYROwMQB3c.roa: Serial number '6B9' is not unique. (Also found in 'rsync://rpki.cnnic.cn/rpki/A9162E3D0000/561/GqEqV9qIXXJK2ICJP14IjGwoQKQ.roa'.)
WRN: rsync://rpki.cnnic.cn/rpki/A9162E3D0000/561/URCkLU-hrbETGHt-zWzU-tZvi70.roa: Serial number '6B9' is not unique. (Also found in 'rsync://rpki.cnnic.cn/rpki/A9162E3D0000/561/GqEqV9qIXXJK2ICJP14IjGwoQKQ.roa'.)
ERR: rsync://rpki.cnnic.cn/rpki/A9162E3D0000/FE-4PMY9qqTI2aJ0xLDm7cD-fvw.cer: Could not open location 'tmp/rpki.cnnic.cn/rpki/A9162E3D0000/515/FE-4PMY9qqTI2aJ0xLDm7cD-fvw.mft'
ERR:   - No such file or directory
ERR: rsync://rpki.cnnic.cn/rpki/A9162E3D0000/FE-4PMY9qqTI2aJ0xLDm7cD-fvw.cer: Could not open location 'tmp/rpki.cnnic.cn/rpki/A9162E3D0000/515/FE-4PMY9qqTI2aJ0xLDm7cD-fvw.mft'
ERR:   - No such file or directory
WRN: rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2329/01jyjWbE_vnmei3aHGlV_cCSXYA.roa: Serial number '732' is not unique. (Also found in 'rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2329/-w8V5CMi6bHN88xgo8K9tma5MC8.roa'.)
WRN: rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2329/70nRMOo1VzrcvxbocYKqzlcNbqU.roa: Serial number '732' is not unique. (Also found in 'rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2329/-w8V5CMi6bHN88xgo8K9tma5MC8.roa'.)
WRN: rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2329/9YAUV53TP8C8valffV_Pbl8k0Pc.roa: Serial number '732' is not unique. (Also found in 'rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2329/-w8V5CMi6bHN88xgo8K9tma5MC8.roa'.)
WRN: rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2329/Hi7elxud7qvaNilveqkgB0LmoHs.roa: Serial number '732' is not unique. (Also found in 'rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2329/-w8V5CMi6bHN88xgo8K9tma5MC8.roa'.)
WRN: rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2329/U2DxoZ7UrM_rju6WOJe1r5LpBgM.roa: Serial number '732' is not unique. (Also found in 'rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2329/-w8V5CMi6bHN88xgo8K9tma5MC8.roa'.)
WRN: rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2329/ZcvvMu_hxh0SyftR2-OPegdnTHA.roa: Serial number '732' is not unique. (Also found in 'rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2329/-w8V5CMi6bHN88xgo8K9tma5MC8.roa'.)
WRN: rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2329/yWD9OmpNgJA5rwfOF9JlXPfgHLw.roa: Serial number '732' is not unique. (Also found in 'rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2329/-w8V5CMi6bHN88xgo8K9tma5MC8.roa'.)

The admin running this is unlikely to have the authority to correct these problems, and they tend to obfuscate the actual operation errors, which are much more important for them.

On the other hand, downgrading the priority of these messages to debug would be a bit extreme because they can be helpful for people trying to validate the compliance of their own RPKI objects.

It has been therefore proposed to separate these messages into a separate logging channel.

Update: This bug is independent of incidences:

• Incidences were conceived (mainly) as a means to direct Fort not to drop RPKI objects due to minor, understood, common and specific profile validation violations.
• This is (mainly) a means to prevent Fort from polluting the logs with potentially unimportant information. (While still likely dropping the offending objects.)

Fails to build with gcc 10

The package fails to build in a test rebuild on at least amd64 with gcc-10/g++-10, but succeeds to build with gcc-9/g++-9.

The full build log can be found at: http://people.debian.org/~doko/logs/gcc10-20200225/fort-validator_1.2.0-1_unstable_gcc10.log

To build with GCC 10, either set CC=gcc-10 CXX=g++-10 explicitly,
or install the gcc, g++, gfortran, ... packages from experimental.

apt-get -t=experimental install g++

Common build failures are new warnings resulting in build failures with
-Werror turned on, or new/dropped symbols in Debian symbols files.
For other C/C++ related build failures see the porting guide at
http://gcc.gnu.org/gcc-10/porting_to.html

/usr/bin/ld: slurm/fort-db_slurm.o:./src/slurm/db_slurm.c:36: multiple definition of `addr_buf'; fort-output_printer.o:./src/output_printer.c:11: first defined here

Add --daemonize option

For some deployment scenarios it might be nice to have the application daemonize itself into the background. Please consider adding an optional --daemonize command line option that also requires --mode=server to be passed

Should ROA's ASN be validated as a subset of parent's cert ASN range?

If a ROA contains an ASN that is not included on its parent's EE and CA certs ASN range (for example, the parent EE and CA define an ASN range like 1000-2000 and the ROA contains the ASN 999999), the validator doesn't report any error.

Should ROA's ASN be validated as a subset of parent's cert ASN range?

Segmentation Fault when a ROA advertise a subset that isn't included on parents resources

When the rpki validator tries to validate a ROA that contains the ip resources 1-50.0.0.0/9 and its EE contains the resource 255.0.0.0/9, the following stack trace is displayed:

rpki_validator(print_stack_trace+0x32) [0x558df183feb2]
rpki_validator(+0x8f96) [0x558df183ff96]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12890) [0x7f868ae94890]
rpki_validator(+0x13600) [0x558df184a600]
rpki_validator(sarray_contains+0x53) [0x558df1842ea3]
rpki_validator(res4_contains_prefix+0x3e) [0x558df184a78e]
rpki_validator(handle_roa+0x54f) [0x558df18499af]
rpki_validator(rpp_traverse+0x112) [0x558df1842b82]
rpki_validator(certificate_traverse+0x2a9) [0x558df18486c9]
rpki_validator(+0x7c41) [0x558df183ec41]
rpki_validator(foreach_uri+0x4d) [0x558df184a09d]
rpki_validator(main+0xc2) [0x558df183ea12]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f868aab2b97]
rpki_validator(_start+0x2a) [0x558df183ea7a]
(Stack size was 14.)

errors in validation log , and session restarting every 120 seconds

OS Debian 10.10
Linux rpki 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 GNU/Linux
fort 1.5.1

config.json attached
config.json.txt

Every two minutes router sessions are restarted (max uptime is two minutes).
The first line is a fort-1.5.1 at about two minutes.
The second line is a fort-1.4.2 whose session is not restarted.

---

show validation session
me@mx>Session State Flaps Uptime #IPv4/IPv6 records
172.20.21.33 Up 55 00:01:58 227887/43730
172.30.37.33 Up 3 06:41:53 227887/43730

show validation session
me@mx>Session State Flaps Uptime #IPv4/IPv6 records
172.20.21.33 Up 55 00:01:59 227887/43730
172.30.37.33 Up 3 06:41:54 227887/43730

show validation session
me@mx>Session State Flaps Uptime #IPv4/IPv6 records
172.20.21.33 Up 56 00:00:00 227887/43730
172.30.37.33 Up 3 06:41:55 227887/43730

me@mx>show validation session
Session State Flaps Uptime #IPv4/IPv6 records
172.20.21.33 Up 56 00:00:01 227887/43730
172.30.37.33 Up 3 06:41:56 227887/43730

---

I had to set http transfer-timeout to 120, to avoid lots of timeout error in validation-log (not too bad)
Still have lots of errors in validation-log , in different flavors (at startup, and at each refresh)

fort.log attached
fort.log

rsync download any files/directories included in the TAL's URI

If the rsync URI included in TAL file references any file or directory that isn't a valid RPKI certificate, the rpki validator allows to download all the content located on that URI

For example, if the TAL file contains the following URI:

rsync://rsync.kernel.org/pub/software/

MIBBIjANB...
...DAQAB

and the user executes the following command

rpki_validator --tal rsyncdirectory.tal --local-repository repository

the rpki validator starts to download all the content from that URI.

According to RFC 6490:

the rsync URI in the TAL MUST reference a single object. It MUST NOT reference a directory or any other form of collection of objects

so rpki validator should prevent to download any directories o collections from rsync URI

More validation debugging information could be useful

There is an ongoing issue with the ARIN RPKI Trust Anchor https://www.arin.net/announcements/20200812/

The issue is explained in greater detail here http://sobornost.net/~job/arin-manifest-issue-2020.08.12.txt

In this situation rpki-client gives the following error:

job@bench ~$ doas rpki-client -n -v -t /etc/rpki/arin.tal
rpki-client: rpki.arin.net/repository: pulling from network
rpki-client: rpki.arin.net/repository: loaded from cache
rpki-client: rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/5e4a23ea-e80a-403e-b08c-2171da2157d3.mft: certificate signature failure
rpki-client: all files parsed: generating output
rpki-client: Route Origin Authorizations: 0 (0 failed parse, 0 invalid)
rpki-client: Certificates: 2 (0 failed parse, 0 invalid)
rpki-client: Trust Anchor Locators: 1
rpki-client: Manifests: 2 (1 failed parse, 0 stale)
rpki-client: Certificate revocation lists: 1
rpki-client: Repositories: 1
rpki-client: Files removed: 0
rpki-client: VRP Entries: 0 (0 unique)

However, when running FORT, the below output gives very little to go on, I think operators would benefit from more insight into why the tree is not validating. (I believe FORT behaves correctly, just doesn't provide much debug info)

$ fort --tal=/etc/rpki/arin.tal --rrdp.enabled=true --output.roa=- --mode=standalone --log.output=console --log.level=debug --log.enabled=true
Aug 13 12:03:54 INF: Disabling validation logging on syslog.
Aug 13 12:03:54 INF: Disabling validation logging on standard streams.
Aug 13 12:03:54 INF: Console log output configured; disabling operation logging on syslog.
Aug 13 12:03:54 INF: (Operation Logs will be sent to the standard streams only.)
Aug 13 12:03:54 INF: Configuration {
Aug 13 12:03:54 INF: tal: /etc/rpki/arin.tal
Aug 13 12:03:54 INF: local-repository: /tmp/fort/repository
Aug 13 12:03:54 INF: sync-strategy: root-except-ta
Aug 13 12:03:54 INF: shuffle-uris: false
Aug 13 12:03:54 INF: maximum-certificate-depth: 32
Aug 13 12:03:54 INF: slurm: (null)
Aug 13 12:03:54 INF: mode: standalone
Aug 13 12:03:54 INF: work-offline: false
Aug 13 12:03:54 INF: server.address: (null)
Aug 13 12:03:54 INF: server.port: 323
Aug 13 12:03:54 INF: server.backlog: 128
Aug 13 12:03:54 INF: server.interval.validation: 3600
Aug 13 12:03:54 INF: server.interval.refresh: 3600
Aug 13 12:03:54 INF: server.interval.retry: 600
Aug 13 12:03:54 INF: server.interval.expire: 7200
Aug 13 12:03:54 INF: rsync.enabled: true
Aug 13 12:03:54 INF: rsync.priority: 50
Aug 13 12:03:54 INF: rsync.strategy: root-except-ta
Aug 13 12:03:54 INF: rsync.retry.count: 2
Aug 13 12:03:54 INF: rsync.retry.interval: 5
Aug 13 12:03:54 INF: rsync.program: rsync
Aug 13 12:03:54 INF: rsync.arguments-recursive:
Aug 13 12:03:54 INF:   --recursive
Aug 13 12:03:54 INF:   --delete
Aug 13 12:03:54 INF:   --times
Aug 13 12:03:54 INF:   --contimeout=20
Aug 13 12:03:54 INF:   --timeout=15
Aug 13 12:03:54 INF:   $REMOTE
Aug 13 12:03:54 INF:   $LOCAL
Aug 13 12:03:54 INF: rsync.arguments-flat:
Aug 13 12:03:54 INF:   --times
Aug 13 12:03:54 INF:   --contimeout=20
Aug 13 12:03:54 INF:   --timeout=15
Aug 13 12:03:54 INF:   --dirs
Aug 13 12:03:54 INF:   $REMOTE
Aug 13 12:03:54 INF:   $LOCAL
Aug 13 12:03:54 INF: rrdp.enabled: true
Aug 13 12:03:54 INF: rrdp.priority: 50
Aug 13 12:03:54 INF: rrdp.retry.count: 2
Aug 13 12:03:54 INF: rrdp.retry.interval: 5
Aug 13 12:03:54 INF: http.user-agent: fort/1.3.0
Aug 13 12:03:54 INF: http.connect-timeout: 30
Aug 13 12:03:54 INF: http.transfer-timeout: 0
Aug 13 12:03:54 INF: http.idle-timeout: 15
Aug 13 12:03:54 INF: http.ca-path: (null)
Aug 13 12:03:54 INF: log.enabled: true
Aug 13 12:03:54 INF: log.output: console
Aug 13 12:03:54 INF: log.level: debug
Aug 13 12:03:54 INF: log.tag: (null)
Aug 13 12:03:54 INF: log.facility: daemon
Aug 13 12:03:54 INF: log.file-name-format: global-url
Aug 13 12:03:54 INF: log.color-output: false
Aug 13 12:03:54 INF: validation-log.enabled: false
Aug 13 12:03:54 INF: validation-log.output: console
Aug 13 12:03:54 INF: validation-log.level: warning
Aug 13 12:03:54 INF: validation-log.tag: Validation
Aug 13 12:03:54 INF: validation-log.facility: daemon
Aug 13 12:03:54 INF: validation-log.file-name-format: global-url
Aug 13 12:03:54 INF: validation-log.color-output: false
Aug 13 12:03:54 INF: Custom incidences:
Aug 13 12:03:54 INF:   incid-hashalg-has-params (Signed Object's hash algorithm has NULL object as parameters): ignore
Aug 13 12:03:54 INF:   incid-obj-not-der-encoded (Object isn't DER encoded): ignore
Aug 13 12:03:54 INF:   incid-file-at-mft-not-found (File listed at manifest doesn't exist): error
Aug 13 12:03:54 INF:   incid-file-at-mft-hash-not-match (File hash listed at manifest doesn't match the actual file hash): error
Aug 13 12:03:54 INF: output.roa: -
Aug 13 12:03:54 INF: output.bgpsec: (null)
Aug 13 12:03:54 INF: asn1-decode-max-stack: 4096
Aug 13 12:03:54 INF: stale-repository-period: 43200
Aug 13 12:03:54 INF: }
Aug 13 12:03:54 DBG: rpkiManifest registered. Its nid is 1001.
Aug 13 12:03:54 DBG: signedObject registered. Its nid is 1002.
Aug 13 12:03:54 DBG: rpkiNotify registered. Its nid is 1003.
Aug 13 12:03:54 DBG: id-cp-ipAddr-asNumber (RFC 6484) registered. Its nid is 1004.
Aug 13 12:03:54 DBG: id-cp-ipAddr-asNumber-v2 (RFC 8360) registered. Its nid is 1005.
Aug 13 12:03:54 DBG: id-pe-ipAddrBlocks-v2 registered. Its nid is 1006.
Aug 13 12:03:54 DBG: id-pe-autonomousSysIds-v2 registered. Its nid is 1007.
Aug 13 12:03:54 DBG: id-kp-bgpsec-router registered. Its nid is 1008.
Aug 13 12:03:54 INF: Starting validation.
ASN,Prefix,Max prefix length
Aug 13 12:04:14 INF: Validation finished:
Aug 13 12:04:14 INF: - Valid Prefixes: 0
Aug 13 12:04:14 INF: - Valid Router Keys: 0
Aug 13 12:04:14 INF: - Real execution time: 20 secs.

Docker image

Hello there,

For my own use I created a Docker image based on the Debian FORT Validator package. See:

• https://github.com/ximon18/relyingpartydockerimages/tree/master/fortvalidator
• https://hub.docker.com/r/ximoneighteen/fortvalidator

If you've already got this in-progress or sorted and I missed it my apologies, I can switch to using your image and get rid of mine.

I would be happy to donate it to you in some way, either as-is or perhaps to help you time permitting (e.g. via a Pull Request) to add a Dockerfile (and if needed any supporting files) into your own GH repo (e.g. for auto-building via Docker Hub).

However I can imagine that you might want to make some changes, e.g.:

• Base it on building from sources using COPY . . or similar in your own GitHub repo, instead of downloading and installing a Debian package (only happens once when the image is built, users of the image don't care how the FORT Validator was installed in the image, but you can't build from a GH branch directly instead only after a DEB package has been produced).

• Base it on Alpine base image instead of Debian (seems to be the "in" trendy thing to do in the Docker image world, mainly I think to reduce the image size).

• Tweak FORT Validator to behave correctly when running as PID 1 (in my testing when run inside a Docker container I was unable to CTRL-C the running container presumably because when running as PID 1 it does not respond to signals as Docker requires). I worked around this by using tini.

• Tweak FORT Validator to not require syslog when not in standalone mode but instead log to stdout/stderr which is then visible via docker logs when running in -d mode with Docker, or via the console when running without -d. I worked around this by installing rsyslog in the image and by symbolically linking /var/log/syslog to /proc/1/fd/1 which is a bit of a hack.

• I chose to include the TAL files that you host in your GitHub repo, you may not wish to as you do not appear to bundle them with FORT Validator packages (did I miss them?). You may want to look at how Routinator handles this in its Docker image (see here) - disclaimer: I work for NLnet Labs, the developers of Routinator.

Best wishes,

Ximon

reload feature: restart validation on SIGHUP

Hello,

I believe a reload feature to be able to trigger revalidation and SLURM reread on SIGHUP would be nice to have, without daemon restart, RTR session teardown and RTR serial reset.

If it also would reread the json configuration file, that would be even better, but that probably adds additional complexity.

Thank you

Default sync strategy is strict, not root

When an user executes the rpki validator using the default values, the sync strategy is defined as strict when it should be root in order to execute the validation within a shorter period.

backtrace() on openbsd?

Tried to compile this on openbsd -current

job@vurt FORT-validator$ AUTOMAKE_VERSION=1.16 AUTOCONF_VERSION=2.69 autoreconf --install --force
configure.ac:12: installing './compile'
configure.ac:8: installing './install-sh'
configure.ac:8: installing './missing'
src/Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
job@vurt FORT-validator$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking for size_t... yes
checking for ssize_t... yes
checking for stdbool.h that conforms to C99... yes
checking for _Bool... yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for memset... yes
checking for socket... yes
checking for library containing pthread_create... -lpthread
checking for library containing X509_get_version... -lcrypto
checking for library containing backtrace... no
configure: error: unable to find backtrace() function

Ship/support HTTPS URIs in TALs

As per RFC8630, 4/5 RIRs have now published their TALs with an HTTPS URI in addition to rsync. This allows relying party software that supports RRDP to fetch data without relying on rsync at all, bring us closer to deprecating rsync.

The URIs are:

• https://rpki.afrinic.net/repository/AfriNIC.cer
• https://tal.apnic.net/apnic.cer
• https://rrdp.arin.net/arin-rpki-ta.cer
• https://rpki.ripe.net/ta/ripe-ncc-ta.cer

Does FORT support fetching the root certificate over HTTPS and will it prefer that if the TAL contains both URIs?

It would be great if you could support this and ship the included TALs with the new URIs added. Routinator 0.7.1 and the upcoming RIPE NCC Validator have support as well.

Provide prometheus endpoint

Hello,

currently there is no way to get validation statistics out of FORT. It would be nice if you could provide a prometheus HTTP endpoint for it.

The format is described here:

https://prometheus.io/docs/instrumenting/exposition_formats/

Also there seems to be a C library for it:

https://github.com/digitalocean/prometheus-client-c

Maybe you could also take a look a the metrics that Routinator exports so that there is similarity between the endpoints:

https://routinator.docs.nlnetlabs.nl/en/stable/monitoring.html

validator doesn't like sync caRepositories in strict mode

When the validator is executed for the first time in strict mode rpki_validator --tal arin.tal --sync-strategy strict --roa-output-file arin.csv and the default folder "repository" is generated manually.

the next result is displayed

INF: Configuration {
INF:   root.local-repository: repository/
INF:   root.sync-strategy: strict
INF:   root.maximum-certificate-depth: 32
INF:   tal.tal: ../../arin.tal
INF:   tal.shuffle-uris: false
INF:   rsync.program: rsync
INF:   rsync.arguments-recursive:
INF:     --recursive
INF:     --delete
INF:     --times
INF:     --contimeout=20
INF:     $REMOTE
INF:     $LOCAL
INF:   rsync.arguments-flat:
INF:     --times
INF:     --contimeout=20
INF:     $REMOTE
INF:     $LOCAL
INF:   output.color-output: false
INF:   output.output-file-name-format: global-url
INF:   output.roa-output-file: arin.csv
INF: }
INF: rpkiManifest registered. Its nid is 1061.
INF: signedObject registered. Its nid is 1062.
INF: rpkiNotify registered. Its nid is 1063.
INF: id-cp-ipAddr-asNumber (RFC 6484) registered. Its nid is 1064.
INF: id-cp-ipAddr-asNumber-v2 (RFC 8360) registered. Its nid is 1065.
INF: id-pe-ipAddrBlocks-v2 registered. Its nid is 1066.
INF: id-pe-autonomousSysIds-v2 registered. Its nid is 1067.
DBG: Going to RSYNC 'rsync://rpki.arin.net/repository/arin-rpki-ta.cer' ('repository/rpki.arin.net/repository/arin-rpki-ta.cer').
DBG: Executing RSYNC:
DBG:     rsync
DBG:     --times
DBG:     --contimeout=20
DBG:     rsync://rpki.arin.net/repository/arin-rpki-ta.cer
DBG:     repository/rpki.arin.net/repository/arin-rpki-ta.cer
DBG: Child terminated with error code 0.
DBG: TAL URI 'rsync://rpki.arin.net/repository/arin-rpki-ta.cer' {
DBG:   TA Certificate 'rsync://rpki.arin.net/repository/arin-rpki-ta.cer' {
DBG:     serial Number: 10D0C9F4328576D51CC73C042CFC15E9B3D6378
DBG:     caRepository: rsync://rpki.arin.net/repository/arin-rpki-ta/
DBG:     Going to RSYNC 'rsync://rpki.arin.net/repository/arin-rpki-ta/' ('repository/rpki.arin.net/repository/arin-rpki-ta/').
DBG:     Executing RSYNC:
DBG:         rsync
DBG:         --times
DBG:         --contimeout=20
DBG:         rsync://rpki.arin.net/repository/arin-rpki-ta/
DBG:         repository/rpki.arin.net/repository/arin-rpki-ta/
skipping directory .
DBG:     Child terminated with error code 0.
DBG:     IP {
DBG:       Prefix: 0.0.0.0/0
DBG:       Prefix: ::/0
DBG:     }
DBG:     ASN {
DBG:       ASN: 0-4294967295
DBG:     }
DBG:     Manifest 'rsync://rpki.arin.net/repository/arin-rpki-ta/arin-rpki-ta.mft' {
ERR:       rsync://rpki.arin.net/repository/arin-rpki-ta/arin-rpki-ta.mft: Could not open file 'repository/rpki.arin.net/repository/arin-rpki-ta/arin-rpki-ta.mft': No such file or directory
DBG:     }
DBG:   }
DBG:   Deleted 0 certificates from the stack.
DBG: }

Apparently rsync does not like to synchronize folders with the default command.
The following flags can be used to synchronize the repository without being recursive.

-d, --dirs transfer directories without recursing
-m, --prune-empty-dirs prune empty directory chains from file-list

• Source: https://superuser.com/questions/1074786/linux-rsync-without-recursive-folders

Use previous valid SLURM configuration on SLURM error

SLURM documentation:

Fort reloads the SLURM files during every validation cycle. If the new configuration is invalid, it is treated as nonexistent. Note that this means that an isolated mistake will temporarily drop all your SLURM overrides. This is intended to change in a future revision of Fort, in which the validator will fall back to the previous valid SLURM configuration on error.

To propose any other solutions, comment below please.

Support the RPKI Repository Delta Protocol (RFC8182)

Hi,

Do you have plans to support the RPKI Repository Delta Protocol (RRDP)?
https://tools.ietf.org/html/rfc8182

This is an additional protocol that was invented in response to issues with rsync (which I will not repeat here for brevity). It has seen quite some deployment both in publishers and validators. As you may have seen I started a discussion in the IETF sidrops WG about deprecating rsync altogether and moving to RRDP.

Fort is one of two remaining validators, that I know of, which do not support RRDP. So, it would be really great if you are open to adding this. And greater still if you, or I as your proxy, could report those plans to the IETF.

configure: error: unable to find the X509_get_version() function

tried to compile on Linux, but some error popped up configure: error: unable to find the X509_get_version() function

root@rpki:~/source/FORT-validator# lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 9.11 (stretch)
Release:	9.11
Codename:	stretch
root@rpki:~/source/FORT-validator# dpkg -l | grep openssl
ii  openssl                         1.1.0k-1~deb9u1                amd64        Secure Sockets Layer toolkit - cryptographic utility
ii  python-openssl                  16.2.0-1                       all          Python 2 wrapper around the OpenSSL library
root@rpki:~/source/FORT-validator#

root@rpki:~/source/FORT-validator# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking for size_t... yes
checking for ssize_t... yes
checking for stdbool.h that conforms to C99... yes
checking for _Bool... yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for memset... yes
checking for socket... yes
checking for library containing pthread_create... -lpthread
checking for library containing X509_get_version... no
configure: error: unable to find the X509_get_version() function
root@rpki:~/source/FORT-validator#

revise the /etc/fort/config.json

Dear Support,
We followed up the APNIC guideline to revise the /etc/fort/config.json file.
https://blog.apnic.net/2019/10/28/how-to-installing-an-rpki-validator/

But the fort service can't be start. Would you please provide us the setup steps?

Thanks.

Support https URIs in TALs

Hi,

Could you please support HTTPS in TALs as per:
https://tools.ietf.org/html/rfc8630

This would help us in automating end-to-end interop testing of our RPKI CA software (krill). Of course, we only have a test TA (and can work around the issue with effort). However, supporting this will also allow RIRs to publish their TA certs using HTTPS - which would allow for more robustness (e.g. CDNs).

Thanks
Tim

Wrong "serial number X is not unique" error is displayed when an MFT expired error happens

When RPKI is validating a repository and a MFT file is expired, the corresponding error is displayed. However, RPKI tries to validate again that MFT and then, a not corresponding "serial number X is not unique" error is displayed

ERR: rsync://localhost/repository/axtel-mft.mft: Manifest is expired. (nextUpdate: 2019/08/01 16:45:40)
INF: rsync://localhost/repository/axtel-ca.cer: Retrying repository download to discard 'transient inconsistency' manifest issue (see RFC 6481 section 5) 'rsync://localhost/repository/'
WRN: rsync://localhost/repository/axtel-mft.mft: Serial number '3' is not unique. (Also found in 'rsync://localhost/repository/axtel-mft.mft'.)
WRN: rsync://localhost/repository/axtel-mft.mft: Subject name '1564695948934085260' is not unique. (Also found in 'rsync://localhost/repository/axtel-mft.mft'.)
ERR: rsync://localhost/repository/axtel-mft.mft: Manifest is expired. (nextUpdate: 2019/08/01 16:45:40)

The real problem is that MFT is expired, not that its serial number is not unique.

Log displays "Valid ROAs" label for valid prefixes info

When FORT is running in server mode and log level info, the following information about validation is logged:

INF: Validation finished:
INF: - Valid ROAs: 3
INF: - Valid Router Keys: 0
INF: - Current serial number is 1.
INF: - Real execution time: 0 secs.

The label "Valid ROAS" should be "Valid prefixes" because it is related to the number of prefixes validated in the last execution.

"Programming error" error message when a ROA advertise a subset that is not allowed to advertise

When the rpki validator tries to validate a ROA that contains the ip resources 1.128.0.0-1.255.255.255 and its EE it is allowed to sign the ip subset 1.0.0.0-1.255.0.0, the following error message is displayed:

ERR: rsync://localhost/repository/root-roa.roa: Programming error: Unknown comparison value: 7
ERR: rsync://localhost/repository/root-roa.roa: ROA is not allowed to advertise 1.128.0.0/9.
DBG:

Fort serfaults after multiple "doesn't have files with extension '.slurm'" events

Fort serfaults after multiple doesn't have files with extension '.slurm'

Sep 17 23:25:22 rpki fort[1615]: Sep 17 23:25:22 ERR: Client socket read interrupted
Sep 17 23:25:22 rpki fort[1615]: Sep 17 23:25:22 ERR: - Connection reset by peer
Sep 18 00:29:44 rpki fort[1615]: Sep 18 00:29:44 WRN: Location '/etc/fort/slurm/' doesn't have files with extension '.slurm'
Sep 18 01:32:12 rpki fort[1615]: Sep 18 01:32:12 WRN: Location '/etc/fort/slurm/' doesn't have files with extension '.slurm'
Sep 18 02:34:57 rpki fort[1615]: Sep 18 02:34:57 WRN: Location '/etc/fort/slurm/' doesn't have files with extension '.slurm'
Sep 18 03:49:18 rpki fort[1615]: Sep 18 03:49:18 WRN: Location '/etc/fort/slurm/' doesn't have files with extension '.slurm'
Sep 18 04:58:44 rpki fort[1615]: Sep 18 04:58:44 WRN: Location '/etc/fort/slurm/' doesn't have files with extension '.slurm'
Sep 18 05:59:05 rpki fort[1615]: Segmentation Fault. Stack trace:
Sep 18 05:59:05 rpki fort[1615]: /usr/bin/fort(print_stack_trace+0x30) [0x55cdc8dd0b20]
Sep 18 05:59:05 rpki fort[1615]: /usr/bin/fort(+0x20bf6) [0x55cdc8dd0bf6]
Sep 18 05:59:05 rpki fort[1615]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x14140) [0x7f5f7d953140]
Sep 18 05:59:05 rpki fort[1615]: /usr/bin/fort(reqs_errors_rem_uri+0x25) [0x55cdc8dd57a5]
Sep 18 05:59:05 rpki fort[1615]: /usr/bin/fort(download_files+0x5af) [0x55cdc8de92bf]
Sep 18 05:59:05 rpki fort[1615]: /usr/bin/fort(certificate_traverse+0xc89) [0x55cdc8de1819]
Sep 18 05:59:05 rpki fort[1615]: /usr/bin/fort(+0x336ab) [0x55cdc8de36ab]
Sep 18 05:59:05 rpki fort[1615]: /usr/bin/fort(+0x340b8) [0x55cdc8de40b8]
Sep 18 05:59:05 rpki fort[1615]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x8ea7) [0x7f5f7d947ea7]
Sep 18 05:59:05 rpki fort[1615]: /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f5f7d877eaf]
Sep 18 05:59:05 rpki fort[1615]: (Stack size was 10.)
Sep 18 05:59:05 rpki systemd[1]: fort.service: Main process exited, code=exited, status=1/FAILURE

$ fort --version
fort 1.4.0

fort.service failed

Hi, my fort service suddenly stopped. This is my systemctl status fort output

fort[82801]: /usr/bin/fort() [0x4147b1]
/usr/bin/fort(deferstack_pop+0x2f) [0x4149bf]
/usr/bin/fort() [0x4288e4]
/usr/bin/fort() [0x4292e1]
/lib64/libpthread.so.0(+0x7ea5) [0x7fdea38fbea5]
/lib64/libc.so.6(clone+0x6d) [0x7fdea36248dd]

I have installed 1.4.2 version using rpm package...
thank you

Add --log argument

if (such as in #25) the fort server is forked to the background, it could be useful to be able to specify a filesystem path name which is the stdout/stderr equivalent. perhaps a `--log=/var/log/fort.log' option is useful vs only 'console' or 'syslog'

Some ROAs are not processes/send via RTR or dumped to CSV

ROA from rsync://rpki.ripe.net/repository/DEFAULT/87/f7c4a2-b606-4292-b9f7-fa3c4ef5edf6/1/5WObKiUO8AYk4h7mlYN_9Mxhv8s.roa file never signaled via RTR or dumped to CSV. The same ROA processed by routinator 3000 without issues and produces "81.27.160.0/20-24 55002"

The same subnet with different origin from the file rsync://rpki.ripe.net/repository/DEFAULT/87/f7c4a2-b606-4292-b9f7-fa3c4ef5edf6/1/hHDR3YRXyWPkC3ahQoAACw39Gto.roa processed by FORT-validator without issues and gives "81.27.160.0/20-20 12611"

Will not bind to IPv6 address

Hello,

fort 1.4.2 will not bind to an IPv6 address. I tried to bind it to "::" (IPv6 Any) but it wouldn't do that even though the log says it does:

Dec  9 11:35:31 noc2 fort[25499]: INF: Attempting to bind socket to address '::', port '323'.
Dec  9 11:35:31 noc2 fort[25499]: INF: Success; bound to address '::', port '323'.
Dec  9 11:35:31 noc2 fort[25499]: INF: Starting validation.

But it is not bound, netstat -tulpen shows no open port, connecting is not possible.

When I start fort without a server.address it binds to 0.0.0.0 which is v4 only.

configuration is:

{
	"tal": "/etc/fort/tal",
	"local-repository": "/var/lib/fort",
	"slurm": "/etc/fort/slurm/",
	"server": {
		"address": ["::"],
		"port": "323"
	},
	"log": {
		"output": "syslog",
		"level": "info"
	}
}

I installed it via the .deb from the releases here on github, Debian version is 10.6.

double free in certstack_destroy()?

Tested on OpenBSD 7.0.

Is the right type of list being used?

(gdb) run --tal=/home/job/source/rpkimancer/loopki/tals/TA.tal
Starting program: /usr/local/bin/fort --tal=/home/job/source/rpkimancer/loopki/tals/TA.tal
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
Aug 30 18:00:16 INF: Disabling validation logging on syslog.
Aug 30 18:00:16 INF: Disabling validation logging on standard streams.
Aug 30 18:00:16 INF: Console log output configured; disabling operation logging on syslog.
Aug 30 18:00:16 INF: (Operation Logs will be sent to the standard streams only.)
Aug 30 18:00:16 WRN: First validation cycle has begun, wait until the next notification to connect your router(s)
[New process 7532]
fort(7532) in free(): chunk is already free 0xe416811bb0
Program received signal SIGABRT, Aborted.
[Switching to thread 502378]
thrkill () at /tmp/-:3
3       /tmp/-: No such file or directory.
        in /tmp/-
Current language:  auto; currently asm

(gdb) bt
#0  thrkill () at /tmp/-:3
#1  0x000000e3970eb08e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
#2  0x000000e3970ba386 in wrterror (d=Variable "d" is not available.
) at /usr/src/lib/libc/stdlib/malloc.c:307
#3  0x000000e3970bdd1a in find_chunknum (d=Variable "d" is not available.
) at /usr/src/lib/libc/stdlib/malloc.c:1066
#4  0x000000e3970ba8e9 in ofree (argpool=0xe428639b00, p=0xe416811bb0, clear=0, check=Variable "check" is not available.
) at /usr/src/lib/libc/stdlib/malloc.c:1409
#5  0x000000e3970ba5cb in free (ptr=0xe416811bb0) at /usr/src/lib/libc/stdlib/malloc.c:1470
#6  0x000000e12bd1c5ed in certstack_destroy (stack=0xe4167f4ae0) at cert_stack.c:215
#7  0x000000e12bd26825 in validation_destroy (state=0xe416813c00) at state.c:156
#8  0x000000e12bd34b42 in handle_tal_uri (tal=Variable "tal" is not available.
) at object/tal.c:633
#9  0x000000e12bd347d6 in do_file_validation (thread_arg=Variable "thread_arg" is not available.
) at object/tal.c:643
#10 0x000000e12bd45c4b in tasks_poll (arg=0xe381c2bc00) at thread/thread_pool.c:224
#11 0x000000e40d93ec11 in _rthread_start (v=Unhandled dwarf expression opcode 0xa3
) at /usr/src/lib/librthread/rthread.c:96
#12 0x000000e3970ed7da in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84
#13 0x000000e3970ed7da in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84
Previous frame identical to this frame (corrupt stack?)

(gdb) up 6
#6  0x000000e12bd1c5ed in certstack_destroy (stack=0xe4167f4ae0) at cert_stack.c:215
215                     free(level);
Current language:  auto; currently minimal

(gdb) list
210
211             stack_size = 0;
212             while (!SLIST_EMPTY(&stack->levels)) {
213                     level = SLIST_FIRST(&stack->levels);
214                     SLIST_REMOVE_HEAD(&stack->levels, next);
215                     free(level);
216                     stack_size++;
217             }
218             pr_val_debug("Deleted %u stacked levels.", stack_size);

RPM package for v1.5.1

Will a RPM package be available for the last version?

J

FORT using server mode cannot be interrupted on OpenBSD with SIGINT signal (Control+C)

When FORT is running in server mode on OpenBSD, if the user tries to interrupt the process sending a SIGINT signal (Control+C) the process keeps running as it is shown on the images below:

FORT, server mode, rsync strategy off, local repository

FORT, server mode, validating RIPE TAL

rpki-validator has memory leaks when validating repository

Some memory leaks were discovered using Valgrind tool while rpki-validator is validating a repository. The output for valgrind report is included as attachments for this issue
afrinic-valgrind-output.txt
arin-valgrind-output.txt
lacnic-valgrind-output.txt
ripe-valgrind-output.txt

fort never leaves validation stage when started with IPv6 server address

v1.2.1 in docker/alpine on debian10

Normal startup:

2020-06-12T13:46:46.338052584Z DBG: /etc/fort/tal/ripe.tal: }
2020-06-12T13:46:46.372073001Z DBG: /etc/fort/tal/ripe.tal: Deleted 0 deferred certificates.
2020-06-12T13:46:46.372120704Z DBG: /etc/fort/tal/ripe.tal: Deleting 0 stacked x509s.
2020-06-12T13:46:46.372131224Z DBG: /etc/fort/tal/ripe.tal: Deleted 0 metadatas.
2020-06-12T13:46:46.372137942Z DBG: /etc/fort/tal/ripe.tal: }
2020-06-12T13:46:46.372144047Z INF: Validation finished:
2020-06-12T13:46:46.372150649Z INF: - Valid Prefixes: 153246
2020-06-12T13:46:46.372157211Z INF: - Valid Router Keys: 0
2020-06-12T13:46:46.372163743Z INF: - Current serial number is 0.
2020-06-12T13:46:46.372170613Z INF: - Real execution time: 284 secs.
2020-06-12T13:46:46.372177172Z DBG: Waiting for client connections...
2020-06-12T13:46:51.123307698Z INF: Client accepted [ID 4]: <RTR client IPv4 address>

If started with --server.address it never leaves

2020-06-15T12:26:22.520426006Z DBG: /etc/fort/tal/apnic.tal: }
2020-06-15T12:26:22.520433836Z DBG: /etc/fort/tal/apnic.tal: Deleted 0 deferred certificates.
2020-06-15T12:26:22.520440308Z DBG: /etc/fort/tal/apnic.tal: Deleting 0 stacked x509s.
2020-06-15T12:26:22.520450062Z DBG: /etc/fort/tal/apnic.tal: Deleted 0 metadatas.
2020-06-15T12:26:22.520462453Z DBG: /etc/fort/tal/apnic.tal: }

I want fort to accept RTR sessions on both IPv4 and IPv6 sockets, by default it only accepts IPv4 sessions.

ROAs, MFTs and CAs created with revoked certs are valids

If an issuer revokes a CA or an EE cert from a repository, the corresponding CAs, ROAs and MFTs are processed as valid ones. According to RFC 6487 , these CAs, ROAs and MFTs from a revoked cert should be ignored:

Certificate validation entails verifying that all of the following conditions hold, in addition to the certification path validation criteria specified in Section 6 of [RFC5280]:
...
5. The issuer has not revoked the certificate. A revoked certificate is identified by the certificate's serial number being listed on the issuer's current CRL, as identified by the CRLDP of the certificate, the CRL is itself valid, and the public key used to verify the signature on the CRL is the same public key used to verify the certificate itself.
...

Fort's validation produces no router keys

Hola, repentinamente el proceso de fort falló en todas las instancias que instalamos:

Oct 11 19:04:11 srv-fort fort[2950289]: CRT: /etc/fort/tal/ripe.tal: Attempted to pop empty X509 stack
Oct 11 19:04:11 srv-fort fort[2950289]: Stack trace:
Oct 11 19:04:11 srv-fort fort[2950289]: /usr/bin/fort(print_stack_trace+0x32) [0x55660962b4f2]
Oct 11 19:04:11 srv-fort fort[2950289]: /usr/bin/fort(pr_crit+0x8f) [0x55660962d8af]
Oct 11 19:04:11 srv-fort fort[2950289]: /usr/bin/fort(+0x1b297) [0x556609628297]
Oct 11 19:04:11 srv-fort fort[2950289]: /usr/bin/fort(deferstack_pop+0x3b) [0x55660962847b]
Oct 11 19:04:11 srv-fort fort[2950289]: /usr/bin/fort(+0x2da28) [0x55660963aa28]
Oct 11 19:04:11 srv-fort fort[2950289]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x9609) [0x7ff03fea2609]
Oct 11 19:04:11 srv-fort fort[2950289]: /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7ff03fdc9293]
Oct 11 19:04:11 srv-fort fort[2950289]: (Stack size was 7.)
Oct 11 19:04:11 srv-fort fort[2950289]: ERR: rsync://rpki.apnic.net/member_repository/A91DE10F/60EA5C2CB5D311E7B6A2DD5DC4F9AE02/NDyCcTdhxY6CRQ2UqleWffm0bxU.mft: Unknown message digest sha256
Oct 11 19:04:11 srv-fort systemd[1]: fort.service: Main process exited, code=exited, status=255/EXCEPTION
Oct 11 19:04:12 srv-fort systemd[1]: fort.service: Failed with result 'exit-code'.

Reiniciamos el servicio y todo funcionó correctamente.

¿Podrían darnos apoyo para identificar el problema que lo causó?

Saludos,
Mauricio

1.5.1 segmentation fault

I used fort 1.4.2 for a long time, now tried to replace it with 1.5.1 ... and segmentation fault
The same , running as a service , or manually with --configuration-file
The same , with my old config.json and with the fresh-new one (almost empty) from deb file.

The OS is DEBIAN 10.10
Linux rpki 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 GNU/Linux

This is from syslog

fort: INF: Disabling validation logging on syslog.
fort: INF: Disabling validation logging on standard streams.
fort[4200]: Aug 9 10:16:06 INF: Disabling validation logging on syslog.
fort[4200]: Aug 9 10:16:06 INF: Disabling validation logging on standard streams.
fort[4200]: Aug 9 10:16:06 INF: Syslog log output configured; disabling operation logging on standard streams.
fort[4200]: Aug 9 10:16:06 INF: (Operation Logs will be sent to syslog only.)
fort: INF: Syslog log output configured; disabling operation logging on standard streams.
fort: INF: (Operation Logs will be sent to syslog only.)
fort[4200]: /usr/bin/fort(+0x223bf)[0x5651d12a63bf]
fort[4200]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x14140)[0x7f7ca504d140]
fort[4200]: /lib/x86_64-linux-gnu/libc.so.6(+0x9d7a6)[0x7f7ca4f117a6]
fort[4200]: /lib/x86_64-linux-gnu/libc.so.6(__strdup+0xf)[0x7f7ca4f01d9f]
fort[4200]: /usr/bin/fort(+0x3ce76)[0x5651d12c0e76]
fort[4200]: /usr/bin/fort(rtr_start+0x9f)[0x5651d12c1b3f]
fort[4200]: /usr/bin/fort(main+0x170)[0x5651d12a1450]
fort[4200]: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f7ca4e9acca]
fort[4200]: /usr/bin/fort(_start+0x2a)[0x5651d12a14aa]

Installed 1.5.0 and all is working, with no issues.

[1.5.0] Mode standalone sometimes generates no output

Hello,

currently i run some tests with fort 1.5.0 and observe some unusual behaviour. On a Raspberry Pi 4 with 4 GB (raspberry pi os lite 64bit) i did every half an hour the validation run with fort --mode standalone --log.level debug --validation-log.enabled=true --validation-log.level warning --local-repository /home/pi/.rpki-cache --output.roa /home/pi/csv/$date.csv --tal /home/pi/tals. Most of the time it runs smoothly through the validation within 6 to 10 minutes. But sometimes (about 10 time within 2 days) there is an empty csv file and more often it generates the output 1-2 hours after the validation started. The Log shows different behaviour. Sometimes there are validation entries and sometimes not. Also a timeout occurs, when the output is empty.

I thought maybe it' related to the SBC and so i did a one day test on a powerful server (Ubuntu 20.04). In this one day, there were only 2 empty files and no delay on the output generation. So it's kind of related to the raspberry, but i think the 2 empty files are still problematic.

Now i upload some log outputs of the different cases(date always means the start time CET).
Raspberry pi 4 empty output:
2021-04-02_16-00.log
2021-04-02_17-30.log
2021-04-03_00-00.log
2021-04-03_04-00.log
2021-04-04_05-30.log

Raspberry pi 4 validate over hours but full output:
2021-04-02_12-30.log
2021-04-02_13-30.log
2021-04-02_19-30.log
2021-04-03_09-30.log

Ubuntu Server no output:
2021-04-07_00-00.log
2021-04-07_07-30.log

fort 1.4.2 and 1.2.1 crashes regularly, after 3-5 days uptime.

Segmentation Fault. Stack trace:
/usr/local/bin/fort(print_stack_trace+0x23) [0x55d196279de3]
/usr/local/bin/fort(+0x1ee96) [0x55d196279e96]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110e0) [0x7f46201f20e0]
/usr/local/bin/fort(+0x34e99) [0x55d19628fe99]
/usr/local/bin/fort(rtrhandler_handle_roa_v4+0x52) [0x55d196290fa2]
/usr/local/bin/fort(handle_roa_v4+0x32) [0x55d1962936f2]
/usr/local/bin/fort(vhandler_handle_roa_v4+0x39) [0x55d19627f2d9]
/usr/local/bin/fort(roa_traverse+0x64f) [0x55d1962876ef]
/usr/local/bin/fort(rpp_traverse+0x38) [0x55d19627daf8]
/usr/local/bin/fort(certificate_traverse+0x9ac) [0x55d196285fec]
/usr/local/bin/fort(+0x2d5e3) [0x55d1962885e3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x74a4) [0x7f46201e84a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f461ff2ad0f]
(Stack size was 13.)

fort v1.5.1-7 crashing at 2d validation cycle starting

I'm running FORT validator fort v1.5.1-7-g274dc14 in Ubuntu 20.04 (compiled), with 4G RAM.

Everything starts Ok, the first validation cycle completes without issues (I'm able to connect routers to it and wok as expected)... but right when 2d validation cycle starts the process crashes (i've set the validation interval to 15 minutes in this case):

root@zulu:~# tail -f /var/log/fortd.log

Sep 28 16:16:19 INF: Disabling validation logging on syslog.
Sep 28 16:16:19 INF: Disabling validation logging on standard streams.
Sep 28 16:16:19 INF: Console log output configured; disabling operation logging on syslog.
Sep 28 16:16:19 INF: (Operation Logs will be sent to the standard streams only.)
Sep 28 16:16:19 WRN: First validation cycle has begun, wait until the next notification to connect your router(s)
Sep 28 16:20:49 WRN: First validation cycle successfully ended, now you can connect your router(s)
/usr/local/bin/fort(+0x23623)[0x555def5c8623]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7fd9ab21f3c0]
/lib/x86_64-linux-gnu/libc.so.6(+0x18b675)[0x7fd9ab1a3675]
/usr/local/bin/fort(+0x380f0)[0x555def5dd0f0]
/usr/local/bin/fort(deltas_head_for_each+0x62)[0x555def5dca92]
/usr/local/bin/fort(rrdp_process_deltas+0x42)[0x555def5de4f2]
/usr/local/bin/fort(+0x376ee)[0x555def5dc6ee]
/usr/local/bin/fort(+0x31673)[0x555def5d6673]
/usr/local/bin/fort(certificate_traverse+0x3bd)[0x555def5d7f4d]
/usr/local/bin/fort(+0x3577a)[0x555def5da77a]
/usr/local/bin/fort(+0x362a1)[0x555def5db2a1]
/usr/local/bin/fort(+0x45fbc)[0x555def5eafbc]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x9609)[0x7fd9ab213609]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43)[0x7fd9ab13a293]

This is my config file (/etc/fort/config.json):

{
"tal": "/var/fort/tal",
"local-repository": "/var/fort/repository",
"rsync-strategy": "root",
"shuffle-uris": true,
"mode": "server",

"server": {
	"port": "323",
	"backlog": 16,
	"interval": {
            "validation": 900,
            "refresh": 900,
            "retry": 600,
            "expire": 7200
        }
},

"log": {
	"color-output": true,
	"file-name-format": "file-name"
},

"rsync": {
	"program": "rsync",
	"arguments-recursive": [
		"--recursive",
		"--times",
		"$REMOTE",
		"$LOCAL"
	],
	"arguments-flat": [
		"--times",
		"--dirs",
		"$REMOTE",
		"$LOCAL"
	]
},

"incidences": [
	{
		"name": "incid-hashalg-has-params",
		"action": "ignore"
	}
],

"output": {
	"roa": "/var/fort/fort_roas.csv"
}

}

Programming error when a ROA without prefixes is validated

When FORT is validating a repository, if any of the ROAs included doesn't contain any IP prefixes, the following error message is displayed :

sudo fort --tal test.tal --local-repository=/home/user/ --sync-strategy=off --configuration-file=fort.json
INF: Configuration {
INF:   tal: test.tal
INF:   local-repository: /home/user/
INF:   sync-strategy: off
INF:   shuffle-uris: false
INF:   maximum-certificate-depth: 32
INF:   slurm: (null)
INF:   mode: server
INF:   server.address: (null)
INF:   server.port: 323
INF:   server.backlog: 128
INF:   server.validation-interval: 3600
INF:   rsync.program: rsync
INF:   rsync.arguments-recursive:
INF:     --recursive
INF:     --delete
INF:     --times
INF:     --contimeout=20
INF:     $REMOTE
INF:     $LOCAL
INF:   rsync.arguments-flat:
INF:     --times
INF:     --contimeout=20
INF:     --dirs
INF:     $REMOTE
INF:     $LOCAL
INF:   log.color-output: false
INF:   log.file-name-format: global-url
INF:   Custom incidences:
INF:     Signed Object's hash algorithm has NULL object as parameters: ignore
INF:   output.roa: /home/user/fort_roas.csv
INF: }
INF: rpkiManifest registered. Its nid is 1195.
INF: signedObject registered. Its nid is 1196.
INF: rpkiNotify registered. Its nid is 1197.
INF: id-cp-ipAddr-asNumber (RFC 6484) registered. Its nid is 1198.
INF: id-cp-ipAddr-asNumber-v2 (RFC 8360) registered. Its nid is 1199.
INF: id-pe-ipAddrBlocks-v2 registered. Its nid is 1200.
INF: id-pe-autonomousSysIds-v2 registered. Its nid is 1201.
Attempting to bind socket to address 'any', port '323'.
Success.
CRT: rsync://localhost/repository/root-roa2.roa: Programming error: ipAddrBlocks array is NULL.
Stack trace:
 fort(print_stack_trace+0x32) [0x5619d3035272]
 fort(pr_crit+0x10e) [0x5619d303684e]
 fort(+0x240ac) [0x5619d303f0ac]
 fort(rpp_traverse+0x48) [0x5619d3038218]
 fort(certificate_traverse+0x20b) [0x5619d303dd1b]
 fort(+0x243ca) [0x5619d303f3ca]
 fort(foreach_uri+0x72) [0x5619d303f7e2]
 fort(+0x2492c) [0x5619d303f92c]
 fort(process_file_or_dir+0x5e) [0x5619d303476e]
 fort(perform_standalone_validation+0x34) [0x5619d303f9b4]
 fort(vrps_update+0x65) [0x5619d3044c65]
 fort(+0x1de43) [0x5619d3038e43]
 /lib/x86_64-linux-gnu/libpthread.so.0(+0x76db) [0x7f9c880cc6db]
 /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f9c87df588f]
(Stack size was 14.)

Segmentation Fault when an invalid TAL file is validated

When an user tries to validate a TAL file that contains an unexpected or invalid format (for example, a TAL file without the line break between the repository url and public key), the following stack trace is displayed:

[user@localhost]# rpki_validator ARIN/ arin2.tal 
rpkiManifest registered. Its nid is 1061.
signedObject registered. Its nid is 1062.
Segmentation Fault. Stack trace:
  rpki_validator(print_stack_trace+0x1a) [0x40516a]
  rpki_validator() [0x405214]
  /lib64/libpthread.so.0(+0xf5d0) [0x7f1df80b95d0]
  rpki_validator(tal_load+0x294) [0x40b3f4]
  rpki_validator(main+0xd1) [0x404a61]
  /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f1df7cff3d5]
  rpki_validator() [0x404add]
(Stack size was 7.)

TAL file "arin2.tal" content:

sync://rpki.arin.net/repository/arin-rpki-ta.cer
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3lZPjbHvMRV5sDDqfLc/685th5FnreHMJjg8pEZUbG8Y8TQxSBsDebbsDpl3Ov3Cj1WtdrJ3CIfQODCPrrJdOBSrMATeUbPC+JlNf2SRP3UB+VJFgtTj0RN8cEYIuhBW5t6AxQbHhdNQH+A1F/OJdw0q9da2U29Lx85nfFxvnC1EpK9CbLJS4m37+RlpNbT1cba+b+loXpx0Qcb1C4UpJCGDy7uNf5w6/+l7RpATAHqqsX4qCtwwDYlbHzp2xk9owF3mkCxzl0HwncO+sEHHeaL3OjtwdIGrRGeHi2Mpt+mvWHhtQqVG+51MHTyg+nIjWFKKGx1Q9+KDx4wJStwveQIDAQAB

This issue also happens when the TAL file is empty.

failure scenarios, monitoring and glibc recommendations

Hello,

I'm currently evaluating the FORT validator and have a few questions.

I'm concerned about bugs, misconfigurations or other issues (in all RP/RTR setups, not specific to FORT) that will cause obsolete VRP's on the production routers, because I believe this is the worst-case in RPKI ROV deployments.

I worry about how issues like:

• crash bugs in the validation code
• hangs during RPKI validation (even in rsync), that block the entire validation
• memory allocation failures (failed malloc)
• Linux OOM-killer

impact the RTR service:

The best-case scenario for me is that the RTR server goes down completely and all RTR sessions die, so that the production routers are aware there is a problem with that RTR end point and stop using it (failing over to other RTR servers, if available).

Is that the expected behavior in FORT? It is one-process with multiple threads, so a crash would achieve this, correct?

I'm also thinking about monitoring (maybe without regex'ing logfile)

• how to best monitor for periodic successful validation runs (thinking about how to trigger an ALIVE signal to something like healthchecks.io )
• how to monitor validation run time (like healthchecks.io run time measurement )

Other than parsing strings from logfiles, how could we best achieve this? Is there some stat socket that we could query to check for things like last validation start time and last validation completion time?

Regarding glibc memory allocation: when using glibc, should we just use MALLOC_ARENA_MAX=2 always or only in environments with limited memory? If this is a good middle ground, I'd prefer to just use it always in the glibc world and have systemd unit files set this.

Include ebuild for Gentoo

Check the proposal made by @alarig (thanks for this!), and include it in the installation guide.

Here is the ebuild, in case you have comments: https://git.grifon.fr/alarig/SwordArMor-gentoo-overlay/src/branch/master/net-misc/FORT-validator/FORT-validator-1.1.3.ebuild
I didn’t added the other sandbox options, as I don’t see how to do this simply.

I will drop the filecaps workaround when the “user-fork” will be released.

Originally posted by @alarig in #22 (comment)

Missing files don't result in a manifest being considered invalid

In a MITM scenario where an attacker forces a downgrade of the connection from RRDP to rsync, and strategically withholds certain .roa files from the view of the validator being attacked, the resulting set of VRPs will be incomplete and can cause severe operational issues.

When a manifest is valid (manifest is parsable, CRL exists and is not expired, and manifest is signed with keys not revoked by the CRL), and references files which do not exist in the repository at hand, the publication point should be considered compromised.

So in the case of LACNIC where an End User (self-hosted) RPKI publication point misses a few .roa files, the validator can proceed to consider all data from all RPs it could reach valid, except the data from the publication point where files were missing.

Output ROA file is not generated if rsync hangs on one of the repositories

Output ROA file is not generated if rsync hangs on one of the repositories.
See attachment with descriptions.
fort.conf.txt
rsync-hangs.txt