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

<p style="margin-bottom: 0in"><font face="Liberation Serif, serif"><font size="3">Based
on the previous feedback, following changes have been done in the
RFC-6506 implementation:</font></font></p>

<ol><li><p style="margin-bottom: 0in"><font face="Liberation Serif, serif"><font size="3">The
        code for Sequence number check has been slightly modified and now it
        doesn't violates the specification in the scenarios as given by
        Denis</font></font>


        
        
        
        


</p><p style="margin-bottom: 0in"><font face="Courier New, Courier, monospace"><font size="2">1)
Saved sequence number is 0x00000001:00000001 (high:low). The packet
has sequence number 0x00000001:00000001.<br>Saved low-order is
greater than packet's low-order? No. Saved high-order is greater than
packet's high-order? No.<br>The code continues processing a replayed
packet.<br><br>2) Saved sequence number is 0x00000001:ffffffff
(high:low). The packet has sequence number 0x00000002:00000000.<br>Saved
low-order is greater than packet's low-order? Yes.<br>The code
rejects a packet that has a valid sequence number.</font></font></p>

</li><li><p style="margin-bottom: 0in"><font face="Liberation Serif, serif"><font size="3">The key mechanism is slightly changed. Now length of the key depends on the
        authentication algorithm being used and not sha512 only (which is maximum).</font></font></p><font face="Liberation Serif, serif"><font size="3">(Refer
        to Section 3, page 7 of RFC-6506)</font></font></li></ol></font><font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2">


        
        
        
        <style type="text/css">P { margin-bottom: 0.08in; }</style>


</font><p style="line-height: 100%"><font face="Liberation Serif, serif"><font size="3"><br></font></font></p><p style="line-height: 100%"><font face="Liberation Serif, serif"><font size="3">The
patch files are attached with this mail.</font></font></p>

<font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2"><br>


        
        
        
        <style type="text/css">P { margin-bottom: 0.08in; }</style>


<p style="margin-bottom: 0in">


        
        
        
        <style type="text/css">P { margin-bottom: 0.08in; }</style>


</p>


        
        
        
        <style type="text/css">P { margin-bottom: 0.08in; }</style>


<p style="line-height: 100%"><font face="Liberation Serif, serif"><font size="3">Thanks &amp; Regards<br>Jyotsna
Priya<br>Telecom Technology,<br>NextGen R&amp;D,<br>Tata Consultancy
Services</font></font></p>

<br><font color="#990099">-----Denis Ovsienko <!--Notes ACF
<infrastation@yandex.ru>--> wrote: -----<!--Notes ACF
</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/18/2013 12:33PM<br>Subject: [quagga-dev 10610] Re: RFC-6506(Supporting Authentication Trailer        for OSPFv3) implementation in quagga-0.99.21 version<br><br><pre>Hello.

Please see below for an explanation of one of the points.

[...]
&gt; The sequence number check in ospf6_check_sha256_digest() is taken wrong and will reject valid packets.
&gt;
&gt; 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.
&gt;
[...]

The sequence number in RFC5709 (OSPFv2) is a 32-bit non-decreasing function. The sequence number in RFC6506 (OSPFv3) is a 64-bit strictly increasing function. The code in the patch is:

+   /* Check crypto seqnum. As done in ospfv2*/
+   on = ospf6_neighbor_lookup (oh-&gt;router_id, oi);
+   if (on &amp;&amp; ntohl(on-&gt;low_order_seqnum) &gt; ntohl(ospf6_at-&gt;low_order_seqnum))
+   {
+      zlog_warn ("interface %s: ospf6_check_sha bad Low-order-sequence %d (expect %d)",
+      oi-&gt;interface-&gt;name,
+      ntohl(ospf6_at-&gt;low_order_seqnum),
+          ntohl(on-&gt;ospf6_if-&gt;low_order_seqnum));
+      return 0;
+    }
+
+    if (on &amp;&amp; ntohl(on-&gt;high_order_seqnum) &gt; ntohl(ospf6_at-&gt;high_order_seqnum))
+    {
+      zlog_warn ("interface %s: ospf6_check_sha bad High-order-sequence %d (expect %d)",
+          oi-&gt;interface-&gt;name,
+          ntohl(ospf6_at-&gt;high_order_seqnum),
+          ntohl(on-&gt;ospf6_if-&gt;high_order_seqnum));
+      return 0;
+    }

Consider two following scenarios where this code violates the specification:

1. Saved sequence number is 0x00000001:00000001 (high:low). The packet has sequence number 0x00000001:00000001.
Saved low-order is greater than packet's low-order? No. Saved high-order is greater than packet's high-order? No.
The code continues processing a replayed packet.

2. Saved sequence number is 0x00000001:ffffffff (high:low). The packet has sequence number 0x00000002:00000000.
Saved low-order is greater than packet's low-order? Yes.
The code rejects a packet that has a valid sequence number.

Thank you.

-- 
 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></font></font>
<div id="MIMEAttachInfoDiv" style="display:none" title="octet-stream|RFC6506.patch"></div><div id="MIMEAttachInfoDiv" style="display:none" title="octet-stream|RFC6506_CLI.patch"></div><div id="MIMEAttachInfoDiv" style="display:none" title="octet-stream|RFC6506_implementation.patch"></div><div id="MIMEAttachInfoDiv" style="display:none" title="octet-stream|RFC6506_lib.patch"></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>