Summary

  • LACNIC's 20 July announcement says FORT 1.7.0 validates ASPA objects and shares the information with routers; it also says the feature is experimental because ASPA has not yet been published as a standard.
  • The corresponding 1.7.0.experimental release sets --server.max-rtr-version to 0 by default, while the tagged guide says ASPA reaches routers in RTRv2. The separate --output.aspa file path is also disabled by default.
  • A defensible activation record must keep release capability, local configuration, negotiated protocol, accepted ASPA data, calculated path state and route-policy action as separate events.

The new feature arrives with a gate, and the gate is set to zero.

On 20 July, the LACNIC Blog described FORT 1.7.0 as implementing validation for Autonomous System Provider Authorization objects and sharing the information with routers so they can make better routing decisions. Four days earlier, the project's actual release had given the version a longer name: 1.7.0.experimental. Its notes say it implements ASPA and RTRv2, then state that the maximum RTR version offered by the server defaults to zero.

Both accounts are true. One describes what the software can do. The other describes what it does before an operator makes a choice. The governance problem begins when those two states are read as one.

There is no basis here for saying that LACNIC hid the experimental status. The blog says plainly that ASPA had not been officially published as a standard and might still change. Nor is a conservative default evidence of a defective release. The release notes explain the reason: FORT does not currently yield router keys, which removes the purpose of RTRv1 for this implementation, while the RTRv2 specification is still changing. The narrower question is whether an operator, auditor or downstream network can reconstruct the complete path from installed capability to routing consequence.

Three controls sit behind one launch sentence

The tagged FORT usage guide exposes three different controls.

Control Release default What it governs
--aspa.max-providers 4,000 The maximum provider ASNs one customer ASN may declare across the RPKI trees in a validation cycle
--output.aspa NULL (disabled) Whether validated ASPAs are written to a JSON file or standard output
--server.max-rtr-version 0 The highest RPKI-to-Router protocol version the FORT server will negotiate with clients

These switches operate at different layers. The first is a validation bound. The second creates a file output. The third controls the live protocol surface presented to router clients. Turning on one does not turn on the others.

The guide is unusually explicit about payload history. RTRv0 serves prefix validation records. RTRv1 adds router keys. RTRv2 adds ASPAs. It then says FORT's experimental RTRv2 implementation follows draft-ietf-sidrops-8210bis-25, and that the default maximum is expected to rise as the implementation matures.

With the ceiling left at zero, FORT can still validate ASPA objects internally. It can also write them to a file if --output.aspa is separately configured. But a router session negotiated at version 0 cannot receive the version-2 ASPA PDU. Saying that does not tell us how any real deployment is configured. It tells us only what the published default permits.

Version negotiation is an operational event

The current RTRv2 Internet-Draft, revision 27, makes the next boundary concrete. A router begins with the highest version it implements. If the cache supports that version, the session opens there. If the cache supports a lower compatible version, negotiation can establish the lower version instead. Once downgraded, the higher-version features are unavailable for that session.

That makes configuration only half the evidence. Even if an operator raises FORT's ceiling to 2, the client must support and request version 2, the session must complete at version 2, and the cache must deliver the ASPA payload without a protocol or validation failure. A configuration file proves intention. A negotiated session proves a particular delivery channel. Neither proves what the router later did with the data.

The sequence also creates a useful failure taxonomy:

  1. the installed binary may not be the intended release;
  2. ASPA objects may be absent, rejected or limited during validation;
  3. file output may remain disabled;
  4. the server ceiling may remain below 2;
  5. the client may negotiate a lower version;
  6. a version-2 session may receive no usable ASPA payload for the relevant customer AS;
  7. the router may compute Unknown rather than Invalid;
  8. local policy may observe a result without changing route eligibility.

The launch sentence cannot carry all eight states. An operational record can.

A signed object is not a routing decision

The current ASPA profile defines a signed object through which the holder of a customer ASN authorises one or more provider ASNs. The relying party first validates the object under the RPKI rules. That produces usable provider-authorisation data. It does not by itself classify a BGP path.

The current ASPA verification draft describes the later step. A router evaluates a path as Valid, Unknown or Invalid. Missing information can produce Unknown; a bad object is not the only way to avoid a Valid result. The draft recommends making Invalid paths ineligible for route selection and treating Unknown at the same preference as Valid. It also says the specific mitigation policy remains at the network operator's discretion.

