<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 & Regards<br>Jyotsna
Priya<br>Telecom Technology,<br>NextGen R&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 <jyotsna.priya1@tcs.com>, "quagga-dev@lists.quagga.net" <quagga-dev@lists.quagga.net><br>From: Denis Ovsienko <infrastation@yandex.ru><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.
[...]
> 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.
>
[...]
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->router_id, oi);
+ if (on && ntohl(on->low_order_seqnum) > ntohl(ospf6_at->low_order_seqnum))
+ {
+ zlog_warn ("interface %s: ospf6_check_sha bad Low-order-sequence %d (expect %d)",
+ oi->interface->name,
+ ntohl(ospf6_at->low_order_seqnum),
+ ntohl(on->ospf6_if->low_order_seqnum));
+ return 0;
+ }
+
+ if (on && ntohl(on->high_order_seqnum) > ntohl(ospf6_at->high_order_seqnum))
+ {
+ zlog_warn ("interface %s: ospf6_check_sha bad High-order-sequence %d (expect %d)",
+ oi->interface->name,
+ ntohl(ospf6_at->high_order_seqnum),
+ ntohl(on->ospf6_if->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>