[quagga-dev 10555] Re: RFC-6506(Supporting Authentication Trailer for OSPFv3) implementation in quagga-0.99.21 version

Denis Ovsienko infrastation at yandex.ru
Mon Jun 17 20:31:54 BST 2013


11.06.2013, 12:57, "Lokesh Pareta" <lokesh.pareta at tcs.com>:
> Hi Denis,
>
> Thanks for you feedback. In response to your suggestion, we require more inputs on following points:
>
> *  "It is possible to see that these prior works establish and use a common internal API to cryptographic hash algorithms implemented in a library, libgcrypt in this case. This approach provides agility without the cost of duplicating and maintaining the source code of each hash algorithm in use. Agility matters within the scope of this work, because RFC6506 sets SHA-256 as the mandatory-to-implement, but not the only possible hash algorithm. The contents of sha256.c and sha256.h together with much of the code in ospf6_check_sha256_digest() and ospf6_make_sha256_digest(), which implement the construct specified in RFC6506 (and derived from RFC4822), can be replaced with a call to hash_key_compress_rfc4822() and hash_make_hmac()."
>
> TCS inference -  The functions hash_key_compress_rfc4822() and hash_make_hmac() are present in the code downloaded from the link as suggested , but were not present in original code of quagga-0.99.21(as downloaded from quagga site before our implementation started) and even in current available version quagga-0.99.22. Kindly confirm whether this code piece (hash_key_compress_rfc4822() , hash_make_hmac() and libgcrypt) is in process of inclusion in upcoming version of quagga so that it can be used directly in RFC-6506 implementation. If not, kindly suggest  further steps so as to proceed with the implementation.
>

Hi Lokesh.

Your concern above is very clear, but some things are beyond my responsibility. That is, everyone is in their right to decide whether their version of Quagga includes or not the works I (or anybody else) occasionally contribute.

As a subscriber to this mailing list I can share some expertise on authentication and/or the source code I have authored, but for the rest you would have to make your own judgement. All that said, I really appreciate your will to implement modern specifications and contribute back to Free Software.

> * "ospf6_make_sha256_digest() would default to an empty string key when authentication is configured without any keys".
>
> TCS inference – CLI has been retested. In CLI, for ospf6d daemon, while entering command "ipv6 opspf6 sha-256-key <key-value> sha-256 <password> ", when user tries to enter empty <key-value> or <password>,  it returns an error message "Command incomplete" . Thus authentication without any keys is not possible.
>

No doubt I may be wrong here, but then the code shouldn't allow for two execution branches:

+  if (list_isempty (oi->auth_crypt))
+    auth_key = (const u_int8_t *) "";
+  else
+    {
+      ck = listgetdata (listtail(oi->auth_crypt));
+      auth_key = ck->auth_key;
+    }

-- 
 Denis Ovsienko




More information about the Quagga-dev mailing list