Program Arguments

Index

Syntax
Arguments
Deprecated arguments

Syntax

fort
	[--help]
	[--usage]
	[--version]
	[--configuration-file=<file>]
	[--tal=<file>|<directory>]
	[--local-repository=<directory>]
	[--maximum-certificate-depth=<unsigned integer>]
	[--slurm=<file>|<directory>]
	[--mode=server|standalone]
	[--work-offline=true|false]
	[--daemon=true|false]
	[--server.address=<sequence of strings>]
	[--server.port=<string>]
	[--server.backlog=<unsigned integer>]
	[--server.interval.validation=<unsigned integer>]
	[--server.interval.refresh=<unsigned integer>]
	[--server.interval.retry=<unsigned integer>]
	[--server.interval.expire=<unsigned integer>]
	[--server.deltas.lifetime=<unsigned integer>]
	[--rsync.enabled=true|false]
	[--rsync.priority=<unsigned integer>]
	[--rsync.retry.count=<unsigned integer>]
	[--rsync.retry.interval=<unsigned integer>]
	[--http.enabled=true|false]
	[--http.priority=<unsigned integer>]
	[--http.retry.count=<unsigned integer>]
	[--http.retry.interval=<unsigned integer>]
	[--http.user-agent=<string>]
	[--http.max-redirs=<unsigned integer>]
	[--http.connect-timeout=<unsigned integer>]
	[--http.transfer-timeout=<unsigned integer>]
	[--http.low-speed-limit=<unsigned integer>]
	[--http.low-speed-time=<unsigned integer>]
	[--http.max-file-size=<unsigned integer>]
	[--http.ca-path=<directory>]
	[--log.enabled=true|false]
	[--log.output=syslog|console]
	[--log.level=error|warning|info|debug]
	[--log.tag=<string>]
	[--log.facility=auth|authpriv|cron|daemon|ftp|lpr|mail|news|user|uucp|local0|local1|local2|local3|local4|local5|local6|local7]
	[--log.file-name-format=global-url|local-path|file-name]
	[--log.color-output=true|false]
	[--validation-log.enabled=true|false]
	[--validation-log.output=syslog|console]
	[--validation-log.level=error|warning|info|debug]
	[--validation-log.tag=<string>]
	[--validation-log.facility=auth|authpriv|cron|daemon|ftp|lpr|mail|news|user|uucp|local0|local1|local2|local3|local4|local5|local6|local7]
	[--validation-log.file-name-format=global-url|local-path|file-name]
	[--validation-log.color-output=true|false]
	[--output.roa=<file>]
	[--output.bgpsec=<file>]
	[--output.format=csv|json]
	[--asn1-decode-max-stack=<unsigned integer>]
	[--init-tals=true|false]
	[--init-as0-tals=true|false]
	[--thread-pool.server.max=<unsigned integer>]

If an argument is specified more than once, the last one takes precedence:

$ fort --tal="foo"                          # tal is "foo"
$ fort --tal="foo" --tal="bar"              # tal is "bar"
$ fort --tal="foo" --tal="bar" --tal="qux"  # tal is "qux"

Arguments

`--help`

Type: None
Availability: argv only

Prints a medium-sized description of the command-line syntax, then exits.

$ fort --help
Usage: fort
	[--help]
		(Give this help list)
	[--usage]
		(Give a short usage message)
	[--version]
		(Print program version)
	...
	[--init-as0-tals=true|false]
		(Fetch the currently-known AS0 TAL files into --tal)
	[--thread-pool.server.max=<unsigned integer>]
		(Maximum number of active threads (one thread per RTR client) that can live at the thread pool)
	[--thread-pool.validation.max=<unsigned integer>]
		(Maximum number of active threads (one thread per TAL) that can live at the thread pool)

The slightly larger usage message is man fort and the large usage message is this documentation.

`--usage`

Type: None
Availability: argv only

Prints a small-sized syntax reminder message, then exits.

$ fort --usage
Usage: fort
        [--help]
        [--usage]
        [--version]
	...
        [--log.file-name-format=global-url|local-path|file-name]
        [--output.roa=<file>]
        [--output.bgpsec=<file>]

`--version`

Type: None
Availability: argv only

Prints the program’s version, then exits.

