idnits 2.17.00 (12 Aug 2021) /tmp/idnits59096/draft-lindem-ospfv3-dest-filter-00.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 121 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 (Feb 2004) is 6670 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 141, but not defined == Unused Reference: 'RIPng' is defined on line 191, 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: July 2004 4 File name: draft-lindem-ospfv3-dest-filter-00.txt Feb 2004 6 OSPFv3 Destination Address Filter 7 draft-lindem-ospfv3-dest-filter-00.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. Howevr, 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 that 82 OSPFv3 packets be sent with a hop limit of 255. The only hop 83 limit specification is that the link-scoped multicast packets 84 are sent with a hop limit of 1. Hence, this mechanism 85 can be deployed 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 2.1 Virtual Links 100 Virtual links make use of a global IPv6 unicast destination address. 101 Hence, the propsed destination address filter and virtual links are 102 incompatible. Depending on the granularity of the filtering, 103 virtual links may still be used (See Section 3.0). 105 2.2 Tunnels 107 In order to support OSPF over tunnels, e.g. GRE [GRE], it is 108 necessary for the destination filter to be applied after OSPF 109 packets are delivered to the tunnel endpoint and decapsulated. 110 Furthermore, the encapsulated OSPFv3 packet's destination 111 address should be AlllSPFRouters (FF02::5). 113 3.0 Implementation Placement and Granularity of Filter 115 The placement and granularity of the destination address filter 116 is an engineering decision that must be made for each 117 implementation. Obviously, the sooner it is done after packet 118 reception the less resource that is consumed processing packets 119 that will be dropped. However, since the checking has to be 120 confined to OSPFv3 packets that are delivered locally it may be 121 easier to delay the checking until the packets have been identified 122 as such. A conveinent place in an implementation using the BSD 123 socket model [SOCKET] is the point at which an inbound packet 124 is added to the OSPFv3 socket. 126 The granularity of the check will limit the usage of virtual 127 links at the granularity which it is applied. For example, if it is 128 applied at the BSD socket level, virtual links may not be used 129 by any OSPF instance utilizing that socket. Alternately, additional 130 configuration and checking could be added at the socket level so 131 that the destination filter is only applied to certain instances, 132 areas, or interfaces. Implemenations will need to balance their 133 market requirements for virtual link deployment. In any case, the 134 use of virtual link SHOULD be allowed either by configuration or 135 the filter should be automatically disabled when a virtual link 136 is configured. 138 4. RIPng Applicability 140 The destination filter described herein is also applicable to 141 RIPng [RIPNG]. The filter simply needs to be applied to UDP port 142 521. In RIPng there is no concept of a virtual link and no 143 requirement to send to IPv6 global addresses. 145 5. Security Considerations 147 This document recommends a mechanism that can be used to limit 148 OSPFv3 Denial of Service (DOS) attacks to directly attached networks. 149 Hence, the entire document deals with security. 151 6. Intellectual Property 153 The IETF takes no position regarding the validity or scope of any 154 intellectual property or other rights that might be claimed to 155 pertain to the implementation or use of the technology described in 156 this document or the extent to which any license under such rights 157 might or might not be available; neither does it represent that it 158 has made any effort to identify any such rights. Information on the 159 IETF's procedures with respect to rights in standards-track and 160 standards-related documentation can be found in BCP-11. Copies of 161 claims of rights made available for publication and any assurances of 162 licenses to be made available, or the result of an attempt made to 163 obtain a general license or permission for the use of such 164 proprietary rights by implementors or users of this specification can 165 be obtained from the IETF Secretariat. 167 The IETF invites any interested party to bring to its attention any 168 copyrights, patents or patent applications, or other proprietary 169 rights which may cover technology that may be required to practice 170 this standard. Please address the information to the IETF Executive 171 Director. 173 7. Normative References 175 [RFC-2119] Bradner, S., "Key words for use in RFC's to Indicate 176 Requirement Levels", BCP 14, RFC 2119, March 1977. 178 [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 180 [OSPFv3] Coltun, R., Ferguson, D. and Moy, J., 181 "OSPF for IPv6", RFC 2740, December 1999. 183 [ADDR-ARCH] Hinden, R. and Deering, S., 184 "IP Version 6 Addressing Architecture", 185 RFC 3513, April 2003. 187 [SOCKET] Gilligan, B., Thomson, S., Bound, J., McCann, J. 188 and Stevens, R., "Basic Socket Interface Extensions 189 for IPv6", RFC 3493, February 2003. 191 [RIPng] Malkin, G. and Minnear, R., "RIPng for IPv6", 192 RFC 2080, January 1997. 194 8. Informative References 196 [GTSM] Gill, V., Heasley, J., and Meyer, D., 197 The Generalized TTL Security Mechanism (GTSM) 198 drdraft-gill-gtsh-04.txt, Work in progress. 200 [AUTHv3] Gupta, M. and Melam, N., 201 "Authentication/Confidentiality for OSPFv3", 202 draft-ietf-ospf-ospfv3-auth-04.txt, Work in progress. 204 [VULNER] Jones, E. and Le Moigne, O., 205 "OSPF Security Vulnerabilities Analysis", 206 draft-jones-ospf-vuln-01.txt, Work in progress. 208 [GRE] Farinacci, D., Li, T., Hanks, S., Meyer, D. and 209 Traina, P., "Generic Routing Encapsulation (GRE)", 210 RFC 2784, March 2000. 212 9. Acknowledgments 214 The authors wish to acknowledge Enke Chen and George Apostolopoulos 215 for their thorough review. 217 10. Authors' Addresses 219 Acee Lindem 220 Redback Networks 221 102 Carric Bend Court 222 Cary, NC 27519 223 Email: acee@redback.com 225 Anand Oswal 226 Redback Networks 227 300 Holger 228 San Jose, CA 229 Email: aoswal@redback.com