idnits 2.17.1 draft-lindem-ospfv3-dest-filter-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 278. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 262. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 268. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 9 longer pages, the longest (page 11) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 144 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 (October 2004) is 7132 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 162, but not defined == Unused Reference: 'RIPng' is defined on line 196, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3513 (ref. 'IP6ADDR') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2740 (ref. 'OSPFv3') (Obsoleted by RFC 5340) -- Duplicate reference: RFC2328, mentioned in 'RFC2119', was also mentioned in 'OSPFv2'. ** Downref: Normative reference to an Informational RFC: RFC 3493 (ref. 'SOCKET') == Outdated reference: A later version (-08) exists of draft-ietf-ospf-ospfv3-auth-04 == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-rfc3682bis-02 == Outdated reference: A later version (-02) exists of draft-ietf-rpsec-ospf-vuln-00 Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Lindem 2 Internet-Draft Redback Networks 3 Expires: April 1, 2005 A. Oswal 4 Cisco Systems 5 October 2004 7 OSPFv3 Destination Address Filter 8 draft-lindem-ospfv3-dest-filter-03.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 1, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 OSPFv2 has been criticized for it vulnerability to Denial of Service 44 (DOS) attacks. With OSPFv3, it is a simple matter to filter on the 45 destination address at an implementation dependent level in order to 46 limit the scope of DOS attacks to directly attached routers. Unlike 47 hop limit checking mechanisms, it is compatible with the existing 48 OSPFv3 behavior. However, this level of protection will preclude the 49 deployment of virtual links in topologies where the filtering is 50 applied. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1 Virtual Links . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2 Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Implementation Placement and Granularity of Filter . . . . . . 6 59 4. RIPng Applicability . . . . . . . . . . . . . . . . . . . . . 7 60 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 8 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 65 8.2 Informative References . . . . . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 67 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 68 Intellectual Property and Copyright Statements . . . . . . . . 14 70 1. Introduction 72 OSPFv2 [OSPFv2] and OSPFv3 [OSPFv3] both have been criticised for 73 their vulnerability to Denial of Service attacks [VULNER]. Both 74 support cryptographic authentication to prevent an attacker from 75 being able to spoof an OSPFv2 or OSPFv3 packet ([OSPFv2] and 76 [AUTHv3]). However, in many cases the MD5 or IPSEC protection 77 actually exacerbates the attack due to the computational overhead 78 involved. For OSPFv3, this document proposes limiting accepted 79 OSPFv3 packets to those that are not routable. Doing so allows these 80 packets to be filtered at a low level for a relatively small 81 computational cost. 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Proposed Solution 89 In order to limit the vulnerability to DOS attacks to directly 90 attached routers, OSPFv3 packets are only accepted if the destination 91 address in the packet header is a link-local unicast address or 92 link-local scoped multicast address. Both these address types are 93 never forwarded more than one hop. Unlike hop limit checking 94 mechanisms [GTSM], this technique is fully backward compatible with 95 the OSPFv3 which doesn't specify that OSPFv3 packets be sent with a 96 hop limit of 255. The only hop limit specification is that the 97 link-scoped multicast packets are sent with a hop limit of 1. Hence, 98 this mechanism can be deployed on one OSPFv3 router at a time. 100 In order to make the checking simple and low cost, this document 101 suggests checking the first two octets of the IPv6 destination 102 address for a valid link local unicast or link-local scoped multicast 103 address. Based on the IPv6 Address Architecture [IP6ADDR], this 104 would equate to: 106 if (((first-two-octets & 0xffc0) != 0xfe80) && 107 ((first-two-octets & 0xff0f) != 0xff02)) { 108 drop the packet; 109 } 111 Alternately, an implementation may also check the multicast address 112 flags to assure they are 0x0 since the OSPFv3 specification 113 explicitly uses multicast addresses ff02::5 (AllSPFRouters) and 114 ff02::6 (AllDRrouters) [OSPFv3]. 116 if (((first-two-octets & 0xffc0) != 0xfe80) && 117 ((first-two-octets & 0xffff) != 0xff02)) { 118 drop the packet; 119 } 121 2.1 Virtual Links 123 Virtual links make use of a global IPv6 unicast destination address. 124 Hence, the proposed destination address filter and virtual links are 125 incompatible. Depending on the granularity of the filtering, virtual 126 links may still be used (See Section 3.0). 128 2.2 Tunnels 130 In order to support OSPF over tunnels, e.g. GRE [GRE], it is 131 necessary for the destination filter to be applied after OSPF packets 132 are delivered to the tunnel endpoint and decapsulated. Furthermore, 133 the encapsulated OSPFv3 packet's destination address should be 134 AlllSPFRouters (FF02::5). 136 3. Implementation Placement and Granularity of Filter 138 The placement and granularity of the destination address filter is an 139 engineering decision that must be made for each implementation. 140 Obviously, the sooner it is done after packet reception the less 141 resource that is consumed processing packets that will be dropped. 142 However, since the checking has to be confined to OSPFv3 packets that 143 are delivered locally it may be easier to delay the checking until 144 the packets have been identified as such. A conveinent place in an 145 implementation using the BSD socket model [SOCKET] is the point at 146 which an inbound packet is added to the OSPFv3 socket. 148 The granularity of the check will limit the usage of virtual links at 149 the granularity which it is applied. For example, if it is applied 150 at the BSD socket level, virtual links may not be used by any OSPF 151 instance utilizing that socket. Alternately, additional 152 configuration and checking could be added at the socket level so that 153 the destination filter is only applied to certain instances, areas, 154 or interfaces. Implementations will need to balance their market 155 requirements for virtual link deployment. In any case, the use of 156 virtual link SHOULD be allowed either by configuration or the filter 157 should be automatically disabled when a virtual link is configured. 159 4. RIPng Applicability 161 The destination filter described herein is also applicable to RIPng 162 [RIPNG]. The filter simply needs to be applied to UDP port 521. In 163 RIPng there is no concept of a virtual link and no requirement to 164 send to IPv6 global addresses. 166 5. Compatibility 168 All mechanisms described in this document are backward-compatible 169 with standard OSPFv3 implementations [OSPFv3]. 171 6. Security Considerations 173 This document recommends a mechanism that can be used to limit OSPFv3 174 Denial of Service (DOS) attacks to directly attached networks. 175 Hence, the entire document deals with security. 177 7. IANA Considerations 179 This document does not require any IANA assignments or action. 181 8. References 183 8.1 Normative References 185 [IP6ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing 186 Architecture", RFC 3513, April 2003. 188 [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 190 [OSPFv3] Moy, J., Ferguson, D. and R. Colton, "OSPF for IPv6", RFC 191 2740, December 1999. 193 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 194 Requirement Levels", RFC 2328, March 1977. 196 [RIPng] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 197 January 1997. 199 [SOCKET] Gilligan, B., Thomson, S., Bound, J. and J. McCann, "Basic 200 Socket Interface Extensions for IPv6", RFC 3493, February 201 2003. 203 8.2 Informative References 205 [AUTHv3] Gupta, M. and N. Melam, "Authentication/Confidentiality for 206 OSPFv3", draft-ietf-ospf-ospfv3-auth-04.txt (work in 207 progress). 209 [GRE] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, 210 "Generic Routing Encapsulation (GRE)", RFC 2784, March 211 2000. 213 [GTSM] Gill, V., Heasley, J. and D. Meyer, "The Generalized TTL 214 Security Mechanism (GTSM)", 215 draft-ietf-rtgwg-rfc3682bis-02.txt (work in progress). 217 [VULNER] Jones, E. and O. Le Moigne, "OSPF Security Vulnerabilities 218 Analysis", draft-ietf-rpsec-ospf-vuln-00.txt (work in 219 progress). 221 Authors' Addresses 223 Acee Lindem 224 Redback Networks 225 102 Carric Bend Court 226 Cary, NC 27519 227 USA 229 EMail: acee@redback.com 231 Anand Oswal 232 Cisco Systems 233 225 West Tasman Drive 234 San Jose, CA 95134 235 USA 237 EMail: sina@cisco.com 239 Appendix A. Acknowledgments 241 The authors wish to acknowledge Mukesh Gupta, Venkata Naidu, Enke 242 Chen, and George Apostolopoulos for their review and comments. 244 The RFC text was produced using Marshall Rose's xml2rfc tool. 246 Intellectual Property Statement 248 The IETF takes no position regarding the validity or scope of any 249 Intellectual Property Rights or other rights that might be claimed to 250 pertain to the implementation or use of the technology described in 251 this document or the extent to which any license under such rights 252 might or might not be available; nor does it represent that it has 253 made any independent effort to identify any such rights. Information 254 on the procedures with respect to rights in RFC documents can be 255 found in BCP 78 and BCP 79. 257 Copies of IPR disclosures made to the IETF Secretariat and any 258 assurances of licenses to be made available, or the result of an 259 attempt made to obtain a general license or permission for the use of 260 such proprietary rights by implementers or users of this 261 specification can be obtained from the IETF on-line IPR repository at 262 http://www.ietf.org/ipr. 264 The IETF invites any interested party to bring to its attention any 265 copyrights, patents or patent applications, or other proprietary 266 rights that may cover technology that may be required to implement 267 this standard. Please address the information to the IETF at 268 ietf-ipr@ietf.org. 270 Disclaimer of Validity 272 This document and the information contained herein are provided on an 273 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 274 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 275 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 276 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 277 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 278 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 280 Copyright Statement 282 Copyright (C) The Internet Society (2004). This document is subject 283 to the rights, licenses and restrictions contained in BCP 78, and 284 except as set forth therein, the authors retain all their rights. 286 Acknowledgment 288 Funding for the RFC Editor function is currently provided by the 289 Internet Society.