idnits 2.17.00 (12 Aug 2021) /tmp/idnits58762/draft-lindem-ospfv3-dest-filter-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 131 has weird spacing: '...packets have ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Apr 2004) is 6610 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RIPNG' is mentioned on line 151, but not defined == Unused Reference: 'RIPng' is defined on line 201, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2740 (ref. 'OSPFv3') (Obsoleted by RFC 5340) ** Obsolete normative reference: RFC 3513 (ref. 'ADDR-ARCH') (Obsoleted by RFC 4291) ** Downref: Normative reference to an Informational RFC: RFC 3493 (ref. 'SOCKET') == Outdated reference: draft-ietf-ospf-ospfv3-auth has been published as RFC 4552 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Acee Lindem (Redback Networks) 2 Internet Draft Anand Oswal (Redback Networks) 3 Expiration Date: Sept 2004 4 File name: draft-lindem-ospfv3-dest-filter-01.txt Apr 2004 6 OSPFv3 Destination Address Filter 7 draft-lindem-ospfv3-dest-filter-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 OSPFv2 has been criticized for it vulnerability to Denial of 33 Service (DOS) attacks. With OSPFv3, it is a simple matter to filter 34 on the destination address at an implementation dependent level 35 in order to limit the scope of DOS attacks to directly attached 36 routers. Unlike hop limit checking mechanisms, it is compatible 37 with the existing OSPFv3 behavior. However, this level of protection 38 will preclude the deployment of virtual links in topologies where 39 the filtering is applied. 41 Table of Contents 43 1 Overview ............................................... 2 44 2 Proposed Solution ...................................... 2 45 2.1 Virtual Links .......................................... 3 46 2.2 Tunnels ................................................ 3 47 3 Implementation and Granularity of Filter ............... 3 48 4 RIPng Applicabilty ..................................... 3 49 5 Security Considerations ................................ 4 50 6 Intellectual Property .................................. 4 51 7 Normative References ................................... 4 52 8 Informative References ................................. 5 53 9 Acknowledgments ........................................ 5 54 10 Authors' Addresses ..................................... 5 56 1. Overview 58 OSPFv2 [OSPFv2] and OSPFv3 [OSPFv3] both have been criticised for 59 their vulnerability to Denial of Service attacks [VULNER]. Both 60 support cryptographic authentication to prevent an attacker from 61 being able to spoof an OSPFv2 or OSPFv3 packet ([OSPFv2] and 62 [AUTHv3]). However, in many cases the MD5 or IPSEC protection 63 actually exacerbates the attack due to the computational overhead 64 involved. For OSPFv3, this document proposes limiting accepted 65 OSPFv3 packets to those that are not routable. Doing so allows 66 these packets to be filtered at a low level for a relatively 67 small computational cost. 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in [RFC-2119]. 73 2. Proposed Solution 75 In order to limit the vulnerability to DOS attacks to directly 76 attached routers, OSPFv3 packets are only accepted if the 77 destination address in the packet header is a link-local unicast 78 address or link-local scoped multicast address. Both these address 79 types are never forwarded more than one hop. Unlike hop limit 80 checking mechanisms [GTSM], this technique is fully backward 81 compatible with the OSPFv3 which doesn't specify that OSPFv3 82 packets be sent with a hop limit of 255. The only hop limit 83 specification is that the link-scoped multicast packets are 84 sent with a hop limit of 1. Hence, this mechanism can be deployed 85 on one OSPFv3 router at a time. 87 In order to make the checking simple and low cost, this document 88 suggests checking the first two octets of the IPv6 destination 89 address for a valid link local unicast or link-local scoped 90 multicast address. Based on the IPv6 Address Architecture 91 [ADDR-ARCH], this would equate to: 93 if (((first-two-octets & 0xffc0) != 0xfe80) && 94 ((first-two-octets & 0xff0f) != 0xff02)) { 95 drop the packet; 96 } 98 Alternately, an implementation may also check the multicast address 99 flags to assure they are 0x0 since the OSPFv3 specification 100 explicitly uses multicast addresses ff02::5 (AllSPFRouters) and 101 ff02::6 (AllDRrouters) [OSPFv3]. 103 if (((first-two-octets & 0xffc0) != 0xfe80) && 104 ((first-two-octets & 0xffff) != 0xff02)) { 105 drop the packet; 106 } 108 2.1 Virtual Links 110 Virtual links make use of a global IPv6 unicast destination address. 111 Hence, the propsed destination address filter and virtual links are 112 incompatible. Depending on the granularity of the filtering, 113 virtual links may still be used (See Section 3.0). 115 2.2 Tunnels 117 In order to support OSPF over tunnels, e.g. GRE [GRE], it is 118 necessary for the destination filter to be applied after OSPF 119 packets are delivered to the tunnel endpoint and decapsulated. 120 Furthermore, the encapsulated OSPFv3 packet's destination 121 address should be AlllSPFRouters (FF02::5). 123 3.0 Implementation Placement and Granularity of Filter 125 The placement and granularity of the destination address filter 126 is an engineering decision that must be made for each 127 implementation. Obviously, the sooner it is done after packet 128 reception the less resource that is consumed processing packets 129 that will be dropped. However, since the checking has to be 130 confined to OSPFv3 packets that are delivered locally it may be 131 easier to delay the checking until the packets have been identified 132 as such. A conveinent place in an implementation using the BSD 133 socket model [SOCKET] is the point at which an inbound packet 134 is added to the OSPFv3 socket. 136 The granularity of the check will limit the usage of virtual 137 links at the granularity which it is applied. For example, if it is 138 applied at the BSD socket level, virtual links may not be used 139 by any OSPF instance utilizing that socket. Alternately, additional 140 configuration and checking could be added at the socket level so 141 that the destination filter is only applied to certain instances, 142 areas, or interfaces. Implementations will need to balance their 143 market requirements for virtual link deployment. In any case, the 144 use of virtual link SHOULD be allowed either by configuration or 145 the filter should be automatically disabled when a virtual link 146 is configured. 148 4. RIPng Applicability 150 The destination filter described herein is also applicable to 151 RIPng [RIPNG]. The filter simply needs to be applied to UDP port 152 521. In RIPng there is no concept of a virtual link and no 153 requirement to send to IPv6 global addresses. 155 5. Security Considerations 157 This document recommends a mechanism that can be used to limit 158 OSPFv3 Denial of Service (DOS) attacks to directly attached networks. 159 Hence, the entire document deals with security. 161 6. Intellectual Property 163 The IETF takes no position regarding the validity or scope of any 164 intellectual property or other rights that might be claimed to 165 pertain to the implementation or use of the technology described in 166 this document or the extent to which any license under such rights 167 might or might not be available; neither does it represent that it 168 has made any effort to identify any such rights. Information on the 169 IETF's procedures with respect to rights in standards-track and 170 standards-related documentation can be found in BCP-11. Copies of 171 claims of rights made available for publication and any assurances of 172 licenses to be made available, or the result of an attempt made to 173 obtain a general license or permission for the use of such 174 proprietary rights by implementors or users of this specification can 175 be obtained from the IETF Secretariat. 177 The IETF invites any interested party to bring to its attention any 178 copyrights, patents or patent applications, or other proprietary 179 rights which may cover technology that may be required to practice 180 this standard. Please address the information to the IETF Executive 181 Director. 183 7. Normative References 185 [RFC-2119] Bradner, S., "Key words for use in RFC's to Indicate 186 Requirement Levels", BCP 14, RFC 2119, March 1977. 188 [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 190 [OSPFv3] Coltun, R., Ferguson, D. and Moy, J., 191 "OSPF for IPv6", RFC 2740, December 1999. 193 [ADDR-ARCH] Hinden, R. and Deering, S., 194 "IP Version 6 Addressing Architecture", 195 RFC 3513, April 2003. 197 [SOCKET] Gilligan, B., Thomson, S., Bound, J., McCann, J. 198 and Stevens, R., "Basic Socket Interface Extensions 199 for IPv6", RFC 3493, February 2003. 201 [RIPng] Malkin, G. and Minnear, R., "RIPng for IPv6", 202 RFC 2080, January 1997. 204 8. Informative References 206 [GTSM] Gill, V., Heasley, J., and Meyer, D., 207 The Generalized TTL Security Mechanism (GTSM) 208 drdraft-gill-gtsh-04.txt, Work in progress. 210 [AUTHv3] Gupta, M. and Melam, N., 211 "Authentication/Confidentiality for OSPFv3", 212 draft-ietf-ospf-ospfv3-auth-04.txt, Work in progress. 214 [VULNER] Jones, E. and Le Moigne, O., 215 "OSPF Security Vulnerabilities Analysis", 216 draft-jones-ospf-vuln-01.txt, Work in progress. 218 [GRE] Farinacci, D., Li, T., Hanks, S., Meyer, D. and 219 Traina, P., "Generic Routing Encapsulation (GRE)", 220 RFC 2784, March 2000. 222 9. Acknowledgments 224 The authors wish to acknowledge Enke Chen and George Apostolopoulos 225 for their thorough review. 227 10. Authors' Addresses 229 Acee Lindem 230 Redback Networks 231 102 Carric Bend Court 232 Cary, NC 27519 233 Email: acee@redback.com 235 Anand Oswal 236 Redback Networks 237 300 Holger 238 San Jose, CA 239 Email: aoswal@redback.com