+Also mark 100% compliance with manifests RFC, since the new incidences (stale objects) covers the missing 'local policies' of an RP.
2. [Object isn't DER encoded](#object-isnt-der-encoded)
3. [File listed at manifest doesn't exist](#file-listed-at-manifest-doesnt-exist)
4. [File hash listed at manifest doesn't match the actual file hash](#file-hash-listed-at-manifest-doesnt-match-the-actual-file-hash)
+ 5. [Manifest is stale](#manifest-is-stale)
+ 6. [CRL is stale](#crl-is-stale)
## Introduction
The RPKI RFCs define fairly strict profiles for RPKI objects, and are unequivocal in stating that incorrectly-formed objects are supposed to be rejected by Relying Party validation. In practice, however, this does not prevent a significant amount of legitimate Certificate Authorities from issuing incorrect objects.
-The `incidence` section of Fort's configuration file is a means to modify its behavior upon encountering profile violations that, from experience, are often overlooked.
+The `incidence` section of FORT's configuration file is a means to modify its behavior upon encountering profile violations that, from experience, are often overlooked.
## `incidences` definition
parameters field;
```
-As of 2020-01-31, many signed objects in the global RPKI break this rule.
+As of 2020-07-14, many signed objects in the global RPKI break this rule.
-If not `ignore`d, Fort will report this incidence with the following error message:
+If not `ignore`d, FORT will report this incidence with the following error message at the validation log:
```
<log level>: <offending file name>: The hash algorithm of the '<object>' has a NULL object as parameters
Altough this is mandatory, quite a few signed objects in the global RPKI ignore this rule and are simply BER-encoded.
-If not `ignore`d, Fort will report this incidence with the following error message:
+If not `ignore`d, FORT will report this incidence with the following error message at the validation log:
```
<log level>: <offending file name>: '<object>' isn't DER encoded
If there's a missing file, it could be a publisher error or even an attack against the publication point (see [section 6.5](https://tools.ietf.org/html/rfc6486#section-6.5)).
-By default, Fort validator will handle this as an error, thus discarding the manifest file.
+By default, FORT validator will handle this as an error, thus discarding the manifest file.
-When the incidence is not `ignore`d, Fort will report it with the following message:
+When the incidence is not `ignore`d, FORT will report it with the following message at the validation log:
```
<log level>: <manifest file name>: File '<file name>' listed at manifest doesn't exist.
It's up to a local policy to discard these files (and the rest of the manifest files) or trust in them (see [section 6.6](https://tools.ietf.org/html/rfc6486#section-6.6)).
-By default, Fort validator will discard such files and the manifest as well.
+By default, FORT validator will discard such files and the manifest as well.
-When the incidence is not `ignore`d, Fort will report it with the following message:
+When the incidence is not `ignore`d, FORT will report it with the following message at the validation log:
```
<log level>: <manifest file name>: File '<file name>' does not match its manifest hash.
```
+
+### Manifest is stale
+
+- **Name:** `incid-mft-stale`
+- **Default action:** `error`
+
+[RFC 6486 section 6.1](https://tools.ietf.org/html/rfc6486#section-6.1) considers this scenario:
+
+```
+ 3. Check that the current time (translated to UTC) is between
+ thisUpdate and nextUpdate.
+
+ If the current time does not lie within this interval, then see
+ Section 6.4 {..}
+```
+
+And citing [section 6.4](https://tools.ietf.org/html/rfc6486#section-6.4):
+
+```
+ A manifest is considered stale if the current time is after the
+ nextUpdate time for the manifest. {..}
+
+ All signed objects at the publication point issued by the entity that
+ has published the stale manifest, and all descendant signed objects
+ that are validated using a certificate issued by the entity that has
+ published the stale manifest at this publication point, SHOULD be
+ viewed as somewhat suspect, but MAY be used by the RP as per local
+ policy.
+```
+
+This 'local policy' is the equivalent to the incidence `incid-mft-stale`.
+
+By default, FORT validator will discard a stale manifest and all of its listed elements.
+
+When the incidence is not `ignore`d, FORT will report it with the following message at the validation log:
+
+```
+<log level>: <manifest file name>: Manifest is stale. (nextUpdate: <human readable date> )
+```
+
+### CRL is stale
+
+- **Name:** `incid-crl-stale`
+- **Default action:** `error`
+
+The RFC's aren't clear about stale CRLs; but as strict (or pedantic) as FORT is, a stale CRL isn't trusted by default. A stale CRL is the one where its 'nextUpdate' is in the past.
+
+The "cost" of stop using a stale CRL, is that all of the related CA childs will be discarded as well.
+
+There's a whole discussion on this subject at SIDROPS WG (see the mail archive for ["[Sidrops] what to do when the CRL is hosed?"](https://mailarchive.ietf.org/arch/msg/sidrops/tCybZO7YvXbdVm5pA7DbHEnuKEc/); so, until a concensus is reached on the matter, the RP operator can configure the incidence `incid-crl-stale` to decide how to treat this CRLs.
+
+When the incidence is not `ignore`d, FORT will report it with the following message at the validation log (note that the CRL is validated as part of the manifest validation):
+
+```
+<log level>: <manifest file name>: CRL is stale/expired
+```
| [3779](https://tools.ietf.org/html/rfc3779) (IP & AS Extensions) | 100% |
| [6350](https://tools.ietf.org/html/rfc6350) (vCard) | 0% |
| [6482](https://tools.ietf.org/html/rfc6482) (ROA) | 100% |
-| [6486](https://tools.ietf.org/html/rfc6486) (Manifests) | 75% |
+| [6486](https://tools.ietf.org/html/rfc6486) (Manifests) | 100% |
| [6487](https://tools.ietf.org/html/rfc6487) (Resource Certificates & CRLs) | 100% |
| [6488](https://tools.ietf.org/html/rfc6488) (Signed Objects) | 100% |
| [6493](https://tools.ietf.org/html/rfc6493) (Ghostbusters) | 100% |
The specific validations have been implemented, while the basic ones have not.
-### RFC 6486 (Manifests)
-
-This RFC states a bunch of rules that allow some level of tolerance to missing, invalid or stale manifests. Here's an example:
-
-> signed objects (...) issued by the entity that has published the stale manifest (...) SHOULD be viewed as somewhat suspect, but MAY be used by the RP as per local policy.
-
-These constitute the approximate missing 25%.
-
## TO-DO
- Reach 100% RFC compliance
- Daemon quirks (stuff like "send self to background automatically"), maybe
-- Allow to handle stale objects (CRLs and Manifests) as incidences.
-- Bind RTR server to multiple IPs.
[--asn1-decode-max-stack=<unsigned integer>]
[--stale-repository-period=<unsigned integer>]
[--mode=server|standalone]
- [--server.address=<string>]
+ [--server.address=<sequence of strings>]
[--server.port=<string>]
[--server.backlog=<unsigned integer>]
[--server.interval.validation=<unsigned integer>]
### `--server.address`
-- **Type:** String
+- **Type:** String array
- **Availability:** `argv` and JSON
- **Default:** `NULL`
-Hostname or numeric host address the RTR server will be bound to. Must resolve to (or be) a bindable IP address. IPv4 and IPv6 are supported.
+List of hostnames or numeric host addresses where 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`](#--serverport) 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`](#--serverport).
+- `--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`](#--serverport) 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 '`$ man getaddrinfo`'.
- **Availability:** `argv` and JSON
- **Default:** `"323"`
-TCP port or service the server will be bound to.
+TCP port or service where the server address(es) will be bound to by default if no port is set (see [`--server.address`](#--serveraddress)).
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 services`'.)
{
"name": "incid-file-at-mft-hash-not-match",
"action": "error"
+ },
+ {
+ "name": "incid-mft-stale",
+ "action": "error"
+ },
+ {
+ "name": "incid-crl-stale",
+ "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": {
.br
\fIincid-file-at-mft-hash-not-match\fR (File hash listed at manifest doesn't
match the actual file hash). [Default action: \fBerror\fR]
+.br
+\fIincid-mft-stale\fR (Manifest is stale).
+[Default action: \fBerror\fR]
+.br
+\fIincid-crl-stale\fR (CRL is stale).
+[Default action: \fBerror\fR]
.RE
.P
More information about incidences can be consulted at FORT's web docs.
.B \-\-server.address=\fINODE\fR
.RS 4
-Hostname or numeric host address the RTR server will be bound to. Must resolve
-to (or be) a bindable IP address. IPv4 and IPv6 are supported.
+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.
+.P
+The list of addresses must be comma sepparated, and each address must have the
+following format: \fB<address>[#<port>]\fR. Note that the port is optional; in
+case that a port isn't specified, the value of \fI--server.port\fR will be
+utilized with the corresponding address.
+.P
+Here are some examples of valid values for this argument:
+.br
+- \fI--server.address="localhost"\fR: will bind to 'localhost' and the
+configured port at \fI--server.port\fR.
+.br
+- \fI--server.address="localhost,::1#8324"\fR: same as the previous example,
+and also will bind to IPv6 address '::1' at the port '8324'.
+.br
+- \fI--server.address="localhost#8323,::1#8324"\fR: will bind to 'localhost' at
+port '8323', and to '::1' port '8324'. The value of \fI--server.port\fR isn't
+utilized.
.P
If this field is omitted, FORT will attempt to bind the server using the IP
address \fIINADDR_ANY\fR (for an IPv4 address) or \fIIN6ADDR_ANY_INIT\fR (for
.B \-\-server.port=\fISERVICE\fR
.RS 4
-TCP port or service the server will be bound to.
+TCP port or service the server address(es) will be bound to by default if no
+port is set (see \fI--server.address\fR).
.P
This is a string because a service alias can be used as a valid value. The
alias are commonly located at \fI/etc/services\fR. See also
{
"name": "incid-file-at-mft-hash-not-match",
"action": "error"
+ },
+ {
+ "name": "incid-mft-stale",
+ "action": "error"
+ },
+ {
+ "name": "incid-crl-stale",
+ "action": "error"
}
],
"output": {
projects / thirdparty / FORT-validator.git / commitdiff
