control: accepts beacons and path segment registrations from past or future

[matzf]

As far as I can tell from reading the control service code, there is no check that a beacon or path segment registration is from the distant past or future.
I've not yet attempted to verify this with a practical reproduction scenario.

Note that the lifetime of the path segment is enforced to be contained in the lifetime of the certificate signing the AS entry. As only certificates under an active TRC are considered, this somewhat limits the accepted range of timestamps (IIUC, a few days into the future, up to some months in the past).

Accepting a beacon or path segment with a timestamp in the past may be mostly benign; it won't have operational effects (I think), but it could potentially still be abused in attempts to falsify records that might be relevant to auditing.
Beacons/path segments with timestamp in the future will be inserted into the database, however, and will be preferred over current path segments. A temporary compromise or misconfiguration of a control service can thus "poison" all path databases with a path segment that is not yet valid.

When receiving beacons and path segment registrations, the control service should check that beacons / path segments that are currently valid. The check should account for some clock drift, on the order of the hop expiration granularity (~5.5 minutes), to ensure that we don't require finely synchronized clocks.