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

Jyotsna Priya1 jyotsna.priya1 at tcs.com
Thu Jul 18 06:05:29 BST 2013

 Hi Denis,  
  Thanks for the response.  
 The answers to the raised points were mentioned in my previous mail. To make it more clear I'm writing it as follows:
  	 	 	 		 			Point 			Raised
 		  	 	 		 			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().
 			Respectively, 			it makes sense to review the CLI syntax of the RFC6506 patch to 			reflect SHA-256 as just a particular case of the cryptographic 			authentication (see CLI syntax of the two implementations above 			for an example).
 		  	 	 		 			As a related 			point, in the patch authentication is configured not only per 			interface but also per area. RFC6506 defines configuration and 			operation of the authentication mechanism per interface and it 			seems reasonable to omit the per area extension until the basic 			per interface code is completed.
 		  	 	 		 			The 			sequence number check in ospf6_check_sha256_digest() is taken 			wrong and will reject valid packets.
 		  		 			The 			logic is taken from ospfv2 in quagga-0.99.21 which is a 			counterpart version of ospfv3 and it has not rejected any valid 			packet so far.
 		  	 	 		 			ospf6_make_sha256_digest() 			would default to an empty string key when authentication is 			configured without any keys.
 		  		 			The lines 			that you mentioned have been removed
 		  	 	 		 			Many 			of the changes to ospf6_packet_examin() don't belong there, the 			purpose of that function is to validate packet framing, but not 			the authenticity. This should be better seen looking at the 			counterpart xxx_examin() functions and respective authentication 			layer of ospfd and (especially) ripd.
 		  		 			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 			ospfv2.
 		  	 	 		 			The set of 			authentication key management functions added to ospf6_interface 			module doesn't look as good as the existing functions of 			lib/keychain module.
 		  		 			The 			keychain mechanism used is similar to ospfv2 md5 keychain 			mechanism.
Jyotsna Priya
NextGen R&D,
TCS Towers (GG3),
Gurgaon, Haryana

-----Denis Ovsienko  wrote: -----
To: Jyotsna Priya1 <jyotsna.priya1 at tcs.com>, "quagga-dev at lists.quagga.net" <quagga-dev at lists.quagga.net>
From: Denis Ovsienko <infrastation at yandex.ru>
Date: 07/17/2013 04:28PM
Subject: [quagga-dev 10608] Re: RFC-6506(Supporting Authentication Trailer	for OSPFv3) implementation in quagga-0.99.21 version

12.07.2013, 10:12, "Jyotsna Priya1" <jyotsna.priya1 at tcs.com>: > Hi All, > > Based on the feedbacks received, some modifications have been done in RFC-6506 implementation. The changes are listed below:  [...]  Hello.  This revision is notably cleaner, but most of the previously raised points still apply, can you review?  --   Denis Ovsienko  _______________________________________________ Quagga-dev mailing list Quagga-dev at lists.quagga.net http://lists.quagga.net/mailman/listinfo/quagga-dev 
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/20130718/025a8919/attachment-0001.html>

More information about the Quagga-dev mailing list