The data plane ietf draft specifies a maximum time to live of a hop in order to limit the potential time window available for brute-force attack on HOP validation MACs. Without dropping segments crafted in the future, that time window could be extended indefinitely by an attacker (by forging a segment with a creation date in an arbitrarily far future - not beyond 2106 though) thereby defeating the purpose of the limited time to live.
In response to the request for clarification in https://github.com/scionassociation/scion-cp_I-D/issues/18 the draft will also state that segments from the future (with some specific tolerance) are to lead to dropping the packet. The code must be made compliant. There also is code in the router that assumes paths are checked for a timestamp in the future with no tolerance. That code backdates the path that it crafts by 10s to compensate for clock drift. This compensation should be part of the check instead (once it exists).
The data plane ietf draft specifies a maximum time to live of a hop in order to limit the potential time window available for brute-force attack on HOP validation MACs. Without dropping segments crafted in the future, that time window could be extended indefinitely by an attacker (by forging a segment with a creation date in an arbitrarily far future - not beyond 2106 though) thereby defeating the purpose of the limited time to live.
In response to the request for clarification in https://github.com/scionassociation/scion-cp_I-D/issues/18 the draft will also state that segments from the future (with some specific tolerance) are to lead to dropping the packet. The code must be made compliant. There also is code in the router that assumes paths are checked for a timestamp in the future with no tolerance. That code backdates the path that it crafts by 10s to compensate for clock drift. This compensation should be part of the check instead (once it exists).