< draft-lindem-ospfv3-dest-filter-00.txt   draft-lindem-ospfv3-dest-filter-01.txt >
Network Working Group Acee Lindem (Redback Networks) Network Working Group Acee Lindem (Redback Networks)
Internet Draft Anand Oswal (Redback Networks) Internet Draft Anand Oswal (Redback Networks)
Expiration Date: July 2004 Expiration Date: Sept 2004
File name: draft-lindem-ospfv3-dest-filter-00.txt Feb 2004 File name: draft-lindem-ospfv3-dest-filter-01.txt Apr 2004
OSPFv3 Destination Address Filter OSPFv3 Destination Address Filter
draft-lindem-ospfv3-dest-filter-00.txt draft-lindem-ospfv3-dest-filter-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
OSPFv2 has been criticized for it vulnerability to Denial of OSPFv2 has been criticized for it vulnerability to Denial of
Service (DOS) attacks. With OSPFv3, it is a simple matter to filter Service (DOS) attacks. With OSPFv3, it is a simple matter to filter
on the destination address at an implementation dependent level on the destination address at an implementation dependent level
in order to limit the scope of DOS attacks to directly attached in order to limit the scope of DOS attacks to directly attached
routers. Unlike hop limit checking mechanisms, it is compatible routers. Unlike hop limit checking mechanisms, it is compatible
with the existing OSPFv3 behavior. Howevr, this level of protection with the existing OSPFv3 behavior. However, this level of protection
will preclude the deployment of virtual links in topologies where will preclude the deployment of virtual links in topologies where
the filtering is applied. the filtering is applied.
Table of Contents Table of Contents
1 Overview ............................................... 2 1 Overview ............................................... 2
2 Proposed Solution ...................................... 2 2 Proposed Solution ...................................... 2
2.1 Virtual Links .......................................... 3 2.1 Virtual Links .......................................... 3
2.2 Tunnels ................................................ 3 2.2 Tunnels ................................................ 3
3 Implementation and Granularity of Filter ............... 3 3 Implementation and Granularity of Filter ............... 3
skipping to change at page 2, line 30 skipping to change at page 2, line 30
document are to be interpreted as described in [RFC-2119]. document are to be interpreted as described in [RFC-2119].
2. Proposed Solution 2. Proposed Solution
In order to limit the vulnerability to DOS attacks to directly In order to limit the vulnerability to DOS attacks to directly
attached routers, OSPFv3 packets are only accepted if the attached routers, OSPFv3 packets are only accepted if the
destination address in the packet header is a link-local unicast destination address in the packet header is a link-local unicast
address or link-local scoped multicast address. Both these address address or link-local scoped multicast address. Both these address
types are never forwarded more than one hop. Unlike hop limit types are never forwarded more than one hop. Unlike hop limit
checking mechanisms [GTSM], this technique is fully backward checking mechanisms [GTSM], this technique is fully backward
compatible with the OSPFv3 which doesn't specify that that compatible with the OSPFv3 which doesn't specify that OSPFv3
OSPFv3 packets be sent with a hop limit of 255. The only hop packets be sent with a hop limit of 255. The only hop limit
limit specification is that the link-scoped multicast packets specification is that the link-scoped multicast packets are
are sent with a hop limit of 1. Hence, this mechanism sent with a hop limit of 1. Hence, this mechanism can be deployed
can be deployed on one OSPFv3 router at a time. on one OSPFv3 router at a time.
In order to make the checking simple and low cost, this document In order to make the checking simple and low cost, this document
suggests checking the first two octets of the IPv6 destination suggests checking the first two octets of the IPv6 destination
address for a valid link local unicast or link-local scoped address for a valid link local unicast or link-local scoped
multicast address. Based on the IPv6 Address Architecture multicast address. Based on the IPv6 Address Architecture
[ADDR-ARCH], this would equate to: [ADDR-ARCH], this would equate to:
if (((first-two-octets & 0xffc0) != 0xfe80) && if (((first-two-octets & 0xffc0) != 0xfe80) &&
((first-two-octets & 0xff0f) != 0xff02)) { ((first-two-octets & 0xff0f) != 0xff02)) {
drop the packet; drop the packet;
} }
Alternately, an implementation may also check the multicast address
flags to assure they are 0x0 since the OSPFv3 specification
explicitly uses multicast addresses ff02::5 (AllSPFRouters) and
ff02::6 (AllDRrouters) [OSPFv3].
if (((first-two-octets & 0xffc0) != 0xfe80) &&
((first-two-octets & 0xffff) != 0xff02)) {
drop the packet;
}
2.1 Virtual Links 2.1 Virtual Links
Virtual links make use of a global IPv6 unicast destination address. Virtual links make use of a global IPv6 unicast destination address.
Hence, the propsed destination address filter and virtual links are Hence, the propsed destination address filter and virtual links are
incompatible. Depending on the granularity of the filtering, incompatible. Depending on the granularity of the filtering,
virtual links may still be used (See Section 3.0). virtual links may still be used (See Section 3.0).
2.2 Tunnels 2.2 Tunnels
In order to support OSPF over tunnels, e.g. GRE [GRE], it is In order to support OSPF over tunnels, e.g. GRE [GRE], it is
skipping to change at page 3, line 39 skipping to change at page 3, line 39
as such. A conveinent place in an implementation using the BSD as such. A conveinent place in an implementation using the BSD
socket model [SOCKET] is the point at which an inbound packet socket model [SOCKET] is the point at which an inbound packet
is added to the OSPFv3 socket. is added to the OSPFv3 socket.
The granularity of the check will limit the usage of virtual The granularity of the check will limit the usage of virtual
links at the granularity which it is applied. For example, if it is 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 applied at the BSD socket level, virtual links may not be used
by any OSPF instance utilizing that socket. Alternately, additional by any OSPF instance utilizing that socket. Alternately, additional
configuration and checking could be added at the socket level so configuration and checking could be added at the socket level so
that the destination filter is only applied to certain instances, that the destination filter is only applied to certain instances,
areas, or interfaces. Implemenations will need to balance their areas, or interfaces. Implementations will need to balance their
market requirements for virtual link deployment. In any case, the market requirements for virtual link deployment. In any case, the
use of virtual link SHOULD be allowed either by configuration or use of virtual link SHOULD be allowed either by configuration or
the filter should be automatically disabled when a virtual link the filter should be automatically disabled when a virtual link
is configured. is configured.
4. RIPng Applicability 4. RIPng Applicability
The destination filter described herein is also applicable to The destination filter described herein is also applicable to
RIPng [RIPNG]. The filter simply needs to be applied to UDP port RIPng [RIPNG]. The filter simply needs to be applied to UDP port
521. In RIPng there is no concept of a virtual link and no 521. In RIPng there is no concept of a virtual link and no
 End of changes. 6 change blocks. 
10 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/