[quagga-dev 10609] Re: RFC-6506(Supporting Authentication Trailer for OSPFv3) implementation in quagga-0.99.21 version
jyotsna.priya1 at tcs.com
Thu Jul 18 06:05:29 BST 2013
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:
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.
TCS Towers (GG3),
-----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...
More information about the Quagga-dev