Re: OSPFv3 Destination Address Filter

["Naidu, Venkata" <[e-mail]>]

Hi Acee,

-> We've implemented the subject draft to mitigate some of the
-> OSPFv3 vulnerabilities. While the solution isn't perfect, it is
-> lightweight, easy to deploy, and fully compatible with the current
-> OSPFv3 specification (RFC 2740).
->
-> http://www.ietf.org/internet-drafts/draft-lindem-ospfv3-dest-
-> filter-00.txt

  After a quick look, here are few comments:

  1. Check should be:
      if (((first-two-octets & 0xffc0) != 0xfe80) &&
      <<<<
          ((first-two-octets & 0xff0f) != 0xff02)) {
      ====
          ((first-two-octets & 0xffff) != 0xff02)) {
      >>>>
          drop the packet;
      }

     I think, OSPFv3 SHOULD work on permanently flagged multicast
     addresses not with T flag on'ed ones.

  2. The draft reads:

       The granularity of the check will limit the usage of virtual
       links at the granularity which it is applied. For example, if
       it is applied at the BSD socket level, virtual links may not
       be used by any OSPF instance utilizing that socket.
       Alternately, additional configuration and checking could be
       added at the socket level so that the destination filter is
       only applied to certain instances, areas, or interfaces.

    There is another way to support what this draft does with out
    loss of generality. If these checks are applied at the Raw-IPv6
    stack level (using local address binding socket options)
    virtual link support will not be jeopardized.

    Doing below steps will solve DOS attack for IPv4 applications
    (i.e., OSPFv2, RSVP-TE etc) and IPv6 applications (i.e., OSPFv3
    etc.) - at least for the ones which operate on per interface
    basis.

    1. Bind to the local interface (either using link-layer address/
       ifindex) and make it strong-end socket. That is the socket
       will accept incoming packets only from the binded interface.

    2. Listen only for appropriate multicast address groups using
       various MULTICAST socket options. This will make sure the
       above checks are done at the Raw-IP level instead of at the
       OSPF level.

    3. Open another INADDR_ANY socket ONLY when virtual links are
       operational. Note that, this socket will receive all types
       of OSPF packets. But, that is fine, OSPF will anyway make
       sure (have to make sure) validity of every packet received
       on this socket.

   It is a good idea to enhance socket APIs to have filters based
   on list of IP addresses instead of all-or-one (i.e., multiple
   bindings like). May be, Bill Fenner can answer why it is not
   incorporated in IPv6 at least. I expected this in his recent
   Book. :)

Venakta.