> I’ve rolled up my sleeves and finished my implementation of the MAC > authentication protocol in babeld.
Excellent! I'll get to work on reviewing that as soon as teaching is under control. (In case anyone is interested -- we've got a lot of COVID-related restrictions, which I happen to support, but we're getting very little help with implementing them. I'm down to buying my own masks to distribute to students who forget theirs.) > There is one feature that I have not implemented (yet): expiring > per-neighbour state (section 4.4) using the Hello history or a timer > based on the last accepted packet. Yes, you have :-) The per-neighbour state is attached to the neighbour entry, and the neighbour entry will be discarded soon after the hello history becomes empty. See the function check_neighbours in neighbour.c, which is called periodically by the main loop. > The code has not undergone review. No interoperability testing has > been done. Please find out if you're allowed to enter the office (not obvious due to COVID). If not, I'll ask the boss for permission, or else we'll meet at my place. > I’m also looking for feedback on the user interface. [...] In > particular, do you think that implementing keysets and allowing an > unbounded number of keys is too much for babeld? As a general rule, I'm in favour of reflecting the implementation details in the user interface to the extent possible -- if you don't do that, the interface becomes confusing to the user who cannot build an accurate mental model of what's going on. If that's too complicated, I'd rather we add some macros than dumb down the interface. (Commands that expand to a sequence of lower-level commands.) You should consider what happens to your code when there are too many keys, and the MACs no longer fit in a packet. A silent failure would be bad. -- Juliusz _______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
