Hi Eduard, You need to stop moving the goalposts. Most network protocols use MD5. RFC 5310 added support for specifying other authentication algorithms, but that is up to the network's discretion to specify it; and network engineers are generally not going to manually select an encryption algorithm that their hardware isn't capable of doing quickly.
If you're concerned about adding latency to routing convergence, then stick with discussing the hash algorithms that are actually being widely used, which is still almost entirely MD5. Pointing at SHA-3 and saying "but that's slower on a particular processor I care about" isn't terribly relevant, because nobody's forcing you to use SHA-3 on that processor. Stick with MD5 if your processor is slow at SHA-3. (As an aside, the paper you cite shows the ARM-9 processor runs at 650 cycles per byte of input, so on a 2ghz ARM-9 processor, it'll take about 334 nanoseconds per byte of input run through SHA-3; a 1K input would thus take about 334 microseconds, or 0.3 ms). To your second point, as others have tried to explain, there is a difference between securing static secrets and preventing nuisance attacks. You need stronger security when you are protecting against access to static data that is vulnerable to longer-lasting attacks. For routing protocol security, the goal is NOT to keep data secret; there is generally nothing in an LSP that is particularly secret. What you are trying to do is prevent nuisance attacks from people trying to confuse your routing protocols. The encryption key in that case is simply raising the bar to make such attacks more headache than they are worth. If someone spends the resources to brute force figure out your encryption key, big whoop dee-doo, you go into your config generation system, pick a new encryption key, and push out new configs to your routers, and they're back to square one again. The attacker doesn't gain access to any secret information if they brute-force your MD5 hashed OSPF or IS-IS authentication key. The worst they can do is disrupt your routing protocol by sending bad information into it until you change the authentication key, which is generally trivial to do. As such, there is no particular need to move to "stronger" encryption functions than your hardware is capable of supporting, because there's nothing secret you're trying to protect; you're simply making it difficult enough to send bogus data into your network that most attackers won't bother trying. Please stop moving the goalposts to try to bolster your defense of a defenseless position. :( Thank you. Matt On Tue, Sep 9, 2025 at 11:40 PM Vasilenko Eduard < vasilenko.edu...@huawei.com> wrote: > Hi Matthew, > > Thanks for the discussion. It is the right approach to calculate carefully. > > I do not believe that MD5 is a good basis; NIST recommends moving away > from it. I am not qualified to question NIST decisions. > > I have already pointed out the reference to IJCNA-2020-O-01.pdf > <https://www.ijcna.org/Manuscripts/IJCNA-2020-O-01.pdf>. It is SHA-3; I > have not found good data for SHA-2 (I was interested in ARM). > > They have a table in section 6.1 for all sizes. It is 4151199 Cycles for > 750B. The maximum clock for the ARM core is about 2Ghz (practically less, > routers do not have enough cooling for this). Hence, this 750B would be > checked for 2ms. > > There is a discussion in the IETF that in the big networks, many > attributes (TE, flex-algo, whatever) are attached in ISIS, hence the packet > may be full size (1500B). Then the hash would be 4ms. > > Twice (8ms) if the message is relayed, because a hash would be needed on > input and output. > > > > Hence, I do not understand why 5ms is “completely incorrect”. > > Eduard > _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/WNV7CXGGGETNVC3TY4WJ4YMWAH4FMORT/
