< draft-lindem-ospfv3-dest-filter-01.txt   draft-lindem-ospfv3-dest-filter-02.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: Sept 2004 Expiration Date: Oct 2004
File name: draft-lindem-ospfv3-dest-filter-01.txt Apr 2004 File name: draft-lindem-ospfv3-dest-filter-02.txt May 2004
OSPFv3 Destination Address Filter OSPFv3 Destination Address Filter
draft-lindem-ospfv3-dest-filter-01.txt draft-lindem-ospfv3-dest-filter-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or IPR claims of which I am aware have been disclosed, and
any of which I become aware will be disclosed, in accordance with
RFC 3668.
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.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
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. However, this level of protection with the existing OSPFv3 behavior. However, this level of
will preclude the deployment of virtual links in topologies where protection will preclude the deployment of virtual links in
the filtering is applied. topologies where 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
4 RIPng Applicabilty ..................................... 3 4 RIPng Applicabilty ..................................... 4
5 Security Considerations ................................ 4 5 Security Considerations ................................ 4
6 Intellectual Property .................................. 4 6 Intellectual Property .................................. 4
7 Normative References ................................... 4 7 Normative References ................................... 5
8 Informative References ................................. 5 8 Informative References ................................. 5
9 Acknowledgments ........................................ 5 9 Acknowledgments ........................................ 6
10 Authors' Addresses ..................................... 5 10 Authors' Addresses ..................................... 6
1. Overview 1. Overview
OSPFv2 [OSPFv2] and OSPFv3 [OSPFv3] both have been criticised for OSPFv2 [OSPFv2] and OSPFv3 [OSPFv3] both have been criticised for
their vulnerability to Denial of Service attacks [VULNER]. Both their vulnerability to Denial of Service attacks [VULNER]. Both
support cryptographic authentication to prevent an attacker from support cryptographic authentication to prevent an attacker from
being able to spoof an OSPFv2 or OSPFv3 packet ([OSPFv2] and being able to spoof an OSPFv2 or OSPFv3 packet ([OSPFv2] and
[AUTHv3]). However, in many cases the MD5 or IPSEC protection [AUTHv3]). However, in many cases the MD5 or IPSEC protection
actually exacerbates the attack due to the computational overhead actually exacerbates the attack due to the computational overhead
involved. For OSPFv3, this document proposes limiting accepted involved. For OSPFv3, this document proposes limiting accepted
OSPFv3 packets to those that are not routable. Doing so allows OSPFv3 packets to those that are not routable. Doing so allows
these packets to be filtered at a low level for a relatively these packets to be filtered at a low level for a relatively
small computational cost. small computational cost.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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 OSPFv3 compatible with the OSPFv3 which doesn't specify that OSPFv3
packets be sent with a hop limit of 255. The only hop limit packets be sent with a hop limit of 255. The only hop limit
specification is that the link-scoped multicast packets are specification is that the link-scoped multicast packets are
sent with a hop limit of 1. Hence, this mechanism can be deployed sent with a hop limit of 1. Hence, this mechanism 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 Alternately, an implementation may also check the multicast address
flags to assure they are 0x0 since the OSPFv3 specification flags to assure they are 0x0 since the OSPFv3 specification
explicitly uses multicast addresses ff02::5 (AllSPFRouters) and explicitly uses multicast addresses ff02::5 (AllSPFRouters) and
ff02::6 (AllDRrouters) [OSPFv3]. ff02::6 (AllDRrouters) [OSPFv3].
if (((first-two-octets & 0xffc0) != 0xfe80) && if (((first-two-octets & 0xffc0) != 0xfe80) &&
((first-two-octets & 0xffff) != 0xff02)) { ((first-two-octets & 0xffff) != 0xff02)) {
drop the packet; 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 proposed 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
necessary for the destination filter to be applied after OSPF necessary for the destination filter to be applied after OSPF
packets are delivered to the tunnel endpoint and decapsulated. packets are delivered to the tunnel endpoint and decapsulated.
Furthermore, the encapsulated OSPFv3 packet's destination Furthermore, the encapsulated OSPFv3 packet's destination
address should be AlllSPFRouters (FF02::5). address should be AlllSPFRouters (FF02::5).
3.0 Implementation Placement and Granularity of Filter 3.0 Implementation Placement and Granularity of Filter
The placement and granularity of the destination address filter The placement and granularity of the destination address filter
is an engineering decision that must be made for each is an engineering decision that must be made for each
implementation. Obviously, the sooner it is done after packet implementation. Obviously, the sooner it is done after packet
reception the less resource that is consumed processing packets reception the less resource that is consumed processing packets
that will be dropped. However, since the checking has to be that will be dropped. However, since the checking has to be
confined to OSPFv3 packets that are delivered locally it may be confined to OSPFv3 packets that are delivered locally it may be
easier to delay the checking until the packets have been identified easier to delay the checking until the packets have been identified
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. Implementations 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
requirement to send to IPv6 global addresses. requirement to send to IPv6 global addresses.
5. Security Considerations 5. Security Considerations
This document recommends a mechanism that can be used to limit This document recommends a mechanism that can be used to limit
OSPFv3 Denial of Service (DOS) attacks to directly attached networks. OSPFv3 Denial of Service (DOS) attacks to directly attached networks.
Hence, the entire document deals with security. Hence, the entire document deals with security.
6. Intellectual Property 6. Intellectual Property
skipping to change at page 4, line 40 skipping to change at page 5, line 12
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
7. Normative References 7. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFC's to Indicate [RFC-2119] Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1977. Requirement Levels", BCP 14, RFC 2119, March 1977.
[OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[OSPFv3] Coltun, R., Ferguson, D. and Moy, J., [OSPFv3] Coltun, R., D. Ferguson, and J. Moy,
"OSPF for IPv6", RFC 2740, December 1999. "OSPF for IPv6", RFC 2740, December 1999.
[ADDR-ARCH] Hinden, R. and Deering, S., [ADDR-ARCH] Hinden, R. and S. Deering,
"IP Version 6 Addressing Architecture", "IP Version 6 Addressing Architecture",
RFC 3513, April 2003. RFC 3513, April 2003.
[SOCKET] Gilligan, B., Thomson, S., Bound, J., McCann, J. [SOCKET] Gilligan, B., S. Thomson, J. Bound, J. McCann,
and Stevens, R., "Basic Socket Interface Extensions and R. Stevens, "Basic Socket Interface Extensions
for IPv6", RFC 3493, February 2003. for IPv6", RFC 3493, February 2003.
[RIPng] Malkin, G. and Minnear, R., "RIPng for IPv6", [RIPng] Malkin, G. and R. Minnear, "RIPng for IPv6",
RFC 2080, January 1997. RFC 2080, January 1997.
8. Informative References 8. Informative References
[GTSM] Gill, V., Heasley, J., and Meyer, D., [GTSM] Gill, V., J. Heasley, and D. Meyer,
The Generalized TTL Security Mechanism (GTSM) The Generalized TTL Security Mechanism (GTSM)
drdraft-gill-gtsh-04.txt, Work in progress. drdraft-gill-gtsh-04.txt, Work in progress.
[AUTHv3] Gupta, M. and Melam, N., [AUTHv3] Gupta, M. and N. Melam,
"Authentication/Confidentiality for OSPFv3", "Authentication/Confidentiality for OSPFv3",
draft-ietf-ospf-ospfv3-auth-04.txt, Work in progress. draft-ietf-ospf-ospfv3-auth-04.txt, Work in progress.
[VULNER] Jones, E. and Le Moigne, O., [VULNER] Jones, E. and O. Le Moigne,
"OSPF Security Vulnerabilities Analysis", "OSPF Security Vulnerabilities Analysis",
draft-jones-ospf-vuln-01.txt, Work in progress. draft-jones-ospf-vuln-01.txt, Work in progress.
[GRE] Farinacci, D., Li, T., Hanks, S., Meyer, D. and [GRE] Farinacci, D., T. Li, S. Hanks, D. Meyer, and
Traina, P., "Generic Routing Encapsulation (GRE)", P. Traina, "Generic Routing Encapsulation (GRE)",
RFC 2784, March 2000. RFC 2784, March 2000.
9. Acknowledgments 9. Acknowledgments
The authors wish to acknowledge Enke Chen and George Apostolopoulos The authors wish to acknowledge Mukesh Gupta, Venkata Naidu,
for their thorough review. Enke Chen, and George Apostolopoulos for their review and
comments.
10. Authors' Addresses 10. Authors' Addresses
Acee Lindem Acee Lindem
Redback Networks Redback Networks
102 Carric Bend Court 102 Carric Bend Court
Cary, NC 27519 Cary, NC 27519
Email: acee@redback.com Email: acee@redback.com
Anand Oswal Anand Oswal
 End of changes. 32 change blocks. 
46 lines changed or deleted 49 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/