[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OSPFv3 Destination Address Filter
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.