idnits 2.17.00 (12 Aug 2021) /tmp/idnits27293/draft-rahman-rtg-router-alert-dangerous-00.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 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 228. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 239. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 246. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 252. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 83 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([RFC2205], [RFC3376], [RFC3209], [RFC2113], [RFC2711]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Introducing new protocols/applications which make use of IP Router Alert option MUST not provide a means of attacking or harming deployed protocols such as RSVP and IGMP which already make use of the IP Router Alert option. -- 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 2008) is 4959 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 182, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 186, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 189, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4081 ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) -- Duplicate reference: RFC2119, mentioned in 'RFC2119', was also mentioned in '1'. -- Duplicate reference: RFC2234, mentioned in 'RFC2234', was also mentioned in '2'. ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area Working Group R. Rahman 3 D. Ward 4 Internet Draft Cisco Systems 5 Intended status: BCP October 2008 6 Expires: April 2009 8 Use of IP Router Alert Considered Dangerous 9 draft-rahman-rtg-router-alert-dangerous-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that 14 any applicable patent or other IPR claims of which he or she is 15 aware have been or will be disclosed, and any of which he or she 16 becomes aware will be disclosed, in accordance with Section 6 of 17 BCP 79. 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 Internet- 22 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 17, 2009. 37 Abstract 39 This document provides guidelines to address security concerns which 40 arise with the use of IP Router Alert option [RFC2113] and [RFC2711]. 41 RSVP,[RFC2205] and [RFC3209], and IGMP [RFC3376] are some of the 42 protocols which make use of the IP Router Alert option. IP datagrams 43 carrying the Router Alert option are usually examined in a router's 44 "slow path" and an excess of such datagrams can cause performance 45 degradation or packet drops in a router's "slow path". 47 2008 49 Table of Contents 51 1. Introduction...................................................2 52 2. Conventions used in this document..............................2 53 3. Security Risk Of IP Router Alert Option........................2 54 4. Guidelines For Use Of IP Router Alert Option...................3 55 5. Security Considerations........................................3 56 6. IANA Considerations............................................4 57 7. Conclusions....................................................4 58 8. Acknowledgments................................................4 59 9. References.....................................................5 60 9.1. Normative References......................................5 62 1. Introduction 64 The main purpose of this document is to describe the security risks 65 associated with the use of IP Router Alert and to discourage new 66 applications and protocols from using IP Router Alert. 68 2. Conventions used in this document 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC-2119 [1]. 74 3. Security Risk Of IP Router Alert Option 76 IP datagrams carrying the Router Alert option are usually examined in 77 a router's "slow path" and an excess of such datagrams can cause 78 performance degradation or packet drops in a router's "slow path". 80 [RFC4081] and [RFC2711] mention the security risks associated with 81 the use of the IP Router Alert option: flooding a router with bogus 82 IP datagrams which contain the IP Router Alert option would cause a 83 performance degradation of the router's "slow path" and can also lead 84 to packet drops in the "slow path". 86 [RFC2711] mentions that limiting, by rate or some other means, the 87 use of Router Alert option is a way of protecting against a potential 88 attack. If rate limiting is used as a protection mechanism and the 89 granularity of the rate limiting is coarse, an attack using packet 90 types of one protocol could severely degrade the operation of other 91 protocols using IP Router Alert option. 93 2008 95 4. Guidelines For Use Of IP Router Alert Option 97 To protect the "slow path" against DOS attacks, a router MUST have a 98 means of limiting the number of Router Alert IP datagrams which go to 99 the "slow path". 101 If there are multiple protocols which make use of IP Router Alert 102 option on a router, the limiting MUST be able to distinguish between 103 the various protocols. E.g. if rate limiting is used, there MUST be 104 different rate limit pools for the protocols so that an attack on one 105 protocol will not affect the operation of another protocol. 107 IP Router Alert packets MUST NOT be sent to the "slow path" unless 108 there is at least one protocol enabled which uses the IP Router Alert 109 option. 111 A router SHOULD inspect Router Alert packets before sending them to 112 the "slow path" so that if the protocol to which a packet belongs is 113 not enabled on the router or on the incoming interface (physical or 114 virtual), then the packet is dropped. 116 Introducing new protocols/applications which make use of IP Router 117 Alert option MUST not provide a means of attacking or harming 118 deployed protocols such as RSVP and IGMP which already make use of 119 the IP Router Alert option. 121 Routing and signaling users of IP Router Alert, e.g. IGMP and RSVP, 122 are the highest priority users and MUST NOT be impacted by other 123 users of IP Router Alert. 125 Any application that relies on IP Router Alert should expect that the 126 incoming packets MAY be dropped by default and that a special filter 127 is needed to let the packets through. 129 All non-routing and non-signaling IP Router Alert packets, when 130 enabled, may be significantly rate limited. 132 Creating an application or protocol that uses IP Router Alert is 133 considered harmful and is strongly discouraged. A different mechanism 134 should be used to decrease the risk of impacting existing routing and 135 signaling protocols which use IP Router Alert 137 5. Security Considerations 139 This document provides guidelines for security risks which are 140 present with the use of IP Router Alert option. Its purpose is to 142 2008 144 have greater security against DDOS attacks and to discourage new 145 applications from using IP Router Alert since this would cause a 146 security risk against current users of IP Router Alert. 148 6. IANA Considerations 150 7. Conclusions 152 Use of IP Router Alert is a security risk and should be discouraged 153 for new applications and protocols. 155 8. Acknowledgments 157 This document was prepared using 2-Word-v2.0.template.dot. 159 2008 161 9. References 163 [RFC2113] "IP Router Alert Option", RFC 2113, D. Katz, February 164 1997. 165 [RFC2711] "IPv6 Router Alert Option", RFC 2711, C. Partridge, et al, 166 October 1999. 167 [RFC2205] "Resource ReSerVation Protocol (RSVP) - Version 1, 168 Functional Specification", RFC 2205, Braden, et al, September 169 1997. 170 [RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al, 171 RFC 3209, December 2001. 172 [RFC3376] "Internet Group Management Protocol, Version 3", RFC 3376, 173 B. Cain, et al, October 2002. 174 [RFC4081] "Security Threats For Next Steps in Signaling (NSIS)", RFC 175 4081, H. Tschofenig, et al, June 2005 177 9.1. Normative References 179 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 180 Levels", BCP 14, RFC 2119, March 1997. 182 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 183 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 184 Demon Internet Ltd., November 1997. 186 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 187 Requirement Levels", BCP 14, RFC 2119, March 1997. 189 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 190 Syntax Specifications: ABNF", RFC 2234, Internet Mail 191 Consortium and Demon Internet Ltd., November 1997. 193 Author's Addresses 195 Reshad Rahman 196 Cisco Systems Inc. 197 2000 Innovation Dr., 198 Kanata, Ontario, K2K 3E8 199 Canada. 200 Phone: (613)-254-3519 201 Email: rrahman@cisco.com 203 David Ward 204 Cisco Systems Inc. 205 3750 Cisco Way, 207 2008 209 San Jose, California, 95134 210 United States 211 Phone: (651)-726-2368 212 Email: wardd@cisco.com 214 Full Copyright Statement 216 Copyright (C) The IETF Trust (2008). 218 This document is subject to the rights, licenses and restrictions 219 contained in BCP 78, and except as set forth therein, the authors 220 retain all their rights. 222 This document and the information contained herein are provided on an 223 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 224 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 225 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 226 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 227 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 228 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 230 Intellectual Property Statement 232 The IETF takes no position regarding the validity or scope of any 233 Intellectual Property Rights or other rights that might be claimed to 234 pertain to the implementation or use of the technology described in 235 this document or the extent to which any license under such rights 236 might or might not be available; nor does it represent that it has 237 made any independent effort to identify any such rights. Information 238 on the procedures with respect to rights in RFC documents can be 239 found in BCP 78 and BCP 79. 241 Copies of IPR disclosures made to the IETF Secretariat and any 242 assurances of licenses to be made available, or the result of an 243 attempt made to obtain a general license or permission for the use of 244 such proprietary rights by implementers or users of this 245 specification can be obtained from the IETF on-line IPR repository at 246 http://www.ietf.org/ipr. 248 The IETF invites any interested party to bring to its attention any 249 copyrights, patents or patent applications, or other proprietary 250 rights that may cover technology that may be required to implement 251 this standard. Please address the information to the IETF at 252 ietf-ipr@ietf.org.