Hi David, Add "Is there someone will to do the work and maintain the code?" to the non-library options. The answer to that q. very well could be "no" in which case the library is definitely the way to go. :) Thanks, Chris. "Ward, David - 0665 - MITLL" <david.ward@ll.mit.edu> writes:
FRR has an "internal" implementation of the MD5 and SHA-256 algorithms, including HMAC functions for both. [1] This code is under a BSD license, and provides an alternative to linking FRR against OpenSSL, for which there were historical (?) issues around GPL incompatibility. Several routing protocols use one of these hash algorithms.
ospf6d was extended last year to support the OSPFv3 Authentication Trailer (RFC 7166), which may use any of HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA-512. [2] The choice of algorithm is limited unless FRR has been compiled with OpenSSL support.
Can we update FRR's internal crypto implementation in order to overcome this limitation? For example: * Gnulib provides a drop-in version of each of the algorithms mentioned above for inclusion in open-source projects, available under LGPL 2.1. * FreeBSD has adapted Colin Percival's SHA-256 implementation to support the other SHA-2 algorithms (but without the HMAC functions - which would seem straightforward to adapt). * Or should FRR rely on an external library for these functions instead? Should it allow the use of something other than OpenSSL, such as Libgcrypt?
Thanks in advance,
David
[1] The SHA-256 implementation was written by Colin Percival, originally for FreeBSD. His current version seems to be here: https://github.com/Tarsnap/libcperciva/blob/master/alg/sha256.c
[2] ospf6d also supports the use of HMAC-MD5 here, despite this not being specified in RFC 7166.
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev