idnits 2.17.00 (12 Aug 2021) /tmp/idnits57525/draft-lindem-ospfv3-dest-filter-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-21) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 3) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages 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 134 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 (May 2004) is 6580 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 154, but not defined == Unused Reference: 'RIPng' is defined on line 204, 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 (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Acee Lindem (Redback Networks) 3 Internet Draft Anand Oswal (Redback Networks) 4 Expiration Date: Oct 2004 5 File name: draft-lindem-ospfv3-dest-filter-02.txt May 2004 7 OSPFv3 Destination Address Filter 8 draft-lindem-ospfv3-dest-filter-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or IPR claims of which I am aware have been disclosed, and 14 any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 OSPFv2 has been criticized for it vulnerability to Denial of 36 Service (DOS) attacks. With OSPFv3, it is a simple matter to filter 37 on the destination address at an implementation dependent level 38 in order to limit the scope of DOS attacks to directly attached 39 routers. Unlike hop limit checking mechanisms, it is compatible 40 with the existing OSPFv3 behavior. However, this level of 41 protection will preclude the deployment of virtual links in 42 topologies where the filtering is applied. 44 Table of Contents 46 1 Overview ............................................... 2 47 2 Proposed Solution ...................................... 2 48 2.1 Virtual Links .......................................... 3 49 2.2 Tunnels ................................................ 3 50 3 Implementation and Granularity of Filter ............... 3 51 4 RIPng Applicabilty ..................................... 4 52 5 Security Considerations ................................ 4 53 6 Intellectual Property .................................. 4 54 7 Normative References ................................... 5 55 8 Informative References ................................. 5 56 9 Acknowledgments ........................................ 6 57 10 Authors' Addresses ..................................... 6 59 1. Overview 61 OSPFv2 [OSPFv2] and OSPFv3 [OSPFv3] both have been criticised for 62 their vulnerability to Denial of Service attacks [VULNER]. Both 63 support cryptographic authentication to prevent an attacker from 64 being able to spoof an OSPFv2 or OSPFv3 packet ([OSPFv2] and 65 [AUTHv3]). However, in many cases the MD5 or IPSEC protection 66 actually exacerbates the attack due to the computational overhead 67 involved. For OSPFv3, this document proposes limiting accepted 68 OSPFv3 packets to those that are not routable. Doing so allows 69 these packets to be filtered at a low level for a relatively 70 small computational cost. 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC-2119]. 76 2. Proposed Solution 78 In order to limit the vulnerability to DOS attacks to directly 79 attached routers, OSPFv3 packets are only accepted if the 80 destination address in the packet header is a link-local unicast 81 address or link-local scoped multicast address. Both these address 82 types are never forwarded more than one hop. Unlike hop limit 83 checking mechanisms [GTSM], this technique is fully backward 84 compatible with the OSPFv3 which doesn't specify that OSPFv3 85 packets be sent with a hop limit of 255. The only hop limit 86 specification is that the link-scoped multicast packets are 87 sent with a hop limit of 1. Hence, this mechanism can be deployed 88 on one OSPFv3 router at a time. 90 In order to make the checking simple and low cost, this document 91 suggests checking the first two octets of the IPv6 destination 92 address for a valid link local unicast or link-local scoped 93 multicast address. Based on the IPv6 Address Architecture 94 [ADDR-ARCH], this would equate to: 96 if (((first-two-octets & 0xffc0) != 0xfe80) && 97 ((first-two-octets & 0xff0f) != 0xff02)) { 98 drop the packet; 99 } 101 Alternately, an implementation may also check the multicast address 102 flags to assure they are 0x0 since the OSPFv3 specification 103 explicitly uses multicast addresses ff02::5 (AllSPFRouters) and 104 ff02::6 (AllDRrouters) [OSPFv3]. 106 if (((first-two-octets & 0xffc0) != 0xfe80) && 107 ((first-two-octets & 0xffff) != 0xff02)) { 108 drop the packet; 109 } 111 2.1 Virtual Links 113 Virtual links make use of a global IPv6 unicast destination address. 114 Hence, the proposed destination address filter and virtual links are 115 incompatible. Depending on the granularity of the filtering, 116 virtual links may still be used (See Section 3.0). 118 2.2 Tunnels 120 In order to support OSPF over tunnels, e.g. GRE [GRE], it is 121 necessary for the destination filter to be applied after OSPF 122 packets are delivered to the tunnel endpoint and decapsulated. 123 Furthermore, the encapsulated OSPFv3 packet's destination 124 address should be AlllSPFRouters (FF02::5). 126 3.0 Implementation Placement and Granularity of Filter 128 The placement and granularity of the destination address filter 129 is an engineering decision that must be made for each 130 implementation. Obviously, the sooner it is done after packet 131 reception the less resource that is consumed processing packets 132 that will be dropped. However, since the checking has to be 133 confined to OSPFv3 packets that are delivered locally it may be 134 easier to delay the checking until the packets have been identified 135 as such. A conveinent place in an implementation using the BSD 136 socket model [SOCKET] is the point at which an inbound packet 137 is added to the OSPFv3 socket. 139 The granularity of the check will limit the usage of virtual 140 links at the granularity which it is applied. For example, if it is 141 applied at the BSD socket level, virtual links may not be used 142 by any OSPF instance utilizing that socket. Alternately, additional 143 configuration and checking could be added at the socket level so 144 that the destination filter is only applied to certain instances, 145 areas, or interfaces. Implementations will need to balance their 146 market requirements for virtual link deployment. In any case, the 147 use of virtual link SHOULD be allowed either by configuration or 148 the filter should be automatically disabled when a virtual link 149 is configured. 151 4. RIPng Applicability 153 The destination filter described herein is also applicable to 154 RIPng [RIPNG]. The filter simply needs to be applied to UDP port 155 521. In RIPng there is no concept of a virtual link and no 156 requirement to send to IPv6 global addresses. 158 5. Security Considerations 160 This document recommends a mechanism that can be used to limit 161 OSPFv3 Denial of Service (DOS) attacks to directly attached networks. 162 Hence, the entire document deals with security. 164 6. Intellectual Property 166 The IETF takes no position regarding the validity or scope of any 167 intellectual property or other rights that might be claimed to 168 pertain to the implementation or use of the technology described in 169 this document or the extent to which any license under such rights 170 might or might not be available; neither does it represent that it 171 has made any effort to identify any such rights. Information on the 172 IETF's procedures with respect to rights in standards-track and 173 standards-related documentation can be found in BCP-11. Copies of 174 claims of rights made available for publication and any assurances of 175 licenses to be made available, or the result of an attempt made to 176 obtain a general license or permission for the use of such 177 proprietary rights by implementors or users of this specification can 178 be obtained from the IETF Secretariat. 180 The IETF invites any interested party to bring to its attention any 181 copyrights, patents or patent applications, or other proprietary 182 rights which may cover technology that may be required to practice 183 this standard. Please address the information to the IETF Executive 184 Director. 186 7. Normative References 188 [RFC-2119] Bradner, S., "Key words for use in RFC's to Indicate 189 Requirement Levels", BCP 14, RFC 2119, March 1977. 191 [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 193 [OSPFv3] Coltun, R., D. Ferguson, and J. Moy, 194 "OSPF for IPv6", RFC 2740, December 1999. 196 [ADDR-ARCH] Hinden, R. and S. Deering, 197 "IP Version 6 Addressing Architecture", 198 RFC 3513, April 2003. 200 [SOCKET] Gilligan, B., S. Thomson, J. Bound, J. McCann, 201 and R. Stevens, "Basic Socket Interface Extensions 202 for IPv6", RFC 3493, February 2003. 204 [RIPng] Malkin, G. and R. Minnear, "RIPng for IPv6", 205 RFC 2080, January 1997. 207 8. Informative References 209 [GTSM] Gill, V., J. Heasley, and D. Meyer, 210 The Generalized TTL Security Mechanism (GTSM) 211 drdraft-gill-gtsh-04.txt, Work in progress. 213 [AUTHv3] Gupta, M. and N. Melam, 214 "Authentication/Confidentiality for OSPFv3", 215 draft-ietf-ospf-ospfv3-auth-04.txt, Work in progress. 217 [VULNER] Jones, E. and O. Le Moigne, 218 "OSPF Security Vulnerabilities Analysis", 219 draft-jones-ospf-vuln-01.txt, Work in progress. 221 [GRE] Farinacci, D., T. Li, S. Hanks, D. Meyer, and 222 P. Traina, "Generic Routing Encapsulation (GRE)", 223 RFC 2784, March 2000. 225 9. Acknowledgments 227 The authors wish to acknowledge Mukesh Gupta, Venkata Naidu, 228 Enke Chen, and George Apostolopoulos for their review and 229 comments. 231 10. Authors' Addresses 233 Acee Lindem 234 Redback Networks 235 102 Carric Bend Court 236 Cary, NC 27519 237 Email: acee@redback.com 239 Anand Oswal 240 Redback Networks 241 300 Holger 242 San Jose, CA 243 Email: aoswal@redback.com