On Sep 22, 2025, at 9:55 AM, Deb Cooley <[email protected]> wrote: > I have no earthly idea why one would propose a protocol, TLS, for a > function such as this. I wouldn't imagine that TLS would be fit for > purpose in this use case.
TLS was used just as an example of a "solution" which would be too high overhead. > The question is how to generate bits in a way that is only known to the two > endpoints, and do that fast enough to provide a reasonably unguessable > value to shove into packets. Classically, a stream cipher (AES in OFB mode > for example) is much faster than normal block cipher modes (the normal AES > GCM). If the CPUs in question have the AES standard cell in hardware, it > should be fast and require less implementation to get wrong. CHA-CHA is > also a stream cipher, but it is normally implemented in S/W, so I'm not > sure how fast it is. The systems are highly constrained. and don't have AES in hardware. CHA-CHA is a cipher, and isn't useful here. We need a way to authenticate the packet contents. Right now, that's done with MD5 as Hash(packet + key). Failing that, the idea is to generates a stream of pseudo-random numbers based on shared / secret state. That's the ISAAC method which we propose here. Paul suggested SipHash. Perhaps it is fast enough to replace the use of MD5 in BFD. But doing that would involve a new document. > If there is an instance of using ISAAC in this use case, there will be > gigantic warnings about how this is NOT a general purpose option. I'm not > a fan, nor is any other Sec AD I've ever met, of picking an algorithm out > of the blue and using it without evaluation, no matter how old it is. Sure. > Before I answer the other comments, I have some homework to do (where does > RFC5880 get/generate/negotiate keys since apparently I read something > wrong). The keys are not generated. The keys are really shared secrets entered by humans, in an admin interface. i.e. ASCII text. The keys are not negotiated. There is no way to signal "you sent me key X, but I want to use key Y". BFD just proposes a key ID. The other end either uses the corresponding key, or else it tears the session down. While there are provisions for using multiple keys, in practice, there's really only one shared secret for any BFD peers which communicate. Alan DeKok.
