[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OSPFv3 Destination Address Filter
Hi Venkata,
Are you talking about a socket per interface ?
Thanks
Anand
"Naidu, Venkata" wrote:
>
> 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.