Earlier, Dow Street wrote:
% I have also been thinking about this type of path hash
% - a (compressed) record of the router interfaces the packet
% has traversed. If the receiver saw the hash value change
% over the course of a session, it would be a hint that the path
changed:
%
% - restart congestion control / RTT measurements?
% - off-path attacker spoofing packets?
% - persistent oscillation of hash values -> load-balanced links
% somewhere (watch for packet re-ordering)
%
% It may make sense to have the hash done per router *interface*.
% If we're making host changes, something like this is probably worth
% considering as a part of the information exchange between network
% and endpoint.
Maybe I'm confused, but the above seems to be suggesting that:
1) a hash computation needs to be done for each packet
that goes through each router interface along the path
from origin to destination
2) the hash result is placed somewhere in the packet being
forwarded, meaning that each packet would be modified
in transit by each router
If I am not confused, each of those ideas would seem to
increase the per-packet cost of packet forwarding in a
very significant way. Absent new custom hardware to
support that function, it isn't obvious how it could be done
at line-rate for interesting interface speeds (e.g. 1 Gbps
or higher speed).f
Did I miss something here ?