$ fort --version
fort 1.6.1

`--tal`

Type: String (Path to file or directory)
Availability: argv and JSON

Path to the Trust Anchor Locator (TAL), or to a directory that contains TALs.

A TAL is a file that points to a Trust Anchor (TA). A TA is an RPKI tree’s root certificate.

The reason why you provide locators instead of anchors is to allow the latter to be officially updated without the need to awkwardly redistribute them. (TALs rarely need to change.)

Registries which own TAs are responsible for providing you with their TALs. For convenience, you can use --init-tals and --init-as0-tals to speed up and automate this process. Alternatively, by following these links, you can download them manually:

The TAL file format has been standardized in RFC 8630. It is a text file that contains zero or more comments (each comment must start with the character “#” and end with a line break), a list of URLs (which serve as alternate access methods for the TA), followed by a blank line, followed by the Base64-encoded public key of the TA.

Just for completeness sake, here’s an example on what a typical TAL looks like:

https://rpki.example.com/repository/root-ca.cer
rsync://rpki.example.com/repository/root-ca.cer

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsqS+PDB1kArJlBTHeYCu
4anCWv8DzE8fHHexlGBm4TQBWC0IhNVbpUFg7SOp/7VddcGWyPZQRfdpQi4fdaGu
d6JJcGRECibaoc0Gs+d2mNyFJ1XXNppLMr5WH3iaL86r00jAnGJiCiNWzz7Rwyvy
UH0Z4lO12h+z0Zau7ekJ2Oz9to+VcWjHzV4y6gcK1MTlM6fMhKOzQxEA3TeDFgXo
SMiU+kLHI3dJhv4nJpjc0F+8+6hokIbF0p79yaCgyk0IGz7W3oSPa13KLN6mIPs6
4/UUJU5DDQvdq5T9FRF0I1mdtLToLSBnDCkTAAC6486UYV1j1Yzv1+DWJHSmiLna
LQIDAQAB

`--init-tals`

Type: None
Availability: argv only

Downloads the currently known core TALs into the --tal directory, then exits. It’s a convenience option, meant for quick TAL retrieval, in case you don’t have a more formal means to do it.

$ fort --init-tals --tal /etc/fort/tal
Jul 30 12:00:55 DBG: HTTP GET: https://rpki.afrinic.net/tal/afrinic.tal
Successfully fetched '/etc/fort/tal/afrinic.tal'!

Jul 30 12:00:57 DBG: HTTP GET: https://tal.apnic.net/apnic.tal
Successfully fetched '/etc/fort/tal/apnic.tal'!

Jul 30 12:01:04 DBG: HTTP GET: https://www.arin.net/resources/manage/rpki/arin.tal
Successfully fetched '/etc/fort/tal/arin.tal'!

Jul 30 12:01:05 DBG: HTTP GET: https://www.lacnic.net/innovaportal/file/4983/1/lacnic.tal
Successfully fetched '/etc/fort/tal/lacnic.tal'!

Jul 30 12:01:06 DBG: HTTP GET: https://tal.rpki.ripe.net/ripe-ncc.tal
Successfully fetched '/etc/fort/tal/ripe-ncc.tal'!

This flag can be used in conjunction with --init-as0-tals.

`--init-as0-tals`

Type: None
Availability: argv only

Download the currently known AS0 Trust Anchor Locators (AS0 TALs) into the --tal directory, then exit.

Here’s an example. The following command downloads the AS0 TALs into /etc/fort/tal (assuming it exists, and is a writable directory):

$ fort --init-as0-tals --tal /etc/fort/tal
Jul 30 12:02:51 DBG: HTTP GET: https://tal.apnic.net/apnic-as0.tal
Successfully fetched '/etc/fort/tal/apnic-as0.tal'!

Jul 30 12:02:52 DBG: HTTP GET: https://www.lacnic.net/innovaportal/file/4983/1/lacnic-as0.tal
Successfully fetched '/etc/fort/tal/lacnic-as0.tal'!

This flag can be used in conjunction with --init-tals.

`--local-repository`

Type: String (Path to directory)
Availability: argv and JSON
Default: /tmp/fort/repository

Path to the directory where Fort will store a local cache of the entire repository trees.

This cache is updated (based on the trees pointed by the TALs) during every validation cycle, and Fort’s entire validation process operates on it.

Assuming not much time has passed since the last time the repository was cached, updating the cache is most of the time much faster than downloading it from scratch. You’re therefore encouraged to keep it around.

`--work-offline`

Type: Boolean (true, false)
Availability: argv and JSON

Skip the repository cache update?

If true, Fort will disable all outgoing RRDP and RSYNC requests during the validation cycle. The validation results will be entirely based on the (possibly outdated) existing cache. (--local-repository)

Mostly intended for debugging. See --rsync.enabled and --http.enabled if you want to disable a specific protocol.

`--daemon`

Type: Boolean (true, false)
Availability: argv and JSON

Send process to the background?

All enabled logs will be sent to syslog; --log.output and --validation-log.output will be ignored.

`--maximum-certificate-depth`

Type: Integer
Availability: argv and JSON
Default: 32
Range: [5, UINT_MAX)

Maximum allowable RPKI tree height. Meant to protect Fort from iterating infinitely due to certificate chain loops.

Fort’s tree traversal is actually iterative (not recursive), so there should be no risk of stack overflow, regardless of this value.

`--mode`

Type: Enumeration (server, standalone)
Availability: argv and JSON
Default: server

In server mode, Fort runs endlessly, performing RPKI validation cycles repeatedly. In parallel, it also starts an RTR server that will perpetually serve the validation results to upcoming RTR clients. (Which are usually routers.)

In standalone mode, Fort simply performs one immediate RPKI validation, then exits. This mode is usually coupled with --output.roa.

`--server.address`

Type: String array
Availability: argv and JSON
Default: NULL

List of hostnames or numeric host addresses the RTR server will be bound to. Must resolve to (or be) bindable IP addresses. IPv4 and IPv6 are supported.

The address list must be comma-separated, and each address must have the following format: <address>[#<port>]. The port defaults to --server.port.

Here are some examples:

--server.address="localhost": Bind to ‘localhost’, port --server.port.
--server.address="localhost, ::1#8324": Same as above, and also bind to IPv6 address ‘::1’, port ‘8324’.
--server.address="localhost#8323, ::1#8324": Bind to ‘localhost’ at port ‘8323’, and to ‘::1’ port ‘8324’. --server.port is ignored.

If this field is omitted, the server will accept connections on any of the host’s network addresses.

`--server.port`

Type: String
Availability: argv and JSON
Default: "323"

TCP port or service the server address(es) will be bound to, if --server.address doesn’t override it.

This is a string because a service alias can be used as a valid value. The available aliases are commonly located at /etc/services. (See ‘$ man 5 services’.)

The default port is privileged. To improve security, either change or jail it. See Non root port binding.

`--server.backlog`

Type: Integer
Availability: argv and JSON
Default: SOMAXCONN
Range: [1, SOMAXCONN]

RTR server’s listen queue length. It is the second argument of listen():

The backlog argument provides a hint to the implementation which the implementation shall use to limit the number of outstanding connections in the socket’s listen queue. Implementations may impose a limit on backlog and silently reduce the specified value. Normally, a larger backlog argument value shall result in a larger or equal length of the listen queue. Implementations shall support values of backlog up to SOMAXCONN, defined in <sys/socket.h>.

See the corresponding manual page from your operating system (likely man 2 listen) for specific implementation details.

`--server.interval.validation`

Type: Integer
Availability: argv and JSON
Default: 3600
Range: [60, UINT_MAX]

Number of seconds Fort will sleep between validation cycles, when in server mode.

The timer starts counting every time a validation is finished, not every time it begins. The actual validation loop is, therefore, longer than this number.

“Validation cycle” includes the rsync update along with the validation operation. Because you are taxing the global repositories every time the validator performs a cache synchronization, it is recommended not to reduce the validation interval to the point you might be contributing to DoS’ing the global repository. The minimum value (60) was taken from the RRDP RFC, which means it’s not necessarily a good value for heavy rsyncs.

`--server.interval.refresh`

Type: Integer
Availability: argv and JSON
Default: 3600
Range: [1, 86400]

To synchronize their cache of RPKI prefix origin data and router keys, RTR clients (routers) poll Fort’s RTR Server at regular intervals.

--server.interval.refresh is the length of that interval (in seconds), as suggested by Fort, to the RTR clients. It is only employed if the peers manage to negociate usage of the RTRv1 protocol for the communication.

See RFC 8210, section 6.

`--server.interval.retry`

Type: Integer
Availability: argv and JSON
Default: 600
Range: [1, 7200]

To synchronize their cache of RPKI prefix origin data and router keys, RTR clients (routers) poll Fort’s RTR Server at regular intervals.

--server.interval.retry is the number of seconds a router should wait before retrying a failed synchronization. It is suggested to them by Fort, and only employed if the peers manage to negociate usage of the RTRv1 protocol for the communication.

See RFC 8210, section 6.

`--server.interval.expire`

Type: Integer
Availability: argv and JSON
Default: 7200
Range: [600, 172800]

To synchronize their cache of RPKI prefix origin data and router keys, RTR clients (routers) poll Fort’s RTR Server at regular intervals.

--server.interval.expire is the number of seconds a router should retain their data while unable to perform a successful synchronization with Fort. It is suggested to them by Fort, and only employed if the peers manage to negociate usage of the RTRv1 protocol for the communication.

See RFC 8210, section 6.

`--server.deltas.lifetime`

Type: Integer
Availability: argv and JSON
Default: 2
Range: [0, UINT_MAX]

When routers first connect to Fort, they request a snapshot of the validation results. (ROAs and Router Keys.) Because they need to keep their validated objects updated, and snapshots tend to be relatively large amounts of information, they request deltas afterwards over configurable intervals. (“Deltas” being the differences between snapshots.)

During each validation cycle, Fort generates a new snapshot, as well as the deltas needed to build the new snapshot from the previous one. These are all stored in RAM. --server.deltas.lifetime is the number of iterations a set of deltas will be kept before being deallocated. (Recall that every iteration lasts --server.interval.validation seconds, plus however long the validation takes.)

If a router lags behind, to the point Fort has already deleted the deltas it needs to update the router’s snapshot, Fort will have to fall back to fetch the entire latest snapshot instead.

`--slurm`

Type: String (path to file or directory)
Availability: argv and JSON
Default: NULL

SLURM file, or directory containing SLURM files. See SLURM.

`--log.enabled`

Type: Boolean (true, false)
Availability: argv and JSON
Default: true

Enable the operation logs?

See Logging.

`--log.level`

Type: Enumeration (error, warning, info, debug)
Availability: argv and JSON
Default: warning

Minimum allowed severity of operation log messages. (Lower severity messages will be dropped.) The highest priority is error, and the lowest is debug.

For example, --log.level=warning will cause only warning and error messages to be logged.

See Logging > Configuration > Level.

`--log.output`

Type: Enumeration (syslog, console)
Availability: argv and JSON
Default: console

Desired target that will take care of actually printing the operation logs.

console will log messages in the standard streams; syslog will log on Syslog.

See Logging > Configuration > Output.

`--log.color-output`

Type: Boolean (true, false)
Availability: argv and JSON
Default: false

Include ANSI color codes in the logging? Meant to ease human consumption. Only applies when --log.output is console.

See Logging > Configuration > Color output.

`--log.file-name-format`

Type: Enumeration (global-url, local-path, file-name)
Availability: argv and JSON
Default: global-url

Decides which version of file names should be printed during most debug/error messages at the operation logs.

See Logging > Configuration > File name format.

`--log.facility`

Type: Enumeration (auth, authpriv, cron, daemon, ftp, lpr, mail, news, user, uucp, from local0 to local7)
Availability: argv and JSON
Default: daemon

Syslog facility utilized for operation logs (meaningful only if --log.output is syslog).

See Logging > Configuration > Facility.

`--log.tag`

Type: String
Availability: argv and JSON
Default: NULL

Prefix tag that will be added to all operation log messages. It’s meant to help identify operation logs from other types of logs.

The tag will be surrounded by square brackets.

See Logging > Configuration > Tag.

`--validation-log.enabled`

Type: Boolean (true, false)
Availability: argv and JSON
Default: false

Enable the validation logs?

See Logging.

`--validation-log.level`

Type: Enumeration (error, warning, info, debug)
Availability: argv and JSON
Default: warning

Minimum allowed severity of validation log messages. (Lower severity messages will be dropped.) The highest priority is error, and the lowest is debug.

For example, --validation-log.level=warning will cause only warning and error messages to be logged.

See Logging > Configuration > Level.

`--validation-log.output`

Type: Enumeration (syslog, console)
Availability: argv and JSON
Default: console

Desired target that will take care of actually printing the validation logs.

console will log messages in the standard streams; syslog will log on Syslog.

See Logging > Configuration > Output.

`--validation-log.color-output`

Type: Boolean (true, false)
Availability: argv and JSON
Default: false

Include ANSI color codes in the logging? Meant to ease human consumption. Only applies when --validation-log.output is console.

See Logging > Configuration > Color output.

`--validation-log.file-name-format`

Type: Enumeration (global-url, local-path, file-name)
Availability: argv and JSON
Default: global-url

Decides which version of file names should be printed during most debug/error messages at the validation logs.

See Logging > Configuration > File name format.

`--validation-log.facility`

Type: Enumeration (auth, authpriv, cron, daemon, ftp, lpr, mail, news, user, uucp, from local0 to local7)
Availability: argv and JSON
Default: daemon

Syslog facility utilized for validation logs (meaningful only if --validation-log.output is syslog).

See Logging > Configuration > Facility.

`--validation-log.tag`

Type: String
Availability: argv and JSON
Default: Validation

Prefix tag that will be added to all operation log messages. It’s meant to help identify operation logs from other types of logs.

The tag will be surrounded by square brackets.

See Logging > Configuration > Tag.

`--http.enabled`

Type: Boolean (true, false)
Availability: argv and JSON
Default: true

Enable HTTP requests during validation?

If disabled (--http.enabled=false), Fort will skip all outgoing HTTP requests during the validation cycle. The relevant validation results will be entirely based on the (possibly outdated) existing cache. (--local-repository)

Mostly intended for debugging.

`--http.priority`

Type: Integer
Availability: argv and JSON
Default: 60
Range: [0, 100]

HTTP’s (and therefore RRDP’s) precedence when choosing the protocol used to download files (assuming Fort has to choose, and both protocols are enabled). The protocol with the highest priority is used first, and the runner-up is employed as fallback.

At the moment, only two protocols (RRDP/HTTP and RSYNC) are supported. Yes, --http.priority’s range is overkill.

See --rsync.priority.

`--http.retry.count`

Type: Integer
Availability: argv and JSON
Default: 0
Range: [0, UINT_MAX]

Number of additional HTTP requests after a failed attempt.

If a transient error is returned when Fort tries to perform an HTTP transfer, it will retry this number of times before giving up. Setting the number to 0 makes Fort do no retries (which is the default). “Transient error” is a timeout, an HTTP 408 response code, or an HTTP 5xx response code.

`--http.retry.interval`

Type: Integer
Availability: argv and JSON
Default: 5
Range: [0, UINT_MAX]

Period of time (in seconds) to wait between each retry to request an HTTP URI.

`--http.user-agent`

Type: String
Availability: argv and JSON
Default: fort/1.6.1

All requests are made using HTTPS, verifying the peer and the certificate name vs host

User-Agent to use at HTTP requests.

The value specified (either by the argument or the default value) is utilized in libcurl’s option CURLOPT_USERAGENT.

`--http.max-redirs`

Type: Integer
Availability: argv and JSON
Default: 10
Range: [0, UINT_MAX]

Maximum allowed number of redirections to follow per HTTP request. (The total number of requests is --http.max-redirs + 1.)

Unlike curl’s --max-redirs, Fort does not provide a means to allow for infinite redirects.

`--http.connect-timeout`

Type: Integer
Availability: argv and JSON
Default: 30
Range: [1, UINT_MAX]

All requests are made using HTTPS, verifying the peer and the certificate name vs host

Timeout (in seconds) for the connect phase.

Whenever an HTTP connection will try to be established, the validator will wait a maximum of http.connect-timeout for the peer to respond to the connection request; if the timeout is reached, the connection attempt will be aborted.

The value specified (either by the argument or the default value) is utilized in libcurl’s option CURLOPT_CONNECTTIMEOUT.

`--http.transfer-timeout`

Type: Integer
Availability: argv and JSON
Default: 0
Range: [0, UINT_MAX]

All requests are made using HTTPS, verifying the peer and the certificate name vs host

Maximum time in seconds (once the connection is established) that the request can last.

Once the connection is established with the server, the request will last a maximum of http.transfer-timeout seconds. A value of 0 means unlimited time.

The value specified (either by the argument or the default value) is utilized in libcurl’s option CURLOPT_TIMEOUT.

`--http.low-speed-limit`

Type: Integer
Availability: argv and JSON
Default: 100000 (100 kilobytes/second)
Range: [0, UINT_MAX]

The value Fort employs as CURLOPT_LOW_SPEED_LIMIT during every HTTP transfer.

It is the average transfer speed (in bytes per second) that HTTP transfers (between Fort and RPKI repositories) should be below during --http.low-speed-time seconds for Fort to consider it to be too slow. (Slow connections are dropped.)

For example:

--http.low-speed-limit 30 --http.low-speed-time 60

Whenever Fort attempts to retrieve a file from an RPKI repository through HTTP, it will abort the transfer if the connection stays slower than 30 bytes per second, over a period of 60 seconds.

The intent is to prevent malicious repositories from slowing down Fort.

Zero disables the validation.

`--http.low-speed-time`

Type: Integer
Availability: argv and JSON
Default: 10
Range: [0, UINT_MAX]

The value Fort employs as CURLOPT_LOW_SPEED_TIME during every HTTP transfer.

It is the number of seconds that the transfer speed should be below --http.low-speed-limit for the Fort to consider it too slow. (Slow connections are dropped.)

See --http.low-speed-limit for an example.

`--http.max-file-size`

Type: Integer
Availability: argv and JSON
Default: 1,000,000,000 (1 Gigabyte)
Range: [0, 2000000000] (2 Gigabytes)

The maximum amount of bytes files are allowed to length during HTTP transfers. Files that exceed this limit are dropped, either early (through CURLOPT_MAXFILESIZE) or as they hit the limit (when the file size is not known prior to download).

This is intended to prevent malicious RPKI repositories from stagnating Fort.

As of 2021-10-05, the largest legitimate file in the repositories is an RRDP snapshot that weights ~150 megabytes. (But will double in size during key rollover.)

This configuration value is transient. It is expected that the IETF will eventually standardize a more versatile means to prevent unbounded file transfers. In particular, because RRDP snapshots tend to grow over time, --http.max-file-size’s default value will likely eventually be exceeded by legitimate files.

Watch out for the following warning in the operation logs:

File size exceeds 50% of the configured limit

`--http.ca-path`

Type: String (Path to directory)
Availability: argv and JSON

All requests are made using HTTPS, verifying the peer and the certificate name vs host

Path to a directory containing CA certificates, which Fort might employ to verify peers while performing HTTPS requests.

Useful when the CA from the peer isn’t located at the default OS certificate bundle. If specified, the peer certificate will be verified using the CAs at the path. The directory MUST be prepared using the rehash utility from the SSL library:

OpenSSL command (with help): $ openssl rehash -h
LibreSSL command (with help): $ openssl certhash -h

The value specified is utilized in libcurl’s option CURLOPT_CAPATH.

`--output.roa`

Type: String (Path to file)
Availability: argv and JSON

File where the ROAs (found during each validation run) will be stored. See --output.format.

If the file already exists, it will be overwritten. If it doesn’t exist, it will be created. To print to standard output, use a hyphen (-). If the RTR server is enabled, then the ROAs will be printed every --server.interval.validation secs.

When --output.format equals csv, each line of the result is printed in the following order: AS, Prefix, Max prefix length. The first line contains the column names.

When --output.format equals json, each element is printed in an object array of roas:

{
	"roas": [
		{
			"asn": "AS64496",
			"prefix": "198.51.100.0/24",
			"maxLength": 24
		},
		{
			"asn": "AS64496",
			"prefix": "2001:DB8::/32",
			"maxLength": 48
		}
	]
}

If --output.roa is omitted, the ROAs are not printed.

`--output.bgpsec`

Type: String (Path to file)
Availability: argv and JSON

BGPsec certificate validation has been disabled in version 1.5.2 because of this bug.

File where the BGPsec Router Keys (found during each validation run) will be stored. See --output.format.

Since most of the data (Subject Key Identifier and Subject Public Key Info) is binary, it is base64url-encoded, without trailing pads.

If the file already exists, it will be overwritten. If it doesn’t exist, it will be created. To print to standard output, use a hyphen (-). If the RTR server is enabled, the BGPsec Router Keys will be printed every --server.interval.validation seconds.

When --output.format equals csv, each line of the result is printed in the following order: AS, Subject Key Identifier, Subject Public Key Info. The first line contains the column names.

When --output.format equals json, each element is printed in an object array of router-keys:

{
	"router-keys": [
		{
			"asn": "AS64496",
			"ski": "<Base64 Encoded SKI>",
			"spki": "<Base64 Encoded SPKI>"
		},
		{
			"asn": "AS64497",
			"ski": "<Base64 Encoded SKI>",
			"spki": "<Base64 Encoded SPKI>"
		}
	]
}

If --output.bgpsec is ommited, then the BGPsec Router Keys are not printed.

`--output.format`

Type: Enumeration (csv, json)
Availability: argv and JSON
Default: csv

Output format for --output.roa and --output.bgpsec.

`--asn1-decode-max-stack`

Type: Integer
Availability: argv and JSON
Default: 4096
Range: [1, UINT_MAX]

ASN1 decoder max allowed stack size in bytes, utilized to avoid a stack overflow when a large nested ASN1 object is parsed.

This check is merely a caution, since ASN1 decoding functions are recursive and might cause a stack overflow. So, this argument probably won’t be necessary in most cases, since the RPKI ASN1 objects don’t have nested objects that require too much stack allocation (for now).

`--thread-pool.server.max`

Type: Integer
Availability: argv and JSON
Default: 20
Range: [1, UINT_MAX]

Number of threads the RTR server will reserve for RTR client (router) request handling. The server will be able to handle --thread-pool.server.max requests at most, at once. Additional requests will queue.

Before Fort 1.5.1, this value used to represent the maximum number of client connections the server would be able to hold at any given time. It scales better now.

`--rsync.enabled`

Type: Boolean (true, false)
Availability: argv and JSON
Default: true

Enables RSYNC requests during validation?

If disabled (--rsync.enabled=false), Fort will skip all outgoing RSYNC requests during the validation cycle. The relevant validation results will be entirely based on the (possibly outdated) existing cache. (--local-repository)

Mostly intended for debugging.

`--rsync.priority`

Type: Integer
Availability: argv and JSON
Default: 50
Range: [0, 100]

RSYNC’s precedence when choosing the protocol used to download files (assuming Fort has to choose, and both protocols are enabled). The protocol with the highest priority is used first, and the runner-up is employed as fallback.

At the moment, only two protocols (RRDP/HTTP and RSYNC) are supported. Yes, --rsync.priority’s range is overkill.

See --http.priority.

`--rsync.retry.count`

Type: Integer
Availability: argv and JSON
Default: 0
Range: [0, UINT_MAX]

Maximum number of retries whenever there’s an error executing an RSYNC.

A value of 0 means no retries.

Whenever is necessary to execute an RSYNC, the validator will try at least one time the execution. If there was an error executing the RSYNC, the validator will retry it at most --rsync.retry.count times, waiting --rsync.retry.interval seconds between each retry.

`--rsync.retry.interval`

Type: Integer
Availability: argv and JSON
Default: 5
Range: [0, UINT_MAX]

Period of time (in seconds) to wait between each retry to execute an RSYNC.

`--configuration-file`

Type: String (Path to file)
Availability: argv only

Path to a JSON file from which additional configuration will be read.

The configuration options are mostly the same as the ones from the argv interface. (See the “Availability” metadata of each field.) Here’s a (possibly slightly outdated) full configuration file example:

{
	"tal": "/tmp/fort/tal/",
	"local-repository": "/tmp/fort/repository",
	"work-offline": false,
	"maximum-certificate-depth": 32,
	"mode": "server",
	"daemon": false,
	"slurm": "/tmp/fort/test.slurm",
	"asn1-decode-max-stack": 4096,

	"server": {
		"address": [
			"192.0.2.1",
			"2001:db8::1"
		],
		"port": "8323",
		"backlog": 4096,
		"interval": {
			"validation": 3600,
			"refresh": 3600,
			"retry": 600,
			"expire": 7200
		},
		"deltas": {
			"lifetime": 2
		}
	},

	"log": {
		"enabled": true,
		"output": "console",
		"level": "info",
		"tag": "Operation",
		"facility": "daemon",
		"file-name-format": "global-url",
		"color-output": false
	},

	"validation-log": {
		"enabled": false,
		"output": "console",
		"level": "warning",
		"tag": "Validation",
		"facility": "daemon",
		"file-name-format": "global-url",
		"color-output": false
	},

	"http": {
		"enabled": true,
		"priority": 60,
		"retry": {
			"count": 1,
			"interval": 4
		},
		"user-agent": "fort/1.6.1",
		"max-redirs": 10,
		"connect-timeout": 30,
		"transfer-timeout": 0,
		"low-speed-limit": 100000,
		"low-speed-time": 10,
		"max-file-size": 1000000000,
		"ca-path": "/usr/local/ssl/certs"
	},

	"rsync": {
		"enabled": true,
		"priority": 50,
		"retry": {
			"count": 1,
			"interval": 4
		},
		"program": "rsync",
		"arguments-recursive": [
			"-rtz",
			"--delete",
			"--omit-dir-times",
			"--contimeout=20",
			"--max-size=20MB",
			"--timeout=15",
			"--include=*/",
			"--include=*.cer",
			"--include=*.crl",
			"--include=*.gbr",
			"--include=*.mft",
			"--include=*.roa",
			"--exclude=*",
			"$REMOTE",
			"$LOCAL"
		]
	},

	"incidences": [
		{
			"name": "incid-hashalg-has-params",
			"action": "ignore"
		},
		{
			"name": "incid-obj-not-der-encoded",
			"action": "ignore"
		},
		{
			"name": "incid-file-at-mft-not-found",
			"action": "error"
		},
		{
			"name": "incid-file-at-mft-hash-not-match",
			"action": "error"
		},
		{
			"name": "incid-mft-stale",
			"action": "error"
		},
		{
			"name": "incid-crl-stale",
			"action": "error"
		}
	],

	"output": {
		"roa": "/tmp/fort/roas.csv",
		"bgpsec": "/tmp/fort/bgpsec.csv",
		"format": "csv"
	},

	"thread-pool": {
		"server": {
			"max": 20
		}
	}
}

The file acts as a collection of equivalent argv arguments; precedence is not modified:

$ cat cfg.json
{
	"tal": "bar"
}

$ fort --tal="foo"                                              # tal is "foo"
$ fort --tal="foo" --configuration-file="cfg.json"              # tal is "bar"
$ fort --tal="foo" --configuration-file="cfg.json" --tal="qux"  # tal is "qux"

$ cat a.json
{
	"local-repository": "a",
	"rsync.strategy": "root",
	"maximum-certificate-depth": 5
}

$ cat b.json
{
	"rsync.strategy": "strict"
	"maximum-certificate-depth": 6
}

$ cat c.json
{
	"maximum-certificate-depth": 8
}

$ fort \
	--configuration-file="a.json" \
	--configuration-file="b.json" \
	--configuration-file="c.json"
$ # local-repository is "a", rsync.strategy is "strict" and maximum-certificate-depth is 8

`rsync.program`

Type: String
Availability: JSON only
Default: "rsync"

Name of the program needed to invoke an rsync file transfer.

`rsync.arguments-recursive`

Type: String array
Availability: JSON only
Default: [ "-rtz", "--delete", "--omit-dir-times", "--contimeout=20", "--max-size=20MB", "--timeout=15", "--include=*/", "--include=*.cer", "--include=*.crl", "--include=*.gbr", "--include=*.mft", "--include=*.roa", "--exclude=*", "$REMOTE", "$LOCAL" ]

Arguments needed by rsync.program to perform a recursive rsync.

Fort will replace "$REMOTE" with the remote URL it needs to download, and "$LOCAL" with the target local directory where the file is supposed to be dropped.

`incidences`

Type: JSON Object array
Availability: JSON only

A listing of actions to be performed by validation upon encountering certain error conditions. See Incidences.