Program Arguments

Index

  1. Syntax
  2. Arguments
    1. --help
    2. --usage
    3. --version
    4. --tal
    5. --init-tals
    6. --init-as0-tals
    7. --local-repository
    8. --work-offline
    9. --daemon
    10. --shuffle-uris
    11. --maximum-certificate-depth
    12. --mode
    13. --server.address
    14. --server.port
    15. --server.backlog
    16. --server.interval.validation
    17. --server.interval.refresh
    18. --server.interval.retry
    19. --server.interval.expire
    20. --server.deltas.lifetime
    21. --slurm
    22. --log.enabled
    23. --log.level
    24. --log.output
    25. --log.color-output
    26. --log.file-name-format
    27. --log.facility
    28. --log.tag
    29. --validation-log.enabled
    30. --validation-log.level
    31. --validation-log.output
    32. --validation-log.color-output
    33. --validation-log.file-name-format
    34. --validation-log.facility
    35. --validation-log.tag
    36. --http.enabled
    37. --http.priority
    38. --http.retry.count
    39. --http.retry.interval
    40. --http.user-agent
    41. --http.connect-timeout
    42. --http.transfer-timeout
    43. --http.idle-timeout
    44. --http.ca-path
    45. --output.roa
    46. --output.bgpsec
    47. --output.format
    48. --asn1-decode-max-stack
    49. --stale-repository-period
    50. --thread-pool.server.max
    51. --thread-pool.validation.max
    52. --rsync.enabled
    53. --rsync.priority
    54. --rsync.strategy
      1. strict
      2. root
      3. root-except-ta
    55. --rsync.retry.count
    56. --rsync.retry.interval
    57. --configuration-file
    58. rsync.program
    59. rsync.arguments-recursive
    60. rsync.arguments-flat
    61. incidences
  3. Deprecated arguments
    1. --sync-strategy
    2. --rrdp.enabled
    3. --rrdp.priority
    4. --rrdp.retry.count
    5. --rrdp.retry.interval
    6. init-locations

Syntax

fort
	[--help]
	[--usage]
	[--version]
	[--configuration-file=<file>]
	[--tal=<file>|<directory>]
	[--local-repository=<directory>]
	[--sync-strategy=off|root|root-except-ta]
	[--shuffle-uris=true|false]
	[--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=<32-bit unsigned integer>]
	[--rsync.strategy=root|root-except-ta]
	[--rsync.retry.count=<unsigned integer>]
	[--rsync.retry.interval=<unsigned integer>]
	[--rrdp.enabled=true|false]
	[--rrdp.priority=<32-bit unsigned integer>]
	[--rrdp.retry.count=<unsigned integer>]
	[--rrdp.retry.interval=<unsigned integer>]
	[--http.enabled=true|false]
	[--http.priority=<32-bit unsigned integer>]
	[--http.retry.count=<unsigned integer>]
	[--http.retry.interval=<unsigned integer>]
	[--http.user-agent=<string>]
	[--http.connect-timeout=<unsigned integer>]
	[--http.transfer-timeout=<unsigned integer>]
	[--http.idle-timeout=<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>]
	[--stale-repository-period=<unsigned integer>]
	[--init-tals=true|false]
	[--init-as0-tals=true|false]
	[--thread-pool.server.max=<unsigned integer>]
	[--thread-pool.validation.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.5.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 mostly automate this process. Alternatively, you can download the TALs manually. As of 2021-05-26, they can be found by following these links:

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.

ARIN’s TAL requires that you accept their Relying Party Agreement before the file can be downloaded. This is done through the standard streams.

$ 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'!

Attention: ARIN requires you to agree to their Relying Party Agreement (RPA) before you can download and use their TAL.
Please download and read https://www.arin.net/resources/manage/rpki/rpa.pdf
If you agree to the terms, type 'yes' and hit Enter: yes
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.

--shuffle-uris

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

Access the URLs from the TALs in random order? (This is meant for load balancing.) Otherwise, Fort will try to access them in sequential order. (Which makes more sense when the URLs are ordered by priority.)

Fort only needs one TA for a successful traversal. As soon as one functioning URL is found, the others are ignored until the next validation cycle.

This sorting mechanism is secondary to the protocol sorting mechanism. URLs are first sorted according to their protocol’s priorities (--rsync.priority, --http.priority), then according to --shuffle-uris.

--maximum-certificate-depth

  • Type: Integer
  • Availability: argv and JSON
  • Default: 32
  • Range: 5–(UINT_MAX–1)

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’.)

img/warn.svg 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: 2
  • Range: 0–UINT_MAX

Maximum number of retries whenever there’s an error requesting an HTTP URI.

A value of 0 means no retries.

Whenever is necessary to request an HTTP URI, the validator will try the request at least once. If there was an error requesting the URI, the validator will retry at most --http.retry.count times to fetch the file, waiting --http.retry.interval seconds between each retry.

