Provided by: fort-validator_1.5.4-1_amd64 bug

NAME

       fort - RPKI validator and RTR server

SYNOPSIS

       fort [--mode=server] [OPTIONS]

       fort --mode=standalone [OPTIONS]

       fort --init-tals --tal=PATH

       fort [-h|--help|--V|--version|--usage]

DESCRIPTION

       Fort  is  an  RPKI  "Relying  Party"  (RP).  It's  an artifact that validates Route Origin
       Attestations (ROAs) and BGPsec Router Keys, by way of a Public Key  Infrastructure  (PKI).
       ROAs are employed by routers, to verify BGP routing attestations.

       The  main  validation input is one or more Trust Anchor Locator (TAL) files (--tal), which
       point to the RPKI Trust Anchors (ie. root certificates).  Fort downloads all the resources
       governed  by  the  trust  anchors into a local cache (--local-repository), and proceeds to
       validate their entirety. The output of the validation is a set of trusted ROAs and  Router
       Keys,  which  are  printed  to  files  (--output.roa and --output.bgpsec) and/or served to
       routers (--mode=server, --server.address, --server.port) through the RTR protocol (version
       0 or 1).

OPTIONS

       -h, --help
           Print long usage message and exit.

       --usage
           Print short usage message and exit.

       -V, --version
           Print program version and exit.

       --init-tals
           Download  the  currently known core TALs into the existent local directory --tal, then
           exit.

           The "currently known core TALs" are

           https://rpki.afrinic.net/tal/afrinic.tal
           https://tal.apnic.net/apnic.tal
           https://www.arin.net/resources/manage/rpki/arin.tal
           https://www.lacnic.net/innovaportal/file/4983/1/lacnic.tal
           https://tal.rpki.ripe.net/ripe-ncc.tal

           Please note that ARIN requires that you accept a Relying Party  Agreement  before  you
           can download their TAL: https://www.arin.net/resources/manage/rpki/rpa.pdf

       --init-as0-tals
           Download  the  currently  known AS0 TALs into the existent local directory --tal, then
           exit.

           The "currently known AS0 TALs" are

           https://tal.apnic.net/apnic-as0.tal
           https://www.lacnic.net/innovaportal/file/4983/1/lacnic-as0.tal

       -f, --configuration-file=FILE
           Path to a JSON file from where additional configuration will be read.

           The configuration options are mostly the same as the ones presented  in  this  manual.
           Each  property is mapped as a member of the main JSON object, the members that contain
           a dot '.' must be set  as  objects  (eg.   "--server.port=8323"  will  be  set  as  "{
           "server": { "port": "8323" } }".

           An example configuration file can be seen in this manual at the EXAMPLES section.

           Some  configuration  options  can't  be set at the JSON configuration file: --version,
           --help, --version, and --configuration-file.

           Other configuration options can be configured exclusively at  the  JSON  configuration
           file:

           rsync.program
               Name  of the program needed to invoke an rsync file transfer. The default value is
               "rsync".

           rsync.arguments-recursive
               Arguments needed by rsync.program to perform a recursive rsync. The arguments  are
               specified  as  a  JSON  string  array;  its  default  value  is:  [ "--recursive",
               "--delete", "--times", "--contimeout=20", "--timeout=15", "$REMOTE", "$LOCAL" ]

               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.

               If  rsync.program  set  is rsync (default value), see more about its arguments and
               behavior at rsync(1).

           rsync.arguments-flat
               Arguments needed by rsync.program to perform a single-file  rsync.  The  arguments
               are  specified  as  a  JSON  string  array;  its  default  value  is: [ "--times",
               "--contimeout=20", "--timeout=15", "--dirs", "$REMOTE", "$LOCAL" ]

               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.

               If  rsync.program  set  is rsync (default value), see more about its arguments and
               behavior at rsync(1).

           incidences
               A listing of actions to be  performed  by  validation  upon  encountering  certain
               common  error  conditions. This configuration is a means to modify FORTs validator
               behavior upon encountering profile violations that,  from  experience,  are  often
               overlooked.

               The  incidences  are  configured inside the member "incidences" as a JSON array of
               objects, each with two members "name" and "action", eg:

               "incidences": [
                 {
                   "name": "incid-hashalg-has-params",
                   "action": "warn"
                 }, {
                   "name": "incid-obj-not-der-encoded",
                   "action": "error"
                 }
               ]

               An incidence contains a name and an action.  The  name  is  merely  an  identifier
               defined  by  FORT  that  states a particular error condition, and the action is an
               enumeration that states the outcome of a violation of the corresponding incidence.

               The action can have one of three values:
                   error: Print error  message  in  error  log  level,  fail  validation  of  the
                   offending object (and all of its children).
                   warn:  Print  error  message  in  warning log level, continue validation as if
                   nothing happened.
                   ignore: Do  not  print  error  message,  continue  validation  as  if  nothing
                   happened.

               Currently  these  are  the  registered  incidences,  each  with  a distinct action
               configured by default.
                   incid-hashalg-has-params (Signed Object's hash algorithm has  NULL  object  as
                   parameters). [Default action: ignore]
                   incid-obj-not-der-encoded (Object isn't DER encoded). [Default action: ignore]
                   incid-file-at-mft-not-found (File listed at manifest doesn't exist).  [Default
                   action: error]
                   incid-file-at-mft-hash-not-match (File hash listed at manifest  doesn't  match
                   the actual file hash). [Default action: error]
                   incid-mft-stale (Manifest is stale).  [Default action: error]
                   incid-crl-stale (CRL is stale).  [Default action: error]

               More information about incidences can be consulted at FORT's web docs.

       -t, --tal=(FILE|DIRECTORY)
           Path  to  a  .tal,  or a directory containing .tal files. Fort will validate the trees
           pointed by them.

           The TAL ("Trust Anchor Locator") is a text file that lists a few  URLs  which  can  be
           used  to access the "Trust Anchor" (the root of a particular RPKI tree) and its public
           key. (See RFC 8630.)

       -r, --local-repository=DIRECTORY
           Path to a directory where the local cache of the  repository  will  be  stored  and/or
           read.

           FORT  accesses RPKI repositories either with rsync or RRDP (see RFC 8182). During each
           validation cycle, and depending on the preferred access methods defined  by  the  CAs,
           Fort can do two things:
               -  Literally  invoke  an  rsync  command  (see  rsync.program and rsync.arguments-
               recursive), which will download the files into --local-repository.
               - Fetch the RRDP Update Notification file (which  implies  an  HTTP  request)  and
               fetch  the  files  from  there  on  (can be obtained from a Snapshot file or Delta
               files). The files will be downloaed into --local-repository.

           Fort's entire validation process operates on the resulting copy of the files  (doesn't
           matter if the files where fetched by rsync of https).

           Because  rsync  uses  delta  encoding,  you’re  advised  to keep this cache around. It
           significantly speeds up subsequent validation cycles.

           By default, the path is /var/lib/fort.

       --daemon
           If this flag is activated, Fort will run as a daemon. The process is detached from the
           calling terminal and sent to the background.

           All  the enabled logs will be sent to syslog, so the configured values of --log.output
           and --validation-log.output will be ignored.

       --sync-strategy=(off|strict|root|root-except-ta)
           This argument will be DEPRECATED. Use --rsync.strategy or --rsync.enabled (if rsync is
           meant to be disabled) instead.

           rsync download strategy; states the way rsync URLs are approached during downloads.

           Despite this argument will be deprecated, it still can be utilized. It can have one of
           four values:
               - off: will disable rsync execution. So, using  --sync-strategy=off  will  be  the
               same as --rsync.enabled=false.
               - strict: will be the same as --rsync.strategy=strict.
               - root: will be the same as --rsync.strategy=root.
               -  root-except-ta  (default  value):  will  be  the same as --rsync.strategy=root-
               except-ta.

       --work-offline
           If this flag is activated, Fort will disable all  outgoing  requests  (currently  done
           with:  rsync and https (RRDP protocol uses HTTPS to fetch data)). All repository files
           (certificates, ROAs, etc.) are expected to exist at configured --local-repository.

           Otherwise, Fort will perform outgoing requests whenever this is needed. If a  specific
           protocol needs to be deactivated, use --rsync.enabled or --http.enabled.

       --shuffle-uris
           If  enabled,  FORT  will  access  TAL  URLs  in  random  order. This is meant for load
           balancing. If disabled, FORT will access TAL URLs in sequential order.

           By default, the flag is disabled.

           This flag is only relevant if the TAL lists more than  one  URL.  Regardless  of  this
           flag,  FORT will stop iterating through the URLs as soon as it finds one that yields a
           successful traversal.

           If the TAL lists more than one URL, the shuffle is done honoring the priority  of  the
           protocols (see --rsync.priority and --http.priority). i.e.  if the HTTP protocol has a
           higher priority than RSYNC, then all the shuffled HTTP URLs will come first.

       --maximum-certificate-depth=UNSIGNED_INTEGER
           Maximum allowable certificate chain length.  Meant  to  protect  FORT  from  iterating
           infinitely due to certificate chain loops.

           By default, it has a value of 32. The minimum allowed value is 5.

           (Required to prevent loops and "other degenerate forms of the logical RPKI hierarchy."
           (RFC 6481))

       --slurm=(FILE|DIRECTORY)
           Path to the SLURM FILE or SLURMs DIRECTORY.

           The SLURM definition is from RFC 8416. SLURM stands  for  "Simplified  Local  Internet
           Number  Resource  Management with the RPKI", basically is a document that can override
           (either as a filter or adding assertions) the global RPKI repository data  fetched  by
           FORT; potentially useful for network operators.

           In  case  a  DIRECTORY  is  set,  the  files  with extension '.slurm' will be the ones
           considered as SLURM files and FORT will use them.

           The configured SLURM path (either FILE or DIRECTORY) will be  read  each  time  a  new
           validation  cycle begins. If there's a syntax or content error, the last valid version
           of the SLURM will be applied (if there's one) and a message will be logged to indicate
           this  action.  Note  that  all  this  will happen only if --mode=server and --slurm is
           configured.

           A basic example of a SLURM file can be seen in this manual  at  the  EXAMPLES  section
           (it's almost the same as the one in RFC 8416).

           See more about SLURM configuration at FORT's web docs.

       --mode=(server|standalone)
           Commands the way FORT executes the validation, its possible values are:

           server
               Enable the RTR server using the server.* arguments.

           standalone
               Disable  the  RTR  server, the configuration options server.* are ignored and FORT
               performs an in-place standalone validation.

           By default, the mode is server.

       --server.address=NODE(S)
           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  list  of  addresses  must  be  comma  sepparated,  and each address must have the
           following format: <address>[#<port>]. Note that the port is optional; in case  that  a
           port   isn't  specified,  the  value  of  --server.port  will  be  utilized  with  the
           corresponding address.

           Here are some examples of valid values for this argument:
           - --server.address="localhost": will bind to 'localhost' and the  configured  port  at
           --server.port.
           -  --server.address="localhost,::1#8324":  same as the previous example, and also will
           bind to IPv6 address '::1' at the port '8324'.
           - --server.address="localhost#8323,::1#8324": will bind to 'localhost' at port '8323',
           and to '::1' port '8324'. The value of --server.port isn't utilized.

           If  this  field  is omitted, FORT will attempt to bind the server using the IP address
           INADDR_ANY (for an IPv4 address)  or  IN6ADDR_ANY_INIT  (for  an  IPv6  address).  See
           getaddrinfo(3).

       --server.port=SERVICE
           TCP  port  or service the server address(es) will be bound to by default if no port is
           set (see --server.address).

           This is a string because a service alias can be used as a valid value. The  alias  are
           commonly located at /etc/services. See also getaddrinfo(3) and services(5).

           The default port (323) is privileged. To improve security, either change or jail it.

           The   default   fort-validator.service  configuration  sets  the  CAP_NET_BIND_SERVICE
           capability to allow the unprivileged daemon to bind port 323 anyway.

       --server.backlog=UNSIGNED_INTEGER
           RTR server’s listen queue length. It’s the second argument of the function listen (see
           more  at  man  listen(2)).  This  provides  a  hint  to  the  implementation which the
           implementation shall use to  limit  the  number  of  outstanding  connections  in  the
           socket’s listen queue.

           By default, it has a value of SOMAXCONN.

       --server.interval.validation=UNSIGNED_INTEGER
           Number  of  seconds  that  FORT will sleep between validation cycles. The timer starts
           counting every time a validation is finished, not every time  it  begins.   Therefore,
           the actual validation loop is longer than this number.

           By default, it has a value of 3600.

       --server.interval.refresh=UNSIGNED_INTEGER
           Number of seconds that a router should wait before the next attempt to poll FORT using
           either a Serial Query PDU or Reset Query PDU. Countdown for  this  timer  starts  upon
           receipt of an End Of Data PDU (this should be administered by the client).

           This  value  is  utilized only on RTR version 1 sessions (more information at RFC 8210
           section 6).

           By default, it has a value of 3600. Minimum allowed value: 1,  maximum  allowed  value
           86400.

       --server.interval.retry=UNSIGNED_INTEGER
           Number  of seconds that a router should wait before retrying a failed Serial Query PDU
           or Reset Query PDU. Countdown for this timer starts upon  failure  of  the  query  and
           restarts  after  each  subsequent  failure  until  a  query  succeeds  (this should be
           administered by the client).

           This value is utilized only on RTR version 1 sessions (more information  at  RFC  8210
           section 6).

           By  default,  it  has  a value of 600. Minimum allowed value: 1, maximum allowed value
           7200.

       --server.interval.expire=UNSIGNED_INTEGER
           Number of seconds that a router can retain the current version of data while unable to
           perform a successful subsequent query. Countdown for this timer starts upon receipt of
           an End Of Data PDU (this should be administered by the client).

           This value is utilized only on RTR version 1 sessions (more information  at  RFC  8210
           section 6).

           By  default, it has a value of 7200. Minimum allowed value: 600, maximum allowed value
           172800. It must be larger than server.interval.refresh and server.interval.retry.

       --server.deltas.lifetime=UNSIGNED_INTEGER
           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.

       --log.enabled=true|false
           Enables the operation logs.

           By default, it has a value of true (these logs are enabled).

           Read more about logs at FORT validator's web docs, module 'Logging'.

       --log.level=(error|warning|info|debug)
           Defines which operation log messages will be logged according to its priority, e.g.  a
           value of info will log messages of equal or higher level (info, warning, and error).

           The priority levels, from higher to lowest, are:
               - error
               - warning
               - info
               - debug

           By default, it has a value of warning.

           Read more about logs at FORT validator's web docs, module 'Logging'.

       --log.output=(syslog|console)
           Desired output where the operation logs will be printed.

           The value console will log messages at standard output and standard error; syslog will
           log to syslog.

           Depending on the OS, distinct implementations of syslog could  be  installed  (syslog,
           rsyslog, or syslog-ng are the most common ones). Syslog usage and configuration is out
           of this man scope.

           By default, it has a value of console.

           Read more about logs at FORT validator's web docs, module 'Logging'.

       -c, --log.color-output=true|false
           If enabled, the operation logs output will contain ANSI color codes. Meant  for  human
           consumption.

           Meaningful only if --log.output value is console.

           By default, it has a value of false (it's disabled).

           Read more about logs at FORT validator's web docs, module 'Logging'.

       --log.file-name-format=(global-url | local-path | file-name)
           Decides which version of file names should be printed during most debug/error messages
           at the operation logs.

           Suppose a certificate was downloaded  from  `rsync://rpki.example.com/foo/bar/baz.cer`
           into the local cache `repository/`:

           global-url
               Will print the certificate's name as `rsync://rpki.example.com/foo/bar/baz.cer`.

           local-path
               Will           print          the          certificate's          name          as
               `repository/rpki.example.com/foo/bar/baz.cer`.

           file-name
               Will print the certificate's name as `baz.cer`.

           By default, it has a value of global-url.

           Read more about logs at FORT validator's web docs, module 'Logging'.

       --log.facility=(auth | authpriv | cron | daemon | ftp | lpr | mail | news | user | uucp  |
       from local0 to local7)
           Syslog  facility  utilized  for  operation  logs  (meaningful  only if --log.output is
           syslog).

           By default, it has a value of daemon.

           Read more about logs at FORT validator's web docs, module 'Logging'.

       --log.tag=STRING
           Text tag that will be added to the operation  log  messages  (it  will  appear  inside
           square brackets).

           By default, it has a NULL value.

           Read more about logs at FORT validator's web docs, module 'Logging'.

       --validation-log.enabled=true|false
           Enables the validation logs.

           By default, it has a value of false (these logs are disabled).

           Read more about logs at FORT validator's web docs, module 'Logging'.

       --validation-log.level=(error|warning|info|debug)
           Defines which validation log messages will be logged according to its priority, e.g. a
           value of info will log messages of equal or higher level (info, warning, and error).

           The priority levels, from higher to lowest, are:
               - error
               - warning
               - info
               - debug

           By default, it has a value of warning.

           Read more about logs at FORT validator's web docs, module 'Logging'.

       --validation-log.output=(syslog|console)
           Desired output where the validation logs will be printed.

           The value console will log messages at standard output and standard error; syslog will
           log to syslog.

           Depending  on  the  OS, distinct implementations of syslog could be installed (syslog,
           rsyslog, or syslog-ng are the most common ones). Syslog usage and configuration is out
           of this man scope.

           By default, it has a value of console.

           Read more about logs at FORT validator's web docs, module 'Logging'.

       -c, --validation-log.color-output=true|false
           If  enabled, the validation logs output will contain ANSI color codes. Meant for human
           consumption.

           Meaningful only if --validation-log.output value is console.

           By default, it has a value of false (it's disabled).

           Read more about logs at FORT validator's web docs, module 'Logging'.

       --validation-log.file-name-format=(global-url | local-path | file-name)
           Decides which version of file names should be printed during most debug/error messages
           at the validation logs.

           Suppose  a  certificate was downloaded from `rsync://rpki.example.com/foo/bar/baz.cer`
           into the local cache `repository/`:

           global-url
               Will print the certificate's name as `rsync://rpki.example.com/foo/bar/baz.cer`.

           local-path
               Will          print          the          certificate's          name           as
               `repository/rpki.example.com/foo/bar/baz.cer`.

           file-name
               Will print the certificate's name as `baz.cer`.

           By default, it has a value of global-url.

           Read more about logs at FORT validator's web docs, module 'Logging'.

       --validation-log.facility=(auth  |  authpriv  |  cron | daemon | ftp | lpr | mail | news |
       user | uucp | from local0 to local7)
           Syslog facility  utilized  for  validation  logs  (meaningful  only  if  --validation-
           log.output is syslog).

           By default, it has a value of daemon.

           Read more about logs at FORT validator's web docs, module 'Logging'.

       --validation-log.tag=STRING
           Text  tag  that  will  be  added to the validation log messages (it will appear inside
           square brackets).

           By default, it has the value Validation.

           Read more about logs at FORT validator's web docs, module 'Logging'.

       --http.enabled=true|false
           Enables outgoing HTTP requests.

           If disabled (eg. --http.enabled=false), FORT validator won't request  HTTP  URIs,  and
           will expect to find all the corresponding repository files at --local-repository.

       --http.priority=UNSIGNED_INTEGER
           Assign  priority  to use HTTP to fetch repository files. A higher value means a higher
           priority.

           This argument works along with --rsync.priority, since the higher  value  of  the  two
           arguments  will  result  in  the  first protocol to utilize when fetching repositories
           files. Of course, this depends also on certificates information or the TAL URIs, since
           currently HTTP URIs are optional and not every RIR repository makes use of them.

           Whenever  a  certificate or a TAL has both RSYNC and HTTP URIs, the following criteria
           is followed to prioritize which one to use first:
               -  --rsync.priority  equals  --http.priority:  use  the  order  specified  at  the
               certificate or the TAL to fetch the corresponding URI.
               -  --rsync.priority  greater  than  --http.priority:  use RSYNC repository/TAL URI
               first; if there's an error fetching data, fallback to  fetch  HTTP  repository/TAL
               URI.
               -  --rsync.priority  less than --http.priority: use HTTP repository/TAL URI first;
               if there's an error fetching data, fallback to use RSYNC repository/TAL URI.

           By default, the value is 60, so HTTP requests are preferred over rsync requests.

       --http.retry.count=UNSIGNED_INTEGER
           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.

           By default, the value is 2.

       --http.retry.interval=UNSIGNED_INTEGER
           Period  (in  seconds)  to  wait  between retries after an error ocurred requestin HTTP
           URIs.

           By default, the value is 5.

       --http.user-agent=STRING
           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.

           By default, the value is fort/<current-version>.

       --http.connect-timeout=UNSIGNED_INTEGER
           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 seconds 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.

           By default, it has a value of 30. The minimum allowed value is 1.

       --http.transfer-timeout=UNSIGNED_INTEGER
           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 (default value).

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

           By default, it has a value of 0.

       --low-speed-limit=UNSIGNED_INTEGER
           The value Fort employs as CURLOPT_LOW_SPEED_LIMIT during every HTTP transfer.

           "Abort connection if slower than LIMIT bytes/sec during TIME seconds."

           (See --low-speed-time.)

           Default: 100000 (100 KB/s)

       --low-speed-time=UNSIGNED_INTEGER
           The value Fort employs as CURLOPT_LOW_SPEED_TIME during every HTTP transfer.

           "Abort connection if slower than LIMIT bytes/sec during TIME seconds."

           (See --low-speed-limit.)

           Default: 10

       --http.max-file-size=UNSIGNED_INTEGER
           Maximum amount of bytes files are allowed to length during HTTP transfers.

           Default: 1000000000 (1 GB)

       --http.ca-path=DIRECTORY
           Local path where the CA’s utilized to verify the peers are located.

           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.

           By default, the path has a NULL value.

       --rrdp.enabled=true|false
           This argument will be DEPRECATED. Use --http.enabled instead.

       --rrdp.priority=UNSIGNED_INTEGER
           This argument will be DEPRECATED. Use --http.priority instead.

       --rrdp.retry.count=UNSIGNED_INTEGER
           This argument will be DEPRECATED. Use --http.retry.count instead.

       --rrdp.retry.interval=UNSIGNED_INTEGER
           This argument will be DEPRECATED. Use --http.retry.interval instead.

       --rsync.enabled=true|false
           Enables RSYNC requests.

           If  disabled  (eg.  --rsync.enabled=false),  FORT  validator  won't download files nor
           directories via RSYNC, and will expect  to  find  all  repository  files  at  --local-
           repository.

       --rsync.priority=UNSIGNED_INTEGER
           Assign  priority to use RSYNC to fetch repository files. A higher value means a higher
           priority.

           This argument works along with --http.priority, since the  higher  value  of  the  two
           arguments  will  result  in  the  first protocol to utilize when fetching repositories
           files. Of course, this depends also on certificates information or the TAL URIs, since
           currently HTTP URIs are optional and not every RIR repository makes use of them.

           Whenever  a  certificate  has  both  RSYNC  and  HTTP  URIs, the following criteria is
           followed to prioritize which one to use first:
               -  --rsync.priority  equals  --http.priority:  use  the  order  specified  at  the
               certificate or the TAL to fetch the corresponding URI.
               -  --rsync.priority  greater  than  --http.priority:  use RSYNC repository/TAL URI
               first;  if  there's  an  error  fetching  data,  fallback  to   use   fetch   HTTP
               repository/TAL URI.
               -  --rsync.priority  less than --http.priority: use HTTP repository/TAL URI first;
               if there's an error fetching data, fallback to use RSYNC repository/TAL URI.

           By default, the value is 50, so HTTP requests are preferred over rsync requests.

       --rsync.strategy=(strict|root|root-except-ta)
           rsync download strategy; states the way rsync URLs are approached during downloads. It
           can have one of three values: strict, root, root-except-ta(default value).

           strict
               In  order  to  enable  this  strategy,  FORT  must  be  compiled  using  the flag:
               ENABLE_STRICT_STRATEGY. e.g.
                $ make FORT_FLAGS='-DENABLE_STRICT_STRATEGY'

               RSYNC every repository publication point separately. Only skip 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`.

               This is the slowest, but also the strictly correct sync strategy.

           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=UNSIGNED_INTEGER
           Maximum number of retries whenever there's an error executing RSYNC.

           A value of 0 means no retries.

           Whenever is necessary to execute an RSYNC, the validator will  try  the  execution  at
           least  once. 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.

           By default, the value is 2.

       --rsync.retry.interval=UNSIGNED_INTEGER
           Period (in seconds) to wait between retries after an RSYNC error ocurred.

           By default, the value is 5.

       --output.roa=FILE
           File where the ROAs will be printed in the configured format (see --output.format).

           When  the  FILE is specified, its content will be overwritten by the resulting ROAs of
           the validation (if FILE doesn't exists, it'll be created).

           When --output.format=csv (which is the default value), then each line of the result is
           printed in the following order: AS, Prefix, Max prefix length; the first line contains
           those column descriptors.

           When --output.format=json, then each element is printed  inside  an  object  array  of
           "roas"; ie:
           {
             "roas": [
               {
                 "asn": "AS64496",
                 "prefix": "198.51.100.0/24",
                 "maxLength": 24
               },
               {
                 "asn": "AS64496",
                 "prefix": "2001:DB8::/32",
                 "maxLength": 48
               }
             ]
           }

           In  order  to  print  the  ROAs  at  console,  use  a  hyphen  as  the FILE value, eg.
           --output.roa=-

           By default, it has no value set.

       --output.bgpsec=FILE
           File where the BGPsec Router Keys will  be  printed  in  the  configured  format  (see
           --output.format).

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

           When the FILE is specified, its content will be overwritten by  the  resulting  Router
           Keys of the validation (if FILE doesn't exists, it'll be created).

           When --output.format=csv (which is the default value), then each line of the result is
           printed in the following order: AS, Subject Key Identifier, Subject Public  Key  Info;
           the first line contains those column descriptors.

           When  --output.format=json,  then  each  element  is printed inside an object array of
           "router-keys"; ie:
           {
             "router-keys": [
               {
                 "asn": "AS64496",
                 "ski": "<Base64 Encoded SKI>",
                 "spki": "<Base64 Encoded SPKI>"
               },
               {
                 "asn": "AS64496",
                 "ski": "<Base64 Encoded SKI>",
                 "spki": "<Base64 Encoded SPKI>"
               }
             ]
           }

           In order to print the Router Keys at console, use a hyphen  as  the  FILE  value,  eg.
           --output.bgpsec=-

           By default, it has no value set.

       --output.format=csv|json
           Output format for --output.roa and --output.bgpsec.

           By default, it has a value of csv.

       --thread-pool.server.max=UNSIGNED_INTEGER
           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.

           Minimum: 1
           Maximum: UINT_MAX
           Default: 20

       --thread-pool.validation.max=UNSIGNED_INTEGER
           Maximum  number of threads that will be spawned at an internal thread pool in order to
           run validation cycles.

           When a validation cycle begins, one thread per configured TAL is  utilized;  once  the
           whole RPKI tree of the TAL is validated, the thread is returned to the pool.

           If there are more TALs at --tal than --thread-pool.validation.max threads at the pool,
           is very likely that the validation cycles take a bit more of time  to  complete  since
           only  --thread-pool.validation.max  threads  will be working at the same time. E.g. if
           --thread-pool.validation.max=2 and the location at --tal has 4 TAL files, only 2  TALs
           will  be  validated  simultaneously  while  the rest waits in a queue until there's an
           available thread at the pool to attend them.

           By default, it has a value of 5. Minimum allowed value: 1, maximum allowed value 100.

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

           By default, it has a value of 4096 (4 kB).

       --stale-repository-period=UNSIGNED_INTEGER
           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 issues 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).

           Despite  who's  "fault"  is, FORT validator will try to work with the local files from
           --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  at  the validation log.  This
           argument (--stale-repository-period) is merely to send this error messages also to the
           operation log.

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

           By default, it has a value of 43200 (12 hours).

EXAMPLES

       fort --init-tals --tal=/tmp/tal
           Download the 5 RIR TALs into the specified directory. ARIN TAL will be downloaded only
           if the user accepts ARIN's RPA.

       fort -t /etc/tals -r /var/lib/fort --server.port=9323
           Run FORT with all the  default  values,  using  a  custom  TALs  directory,  a  custom
           repository directory as well, and binding the RTR server to port 9323.

       fort -t /etc/tals -r /var/lib/fort --mode=standalone --output.roa=-
           Run FORT as standalone and output ROAs CSV to the console.

       fort -t /etc/tals -r /var/lib/fort \
            --mode=standalone \
            --slurm=/etc/fort/slurm/
           Run FORT as standalone and using a SLURM file.

       fort --configuration-file=conf.json
           Run FORT using the JSON configuration file conf.json.

       fort -t /etc/tals -r /var/lib/fort \
            --server.address=::1 --server.port=9323 \
            --server.interval.validation=1800 \
            --output.roa=/tmp/roas.csv
           Run FORT with RTR server listening on IPv6 address ::1, port 9323, validating every 30
           minutes, and printing the ROAs CSV in a file.

       Complete configuration file
           This is an example of a valid JSON configuration file with all its members  set  to  a
           specific value:

           {
             "tal": "/etc/tals/",
             "local-repository": "/var/lib/fort/",
             "work-offline": false,
             "shuffle-uris": true,
             "maximum-certificate-depth": 32,
             "mode": "server",
             "daemon": false,
             "slurm": "/etc/fort/slurm/",
             "server": {
               "address": [
                 "192.0.2.1",
                 "2001:db8::1"
               ],
               "port": "8323",
               "backlog": 64,
               "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": "local-path",
               "facility": "daemon",
               "tag": "Operation"
             },
             "validation-log": {
               "enabled": false,
               "level": "warning",
               "output": "console",
               "color-output": true,
               "file-name-format": "local-path",
               "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
           }

       Dummy SLURM file
           This is an example of a SLURM file with some prefix filters and assertions, as well as
           some dummy Router Keys (BGPsec) info:

           {
             "slurmVersion": 1,
             "validationOutputFilters": {
               "prefixFilters": [
                 {
                   "prefix": "192.0.2.0/24",
                   "comment": "All VRPs encompassed by prefix"
                 },
                 {
                   "asn": 64496,
                   "comment": "All VRPs matching ASN"
                 },
                 {
                   "prefix": "198.51.100.0/24",
                   "asn": 64497,
                   "comment": "All VRPs encompassed by prefix, matching ASN"
                 }
               ],
               "bgpsecFilters": [
                 {
                   "asn": 64496,
                   "comment": "All keys for ASN"
                 },
                 {
                   "SKI": "Q8KMeBsCto1PJ6EuhowleIGNL7A",
                   "comment": "Key matching Router SKI"
                 },
                 {
                   "asn": 64497,
                   "SKI": "g5RQYCnkMpDqEbt9WazTeB19nZs",
                   "comment": "Key for ASN 64497 matching Router SKI"
                 }
               ]
             },
             "locallyAddedAssertions": {
               "prefixAssertions": [
                 {
                   "asn": 64496,
                   "prefix": "198.51.100.0/24",
                   "comment": "My other important route"
                 },
                 {
                   "asn": 64496,
                   "prefix": "2001:DB8::/32",
                   "maxPrefixLength": 48,
                   "comment": "My other important de-aggregated routes"
                 }
               ],
               "bgpsecAssertions": [
                 {
                   "asn": 64496,
                   "SKI": "Dulqji-sUM5sX5M-3mqngKaFDjE",
                   "routerPublicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE-rkSLXlPpL_m-L7CfCfKrv1FHrM55FsIc8fMlnjHE6Y5nTuCn3UgWfCV6sYuGUZzPZ0Ey6AvezmfcELUB87eBA"
                 }
               ]
             }
           }

SEE ALSO

       Regular man pages
           getaddrinfo(3), services(5), listen(2), rsync(1)

       FORTs official documentation
           More documentation  about  FORT  validator  can  be  consulted  at  github  repository
           (https://github.com/NICMx/FORT-validator)          and          github         website
           (https://nicmx.github.io/FORT-validator/)