On Thu, Sep 11, 2025 at 2:24 AM Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
You are right again that MD5 is mostly used, not SHA-2, and nobody supports SHA-3. It was strange for me that the community does not pay attention to the NIST recommendation.
There are few real-world software programs or network protocols using SHA-3 for any purpose, and the IETF or network community is not bound to blindly follow every NIST advisory without considering threat models, and what purposes the hash serves in their design. For the main purpose the feature exists. a MD4 or weaker hash'd likely be adequate. The weak point might not be the hash, for example RFC 2385 - Md5 option for BGP. Does not create a heavily replay-resistant authentication, since the hash covers only TCP segment data, and TCP header excluding options. Anything to identify when the packet was actually sent (Timestamps are an optional TCP option, which could therefore be modified on a saved packet without affecting the auth. hash check.) 16-bit TCP Ack and Seq counters are unique, but they are also reused by new TCP sessions, and will wrap and roll to 0 eventually on a long-lived sesion. All your adversary needs then is enough old packets captured over a period of time with the same key and saved to get appropriate Seq values and Ack values. For example, Suppose you are a threat actor with physical access or in a position to actually capture and save packets between routers: Should you be in a position to get a sample packet to attack the hash: In this position you have at least 2 trivial attack methods to corrupt the adjacency. Capture+replay old legitimate packets in order to corrupt the data exchange, or flood spoofed MAC frames causing unicast frames b/w peers to go to you instead - which prevents routers from forwarding packets b/w each other over that LAN all without affecting routing protocol routes or adjacencies. It is not just a lower difficulty attack.. Forwarding disruption is harder to detect, since the routing protocol does not detect and log routes going down. In case you actually needed to prevent corruption; a stronger hash wouldn't help. I believe for EGPs: You would have to use BGP over TLS (BGPSEC), and not the hashing option alone in the first place. For IS-IS; You'd have a not easily-solvable problem at that point. You might use a combination of tunneling and IPSEC to prevent replay, But your attacker's presence on the shared LAN segment b/w internal routers (necessary for them to see hash values being exchanged in the first place), opens up more DoS options for the adversary than I could count. -- -JA