Routers

Index

1. Introduction
2. Server configuration
3. Router configuration
4. Behavior
   1. (Re)start
   2. Continuous validation

Introduction

Just as mentioned at Introduction to Fort, the validated ROAs prefixes and BGPsec router certificates are served so that any router can request them. This is where the RTR protocol comes in.

Fort validator supports RTR version 0 (RFC 6810) and version 1 (RFC 8210). It depends on the router RTR implementation which version to use during the data exchange.

Server configuration

The most relevant program arguments for the communication of Fort validator with the routers are:

• --mode: must have the value server in order to run FORT validator as RTR server.
• --server.address: network address where the server will listen for routers.
• --server.port: port or service (see ‘$ man services’) where the server will listen for routers.
• --server.backlog: max number of outstanding connections in the server listen queue.
• --server.interval.validation: wait time (in seconds) between validations cycles. It also affects on how often the server could send update notifications to the routers (if there are updates as result of the last validation cycle).
• --server.interval.refresh: “This parameter tells the router how long to wait before next attempting to poll the cache and between subsequent attempts” (definition of “Refresh Interval” from RFC 8210 section 6).
• --server.interval.retry: “This parameter tells the router how long to wait before retrying a failed Serial Query or Reset Query.” (definition of “Retry Interval” from RFC 8210 section 6).
• --server.interval.expire: “This parameter tells the router how long it can continue to use the current version of the data while unable to perform a successful subsequent query” (definition of “Expire Interval” from RFC 8210 section 6).

Router configuration

Each router has its own way to configure its connection with an RTR server, but the basic data needed to configure this is:

• Server address and port: where the RTR server is located (configured at --server.address and --server.port).
• Refresh interval: how often does the router will ask for updates to the server.
• Preference: if multiple RTR servers are allowed, this indicates the preference order of each one of them. This way the router will go for updates according to such order.

Here are a few links to the RPKI configuration docs at some routers:

• FRR
• Cisco
• Juniper
• BIRD
• MikroTik (will be supported until ROSv7, currently at beta stage)
• Nokia (commands and explanation)
• Huawei (look for your specific router model)
• Arista

Behavior

(Re)start

When Fort validator is run for the first time, the RTR server will listen for router connections at --server.address:--server.port once its first validation cycle ends.

If a router tries to establish a connection with Fort before the first validation cycle ends, Fort won’t respond at all, causing the router to wait some time (this will depend on each router) before asking for updates again.

Once FORT validator ends its first validation cycle, it will share the resulting data (also known as “Validated ROA Payloads” or VRPs) with any router that establishes an RTR connection.

TIP: When Fort validator is run for the first time, wait a couple of minutes to connect the router, so that it can fetch all the valid data once the connection is established.

Continuous validation

FORT validator will keep fetching and validating the repositories data once every --server.interval.validation seconds. If there are any updates at the VRPs, FORT will notify the routers so that they can request the updates; it’s up to the routers to attend or ignore this notification message.

Beside the notifications sent by the RTR server, the routers can periodically ask for updates. This can be configured at the router (see Router configuration) and/or at the server (see --server.interval.refresh).