[RPSEC] Re: OSPFv3 Destination Address Filter

["Acee Lindem" <[e-mail]>]

----- Original Message ----- 
From: "Naidu, Venkata" <[e-mail]>
To: <[e-mail]>
Sent: Friday, February 27, 2004 5:59 PM
Subject: Re: OSPFv3 Destination Address Filter

Hi Venkata, 


> 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.

We used our IPv6 stack macro that checks for a link scoped multicast. 
It may be somewhat better to check the flags field as well since in the
case we envision usage non-zero flags will result in the  packet being
dropped anyway.  However, strictly speaking, one does not need
to check the flags in order to check for a link scoped IPv6 multicast 
address. I'll update either to allow both options or include the flag
dependent on which seems to fit better. 


> 
>   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. :)

One could certainly support virtual links with a separate socket. 
However, as long as a globally routable address is used, it is subject
to DOS attack and one would have to deal with substantially more
complexity in terms of perferring protect socket, etc. I don't like
#3 at all since my experience has been that OSPF scaling is I/O
bound and receiving a given OSPF packet on more than one
socket is not a good idea. If someone did want to do this I'd
think the separate socket would need to support a list of bind
addresses (one for each virtual link endpoint). However, IMHO,
virtual links aren't that widely deployed and administrative
ACLs can be used to protect OSPFv3 routers where they are
used. 




> 
> Venakta.

_______________________________________________
RPSEC mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rpsec