From aaae3c484a82075ef1e3186c511cc34e9e31ea1a Mon Sep 17 00:00:00 2001 From: pcarana Date: Tue, 14 Jul 2020 18:32:04 -0500 Subject: [PATCH] Update docs with new incidences and server.address behavior +Also mark 100% compliance with manifests RFC, since the new incidences (stale objects) covers the missing 'local policies' of an RP. --- docs/incidence.md | 74 +++++++++++++++++++++++++++++++++++++++----- docs/intro-fort.md | 12 +------ docs/usage.md | 23 +++++++++++--- examples/config.json | 8 +++++ man/fort.8 | 38 +++++++++++++++++++++-- 5 files changed, 129 insertions(+), 26 deletions(-) diff --git a/docs/incidence.md b/docs/incidence.md index df38c8ac..2650989d 100644 --- a/docs/incidence.md +++ b/docs/incidence.md @@ -13,12 +13,14 @@ title: Incidence 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 @@ -80,9 +82,9 @@ Presently, there are a few incidences defined. This list might evolve further ov 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: ``` : : The hash algorithm of the '' has a NULL object as parameters @@ -104,7 +106,7 @@ This only applies to digest parameters that have been defined as NULL objects; a 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: ``` : : '' isn't DER encoded @@ -126,9 +128,9 @@ If not `ignore`d, Fort will report this incidence with the following error messa 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: ``` : : File '' listed at manifest doesn't exist. @@ -149,10 +151,66 @@ When the incidence is not `ignore`d, Fort will report it with the following mess 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: ``` : : File '' 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: + +``` +: : Manifest is stale. (nextUpdate: ) +``` + +### 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): + +``` +: : CRL is stale/expired +``` diff --git a/docs/intro-fort.md b/docs/intro-fort.md index fdfa5057..223f3f11 100644 --- a/docs/intro-fort.md +++ b/docs/intro-fort.md @@ -23,7 +23,7 @@ Further information can be found in the subsections below. | [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% | @@ -44,17 +44,7 @@ The vCard format is only used by Ghostbusters records. 6350 defines the basic vC 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. diff --git a/docs/usage.md b/docs/usage.md index 20402930..75c470b7 100644 --- a/docs/usage.md +++ b/docs/usage.md @@ -85,7 +85,7 @@ command: fort [--asn1-decode-max-stack=] [--stale-repository-period=] [--mode=server|standalone] - [--server.address=] + [--server.address=] [--server.port=] [--server.backlog=] [--server.interval.validation=] @@ -300,11 +300,18 @@ Run mode, commands the way Fort executes the validation. The two possible values ### `--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: `
[#]`. 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`'. @@ -314,7 +321,7 @@ If this field is omitted, Fort will attempt to bind the server using the IP addr - **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`'.) @@ -801,6 +808,14 @@ The configuration options are mostly the same as the ones from the `argv` interf { "name": "incid-file-at-mft-hash-not-match", "action": "error" + }, + { + "name": "incid-mft-stale", + "action": "error" + }, + { + "name": "incid-crl-stale", + "action": "error" } ], diff --git a/examples/config.json b/examples/config.json index 354e4ac2..37aacba8 100644 --- a/examples/config.json +++ b/examples/config.json @@ -92,6 +92,14 @@ { "name": "incid-file-at-mft-hash-not-match", "action": "error" + }, + { + "name": "incid-mft-stale", + "action": "error" + }, + { + "name": "incid-crl-stale", + "action": "error" } ], "output": { diff --git a/man/fort.8 b/man/fort.8 index fc5c8cb4..09b55c24 100644 --- a/man/fort.8 +++ b/man/fort.8 @@ -170,6 +170,12 @@ as parameters). [Default action: \fBignore\fR] .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. @@ -327,8 +333,25 @@ By default, the mode is \fIserver\fR. .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
[#]\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 @@ -338,7 +361,8 @@ an IPv6 address). See \fBgetaddrinfo(3)\fR. .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 @@ -1154,6 +1178,14 @@ to a specific value: { "name": "incid-file-at-mft-hash-not-match", "action": "error" + }, + { + "name": "incid-mft-stale", + "action": "error" + }, + { + "name": "incid-crl-stale", + "action": "error" } ], "output": { -- 2.47.2