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

Jyotsna Priya1 jyotsna.priya1 at tcs.com
Fri Jul 12 07:12:04 BST 2013


 Hi All, 
  
 Based on the feedbacks received, some modifications have been done in RFC-6506 implementation. The changes are listed below: 
  The         implementation now supports sha-1, sha-256, sha-384 and sha-512         algorithms. The hash algorithm implementation (in files cryptohash.c         and cryptohash.h) is taken from          https://github.com/Quagga-RE/quagga-RE/wiki/hashes. This is done by         Denis Ovsienko. 
          
         The         CLI syntax has been changed as it now supports above mentioned hash         algorithms. 
          
         The         configuration and operation of the authentication mechanism now done         per interface and the per area extension is omitted. 
          
         The         logic of sequence number check in ospf6_check_sha256_digest() is         taken from OSPFv2 that is a counterpart version of OSPFv3 and it has         not rejected any valid packet so far.
                  Following         lines which were for default empty key, has been removed
         if         (list_isempty (oi->auth_crypt)) 
+ auth_key = (const u_int8_t         *) "";          
                  Changes         in ospf6_packet_examin has been done and it now doesn't check for         authenticity but it does check for size of packets with         authentication. The packets that are received with authentication         have authentication trailer attached with them which increases         packet size. Similar logic has been used in counterpart version         OPSFv2.
                  The         keychain mechanism used is similar to OPSFv2 md5 keychain mechanism.
                  The         stylistic issues have been removed.The patch files attached are:
- Patch file for lib directory 
- Patch file for CLI part 
- Patch file for OSPF implementation 
- Patch file of whole project 

Thanks and Regards
Jyotsna Priya
Telecom Technology - NextGen R&D,
Tata Consultancy Services

To: Lokesh Pareta <lokesh.pareta at tcs.com>
From: Denis Ovsienko <infrastation at yandex.ru>
Date: 06/18/2013 01:03AM
cc: quagga-dev at lists.quagga.net
Subject: Re: [quagga-dev 10527] RFC-6506(Supporting Authentication Trailer for OSPFv3) implementation in quagga-0.99.21 version

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 &#8211; 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 
 
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20130712/342d33f0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RFC6506_Lib.patch
Type: application/octet-stream
Size: 13831 bytes
Desc: not available
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20130712/342d33f0/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RFC6506_CLI.patch
Type: application/octet-stream
Size: 9786 bytes
Desc: not available
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20130712/342d33f0/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RFC6506_Implementation.patch
Type: application/octet-stream
Size: 32763 bytes
Desc: not available
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20130712/342d33f0/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RFC6506.patch
Type: application/octet-stream
Size: 69548 bytes
Desc: not available
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20130712/342d33f0/attachment-0007.obj>


More information about the Quagga-dev mailing list