<font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2"> <p style="margin-bottom: 0in"><font face="Liberation Serif, serif"><font size="2">Hi
Denis, </font></font>
</p>

<p style="margin-bottom: 0in"><font face="Liberation Serif, serif"><font size="2">Thanks
for the response. </font></font>
</p>
<p style="margin-bottom: 0in"><font face="Liberation Serif, serif"><font size="2">The
answers to the raised points were mentioned in my previous mail. To
make it more clear I'm writing it as follows:</font></font></p>
<p style="margin-bottom: 0in"><br>
</p>
<table cellpadding="4" cellspacing="0" width="100%">
        <colgroup><col width="128*">
        <col width="128*">
        </colgroup><tbody><tr valign="TOP">
                <td style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0.04in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0in" width="50%">
                        <p><font face="Liberation Serif, serif"><font size="2"><b>Point
                        Raised</b></font></font></p>
                </td>
                <td style="border: 1px solid #000000; padding: 0.04in" width="50%">
                        <p><font face="Liberation Serif, serif"><font size="2"><b>Comment</b></font></font></p>
                </td>
        </tr>
        <tr valign="TOP">
                <td style="border-top: none; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0in" width="50%">
                        <p style="font-weight: normal"><font face="Liberation Serif, serif"><font size="2">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().</font></font></p>
                        <p style="font-weight: normal"><font face="Liberation Serif, serif"><font size="2">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).</font></font></p>
                        <p><br>
                        </p>
                </td>
                <td style="border-top: none; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; padding-top: 0in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0.04in" width="50%">
                        <p><font face="Liberation Serif, serif"><font size="2">Done</font></font></p>
                </td>
        </tr>
        <tr valign="TOP">
                <td style="border-top: none; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0in" width="50%">
                        <p><font face="Liberation Serif, serif"><font size="2">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.</font></font></p>
                </td>
                <td style="border-top: none; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; padding-top: 0in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0.04in" width="50%">
                        <p><font face="Liberation Serif, serif"><font size="2">Done</font></font></p>
                </td>
        </tr>
        <tr valign="TOP">
                <td style="border-top: none; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0in" width="50%">
                        <p style="font-weight: normal"><font face="Liberation Serif, serif"><font size="2">The
                        sequence number check in ospf6_check_sha256_digest() is taken
                        wrong and will reject valid packets.</font></font></p>
                </td>
                <td style="; border-top: none; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; padding-top: 0in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0.04in" width="50%">
                        <p style="font-weight: normal"><font face="Liberation Serif, serif"><font size="2">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.</font></font></p>
                </td>
        </tr>
        <tr valign="TOP">
                <td style="; border-top: none; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0in" width="50%">
                        <p><font face="Liberation Serif, serif"><font size="2">ospf6_make_sha256_digest()
                        would default to an empty string key when authentication is
                        configured without any keys.</font></font></p>
                </td>
                <td style="border-top: none; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; padding-top: 0in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0.04in" width="50%">
                        <p><font face="Liberation Serif, serif"><font size="2">The lines
                        that you mentioned have been removed</font></font></p>
                </td>
        </tr>
        <tr valign="TOP">
                <td style="border-top: none; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0in" width="50%">
                        <p style="font-weight: normal"><font face="Liberation Serif, serif"><font size="2">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.</font></font></p>
                        <p><br>
                        </p>
                </td>
                <td style="border-top: none; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; padding-top: 0in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0.04in" width="50%">
                        <p style="font-weight: normal"><font color="#000000"><font face="Liberation Serif, serif"><font size="2">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.</font></font></font></p>
                </td>
        </tr>
        <tr valign="TOP">
                <td style="; border-top: none; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0in" width="50%">
                        <p><font face="Liberation Serif, serif"><font size="2">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.</font></font></p>
                </td>
                <td style="border-top: none; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; padding-top: 0in; padding-bottom: 0.04in; padding-left: 0.04in; padding-right: 0.04in" width="50%">
                        <p style="font-weight: normal"><font color="#000000"><font face="Liberation Serif, serif"><font size="2">The
                        keychain mechanism used is similar to ospfv2 md5 keychain
                        mechanism.</font></font></font></p></td></tr></tbody></table><br>Regards<br>Jyotsna Priya<br>NextGen R&amp;D,<br>TCS Towers (GG3),<br>Gurgaon, Haryana<br><br><font color="#990099">-----Denis Ovsienko <infrastation@yandex.ru> wrote: -----</infrastation@yandex.ru></font><div><blockquote style="padding-right:0px;padding-left:5px;margin-left:5px;border-left:solid black 2px;margin-right:0px">To: Jyotsna Priya1 &lt;jyotsna.priya1@tcs.com&gt;, "quagga-dev@lists.quagga.net" &lt;quagga-dev@lists.quagga.net&gt;<br>From: Denis Ovsienko &lt;infrastation@yandex.ru&gt;<br>Date: 07/17/2013 04:28PM<br>Subject: [quagga-dev 10608] Re: RFC-6506(Supporting Authentication Trailer        for OSPFv3) implementation in quagga-0.99.21 version<br><br><pre>12.07.2013, 10:12, "Jyotsna Priya1" &lt;jyotsna.priya1@tcs.com&gt;:
&gt; Hi All,
&gt;
&gt; 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@lists.quagga.net
<a href="http://lists.quagga.net/mailman/listinfo/quagga-dev">http://lists.quagga.net/mailman/listinfo/quagga-dev</a>
</pre></blockquote></div><div></div></font><p>=====-----=====-----=====<br>
Notice: The information contained in this e-mail<br>
message and/or attachments to it may contain <br>
confidential or privileged information. If you are <br>
not the intended recipient, any dissemination, use, <br>
review, distribution, printing or copying of the <br>
information contained in this e-mail message <br>
and/or attachments to it are strictly prohibited. If <br>
you have received this communication in error, <br>
please notify us by reply e-mail or telephone and <br>
immediately and permanently delete the message <br>
and any attachments. Thank you</p>

<p></p>