--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.5.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.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 ceased.

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.idle-timeout

  • Type: Integer
  • Availability: argv and JSON
  • Default: 15
  • 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 a request can be idle before dropping it.

Once the connection is established with the server, the request can last a maximum of http.idle-timeout seconds without receiving data before dropping the connection. A value of 0 disables idle time verification (use with caution).

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

--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

Note: The paragraphs below apply to Fort 1.5.0.

File where the ROAs (found during each validation run) will be stored (in CSV 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 seconds.

Each line of the result is printed in the following order: AS, Prefix, Max prefix length. The first line contains the column names.

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

Note: The paragraphs below apply to Fort master.

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

Note: The paragraphs below apply to Fort 1.5.0.

File where the BGPsec Router Keys (found during each validation run) will be stored (in CSV 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 console, use a hyphen (-). If the RTR server is enabled, the BGPsec Router Keys will be printed every --server.interval.validation seconds.

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.

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

Note: The paragraphs below apply to Fort master.

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

Note: This flag only exists in Fort master.

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).

--stale-repository-period

  • Type: Integer
  • Availability: argv and JSON
  • Default: 43200 (12 hours)
  • Range: 0–UINT_MAX

Time period that must lapse to warn about a stale repository (the messages will be sent to the operation log). The time lapse starts once the repository download has been retried (see --rsync.retry.count and --http.retry.count) and failed after such retries.

A repository is considered stale if its files can’t be fetched due to a communication error, and this error persists across validation cycles. This kind of issue can be due to a local misconfiguration (eg. a firewall that blocks incoming data) or a problem at the server (eg. the server is down).

During the downtime, Fort will try to work with the local cache. (--local-repository)

The communication errors sent to the operation log, are those related to “first level” RPKI servers; commonly this are the servers maintained by the RIRs.

Currently all the communication errors are logged in the validation log. --stale-repository-period is only used to also send them to the operation log.

A value equal to 0 means that the communication errors will be logged immediately.

--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.

--thread-pool.validation.max

  • Type: Integer
  • Availability: argv and JSON
  • Default: 5
  • Range: 1–100

Warning! Deprecated. This value should always equal the number of TALs you have, and will therefore be automated and retired in the future.

Number of threads in the validation thread pool.

During every validation cycle, one thread is borrowed from this pool per TAL, to validate the RPKI tree of the corresponding TAL.

--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.strategy

  • Type: Enumeration (strict, root, root-except-ta)
  • Availability: argv and JSON
  • Default: root-except-ta

rsync synchronization strategy. Commands the way rsync URLs are approached during downloads.

strict

In order to enable this strategy, recompile using the flag: ENABLE_STRICT_STRATEGY.

e.g. $ make FORT_FLAGS='-DENABLE_STRICT_STRATEGY'

rsyncs every repository publication point separately. Only skips publication points that have already been downloaded during the current validation cycle. (Assuming each synchronization is recursive.)

For example, suppose the validator gets certificates whose caRepository access methods (in their Subject Information Access extensions) point to the following publication points:

  1. rsync://rpki.example.com/foo/bar/
  2. rsync://rpki.example.com/foo/qux/
  3. rsync://rpki.example.com/foo/bar/
  4. rsync://rpki.example.com/foo/corge/grault/
  5. rsync://rpki.example.com/foo/corge/
  6. rsync://rpki.example.com/foo/corge/waldo/

A validator following the strict strategy would download bar, download qux, skip bar, download corge/grault, download corge and skip corge/waldo.

Though this strategy is the only “strictly” correct one, it is also extremely slow. Its usage is not recommended, unless your repository contains lots of spam files, awkward permissions or can’t be found in a repository rooted in a URL that follows the regular expression “rsync://.+/.+/”.

root

For each publication point found, guess the root of its repository and rsync that instead. Then skip any subsequent children of said root.

(To guess the root of a repository, the validator counts four slashes, and prunes the rest of the URL.)

Reusing the caRepository URLs from the strict strategy (above) as example, a validator following the root strategy would download rsync://rpki.example.com/foo, and then skip everything else.

Assuming that the repository is specifically structured to be found within as few roots as possible, and they contain minimal RPKI-unrelated noise files, this is the fastest synchronization strategy. At time of writing, this is true for all the current official repositories.

root-except-ta

Synchronizes the root certificate (the one pointed by the TAL) in strict mode, and once it’s validated, synchronizes the rest of the repository in root mode.

Useful if you want root, but the root certificate is separated from the rest of the repository. Also useful if you don’t want the validator to download the entire repository without first confirming the integrity and legitimacy of the root certificate.

--rsync.retry.count

  • Type: Integer
  • Availability: argv and JSON
  • Default: 2
  • 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,
	"shuffle-uris": true,
	"maximum-certificate-depth": 32,
	"mode": "server",
	"daemon": false,
	"slurm": "/tmp/fort/test.slurm",

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

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

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

	"http": {
		"enabled": true,
		"priority": 60,
		"retry": {
			"count": 2,
			"interval": 5
		},
		"user-agent": "fort/1.5.1",
		"connect-timeout": 30,
		"transfer-timeout": 0,
		"idle-timeout": 15,
		"ca-path": "/usr/local/ssl/certs"
	},

	"rsync": {
		"enabled": true,
		"priority": 50,
		"strategy": "root-except-ta",
		"retry": {
			"count": 2,
			"interval": 5
		},
		"program": "rsync",
		"arguments-recursive": [
			"--recursive",
			"--delete",
			"--times",
			"--contimeout=20",
			"--timeout=15",
			"$REMOTE",
			"$LOCAL"
		],
		"arguments-flat": [
			"--times",
			"--contimeout=20",
			"--timeout=15",
			"--dirs",
			"$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
		},
		"validation": {
			"max": 5
		}
	},

	"asn1-decode-max-stack": 4096,
	"stale-repository-period": 43200
}

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: [ "--recursive", "--delete", "--times", "--contimeout=20", "--timeout=15", "$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.

rsync.arguments-flat

  • Type: String array
  • Availability: JSON only
  • Default: [ "--times", "--contimeout=20", "--timeout=15", "--dirs", "$REMOTE", "$LOCAL" ]

Arguments needed by rsync.program to perform a single-file 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.

Deprecated arguments

--sync-strategy

  • Type: Enumeration (off, strict, root, root-except-ta)
  • Availability: argv and JSON
  • Default: root-except-ta

img/warn.svg This argument will be DEPRECATED. Use --rsync.strategy or --rsync.enabled (if rsync is meant to be disabled) instead.

rsync synchronization strategy. Commands the way rsync URLs are approached during downloads.

Despite this argument will be deprecated, it still can be utilized. Its possible values and behaviour will be as listed here:

  • off: will disable rsync execution, setting --rsync.enabled as false. So, using --sync-strategy=off will be the same as --rsync.enabled=false.
  • strict: will be the same as --rsync.strategy=strict, see strict.
  • root: will be the same as --rsync.strategy=root, see root.
  • root-except-ta: will be the same as --rsync.strategy=root-except-ta, see root-except-ta.

--rrdp.enabled

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

img/warn.svg This argument is DEPRECATED. Use --http.enabled instead.

--rrdp.priority

  • Type: Integer
  • Availability: argv and JSON
  • Default: 60
  • Range: 0–100

img/warn.svg This argument is DEPRECATED. Use --http.priority instead.

--rrdp.retry.count

  • Type: Integer
  • Availability: argv and JSON
  • Default: 2
  • Range: 0–UINT_MAX

img/warn.svg This argument is DEPRECATED. Use --http.retry.count instead.

--rrdp.retry.interval

  • Type: Integer
  • Availability: argv and JSON
  • Default: 5
  • Range: 0–UINT_MAX

img/warn.svg This argument is DEPRECATED. Use --http.retry.interval instead.

init-locations

  • Type: JSON Object array
  • Availability: JSON only

img/warn.svg This argument is deprecated. I don’t know why it exists; just do normal wgets or curls instead. As of Fort 1.5.1, it does nothing. The documentation below applies to 1.5.0 and below.

List of URLs from where the TALs will be fetched when --init-tals is utilized. Each URL can have an optional accept-message that will be displayed at the terminal. When this message is displayed, the word “yes” is expected by FORT to download the corresponding TAL file; this way an explicit acceptance is obtained to comply with the printed message.

By default it has 4 URLs from each TAL that doesn’t require and explicit politics acceptance by the user, and 1 URL that does have an acceptance message so that FORT can proceed with its download.

This is a JSON array of objects, where each object has a mandatory url member, and an optional accept-message member. The default value is:

"init-locations": [
	{
		"url": "https://www.arin.net/resources/manage/rpki/arin.tal",
		"accept-message": "Please download and read ARIN Relying Party Agreement (RPA) from https://www.arin.net/resources/manage/rpki/rpa.pdf. Once you've read it and if you agree ARIN RPA, type 'yes' to proceed with ARIN's TAL download:"
	},
	{
		"url": "https://raw.githubusercontent.com/NICMx/FORT-validator/master/examples/tal/lacnic.tal"
	},
	{
		"url": "https://raw.githubusercontent.com/NICMx/FORT-validator/master/examples/tal/ripe.tal"
	},
	{
		"url": "https://raw.githubusercontent.com/NICMx/FORT-validator/master/examples/tal/afrinic.tal"
	},
	{
		"url": "https://raw.githubusercontent.com/NICMx/FORT-validator/master/examples/tal/apnic.tal"
	}
]