idnits 2.17.1 draft-senie-directed-broadcast-00.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. Found some kind of copyright notice around line 29 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-26) 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) 2024 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 2 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 60: '... Router Requirements [1] is updated as follows. Routers MUST NOT...' RFC 2119 keyword, line 62: '... Routers MAY provide a configuration...' == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC1812, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC1812, updated by this document, for RFC5378 checks: 1994-11-29) -- 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 (January 1999) is 9233 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2267 (ref. '3') (Obsoleted by RFC 2827) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Senie 2 Category: Informational Amaranth Networks Inc. 3 Updates: RFC 1812 January 1999 4 Expires in six months 6 Changing the Default for Directed Broadcasts in Routers 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check the 22 "`id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 25 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 Copyright Notice 29 Copyright (C) The Internet Society (1999). All Rights Reserved. 31 1. Introduction 33 Router Requirements [1] specifies that routers must receive directed 34 broadcasts, though it may contain configuration settings to disable 35 this feature. While directed broadcasts have uses, their use on the 36 Internet backbone appears to be comprised entirely of malicious 37 attacks on other networks. 39 Changing the required default for routers would help ensure new 40 routers connected to the Internet do not add to the problems already 41 present. 43 2. Discussion 45 Damaging denial of service attacks led to the writing of [3] on 46 Ingress Filtering. Many network providers and corporate networks have 47 endorsed the use of these methods to ensure their networks are not 48 the source of such attacks. 50 A recent trend in Smurf Attacks [2] is to target networks which 51 permit directed broadcasts from outside their networks. By permitting 52 directed broadcasts, these systems become "Smurf Amplifiers." 54 While the continued implementation of ingress filters remains the 55 best way to limit these attacks, restricting directed broadcasts 56 should also receive priority. 58 3. Recommendation 60 Router Requirements [1] is updated as follows. Routers MUST NOT 61 process packets which are addressed to directed broadcast addresses. 62 Routers MAY provide a configuration option to enable the processing 63 of directed broadcasts for those situations and applications where 64 this is required. 66 Network service providers and corporate network operators are urged 67 to ensure their networks are not susceptible to directed broadcast 68 packets originating outside their networks. 70 4. Security Considerations 72 The goal of this document is to reduce the efficacy of certain types 73 of denial of service attacks. 75 5. References 77 [1] F. Baker, "Requirements for IP Version 4 Routers", RFC1812, June 78 1995. 80 [2] See the pages by Craig Huegen at: 81 http://www.quadrunner.com/~chuegen/smurf.txt. 83 [3] P. Ferguson, D. Senie, "Ingress Filtering", RFC 2267, January 84 1998. 86 6. Author's Address 88 Daniel Senie 89 Amaranth Networks Inc. 90 324 Still River Road 91 Bolton, MA 01740 93 Phone: (978) 779-6813 95 EMail: dts@senie.com