This separation matters. A dashboard that counts validated ASPA objects measures the relying-party layer. A version-2 session measures transport. A path-state counter measures calculation. A routing-information-base or forwarding result measures applied policy. Each is useful; none is a substitute for the next.

It is therefore too strong to infer that installing FORT 1.7.0.experimental protects a network against route leaks. It is also too strong to infer that an operator without RTRv2 is doing nothing: file exports can support testing, and origin validation continues at earlier protocol versions. The precise statement is less dramatic and more useful. FORT ships an experimental ASPA capability whose router-delivery path requires an explicit version choice and a compatible downstream policy.

Draft provenance belongs in the release record

The tagged guide says the implementation follows revision 25 of the RTRv2 draft. At the research cutoff, the current text was revision 27, dated 13 August. The ASPA object profile was at revision 29, and the path-verification document had reached revision 28 on 24 August.

Those numbers do not prove incompatibility. A higher revision can contain editorial repairs, clarifications or substantive changes; only a comparison and interoperability test can establish the effect. The numbers do prove that supports RTRv2 is incomplete provenance for experimental software. The claim needs an exact draft revision, code commit, build identity and tested peer set.

RFC 8210 remains the published specification for RPKI-to-Router version 1. The ASPA PDU belongs to the version-2 work in progress. This is precisely why the release's conservative default is intelligible. It is also why later operators need to know when the implemented draft and the current draft diverge, when a retest occurs, and which result justified changing the default.

Download counts cannot answer those questions. A downloaded package is not an installation. An installation is not a running process. A running process is not a version-2 session. A session is not an applied mitigation. Evidence should stop at the layer it observed.

A two-part capability and activation record

The smallest durable design has a public release card and a locally generated activation receipt. LACNIC and the FORT project can publish the first without collecting private network telemetry. Operators can retain the second, disclose it during an incident or audit, and expose only safe aggregates where useful.

Release-card field Why it matters
Source tag and commit Identifies the reviewed code
Package name and hash Identifies the installed candidate bytes
ASPA profile revision Fixes the signed-object grammar and validation basis
RTRv2 revision Fixes the wire protocol implemented
Verification revision Fixes the path-state algorithm expected downstream
Defaults and ranges Shows which capability remains dormant before configuration
Known deviations Prevents a generic support label from hiding exclusions
Interoperability set Names tested router clients and negotiated versions without implying universal support
Supersession and rollback Makes later corrections traceable

The operator receipt begins where the release card ends. It records the installed package hash, process start and configuration fingerprint; the maximum RTR version; privacy-safe counts of clients by negotiated version; the validation-cycle time; accepted and rejected ASPA counts with reason classes; file-output state and hash if used; route-verification mode; path-state counts; mitigation policy; and the rollback or exception state.

Router identities and private topology need not be public. A network can publish an aggregate such as three clients negotiated v2, one v0, last successful validation at time T, while keeping exact endpoints protected. A public zero is not always necessary; a verifiable local receipt may be enough for assurance, procurement or incident review.

The join key between the two records is critical: package hash, implementation revision and configuration fingerprint. Without it, a release page describes possible behaviour while an operator report describes an unnamed process. With it, a reviewer can tell whether the running system is the capability that was assessed.

What the checked record does not establish

The sources do not show how many networks installed the release, how many changed the default, which routers negotiated version 2, how many ASPA objects passed validation, or whether any route became ineligible. They do not show that the LACNIC blog is false, that the project should have enabled RTRv2 by default, or that revision 25 is incompatible with revision 27.

They also do not establish universal protection. ASPA is designed for provider-authorisation evidence and route-leak detection. It does not authenticate every operational relationship, validate the forwarding plane, eliminate incomplete information or remove local routing authority.

What the record establishes is narrower. FORT 1.7.0.experimental implemented ASPA and RTRv2. Its router-version ceiling defaulted to 0. Its ASPA file output defaulted to disabled. Its documentation tied the implementation to a specific work-in-progress revision. The later verification choice belonged to the operator.

That is enough to replace the vague question—Does FORT support ASPA?—with the questions that matter: which build, which draft, which output, which negotiated session, which path state, which policy, and which rollback?

Sources