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

Jyotsna Priya1 jyotsna.priya1 at tcs.com
Mon Jul 29 12:56:06 BST 2013


 Hi All,
  Based on the previous feedback, following changes have been done in the RFC-6506 implementation:
  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                                         
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.
  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).(Refer         to Section 3, page 7 of RFC-6506)                                      P { margin-bottom: 0.08in; }   

The patch files are attached with this mail.
  
                                      P { margin-bottom: 0.08in; }                                         P { margin-bottom: 0.08in; }   
                                      P { margin-bottom: 0.08in; }   Thanks & Regards
Jyotsna Priya
Telecom Technology,
NextGen R&D,
Tata Consultancy Services
  
-----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/18/2013 12:33PM
Subject: [quagga-dev 10610] Re: RFC-6506(Supporting Authentication Trailer        for OSPFv3) implementation in quagga-0.99.21 version

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 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/20130729/a04630a9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RFC6506.patch
Type: application/octet-stream
Size: 70224 bytes
Desc: not available
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20130729/a04630a9/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RFC6506_CLI.patch
Type: application/octet-stream
Size: 10460 bytes
Desc: not available
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20130729/a04630a9/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RFC6506_implementation.patch
Type: application/octet-stream
Size: 44001 bytes
Desc: not available
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20130729/a04630a9/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RFC6506_lib.patch
Type: application/octet-stream
Size: 13811 bytes
Desc: not available
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20130729/a04630a9/attachment-0007.obj>


More information about the Quagga-dev mailing list