idnits 2.17.1 draft-senie-directed-broadcast-01.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-19) 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. ** Expected the document's filename to be given on the first page, but didn't find any == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 3 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 34: '... also specifies that routers MUST have...' RFC 2119 keyword, line 35: '...ure, and that this option MUST default...' RFC 2119 keyword, line 80: '... prefix. It MUST NOT be used as a...' RFC 2119 keyword, line 81: '... Broadcast packets. A router MUST NOT...' RFC 2119 keyword, line 82: '...roadcast packets; however a router MAY...' (4 more instances...) == 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 == Line 65 has weird spacing: '... use of dynam...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (January 1999) is 9226 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) ** Obsolete normative reference: RFC 2267 (ref. '2') (Obsoleted by RFC 2827) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2002 (ref. '4') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT D. Senie 3 Category: BCP Amaranth Networks Inc. 4 Updates: RFC 1812 January 1999 5 Expires in six months 7 Changing the Default for Directed Broadcasts in Routers 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 and 34 forward directed broadcasts. It also specifies that routers MUST have 35 an option to disable this feature, and that this option MUST default 36 to permit the receiving and forwarding of directed broadcasts. While 37 directed broadcasts have uses, their use on the Internet backbone 38 appears to be comprised entirely of malicious attacks on other 39 networks. 41 Changing the required default for routers would help ensure new 42 routers connected to the Internet do not add to the problems already 43 present. 45 2. Discussion 47 Damaging denial of service attacks led to the writing of [2] on 48 Ingress Filtering. Many network providers and corporate networks have 49 endorsed the use of these methods to ensure their networks are not 50 the source of such attacks. 52 A recent trend in Smurf Attacks [3] is to target networks which 53 permit directed broadcasts from outside their networks. By permitting 54 directed broadcasts, these systems become "Smurf Amplifiers." 56 While the continued implementation of ingress filters remains the 57 best way to limit these attacks, restricting directed broadcasts 58 should also receive priority. 60 Network service providers and corporate network operators are urged 61 to ensure their networks are not susceptible to directed broadcast 62 packets originating outside their networks. 64 Mobile IP [4] had provisions for using directed broadcasts in a 65 mobile node's use of dynamic agent discovery. While some 66 implementations support this feature, it is unclear whether it is 67 useful. Other methods of achieving the same result are documented in 68 [5]. It may be worthwhile to consider removing the language on using 69 directed broadcasts as Mobile IP progresses on the standards track. 71 3. Recommendation 73 Router Requirements [1] is updated as follows: 75 Section 4.2.2.11 (d) is replaced with: 77 (d) { , -1 } 79 Directed Broadcast - a broadcast directed to the specified network 80 prefix. It MUST NOT be used as a source address. A router MAY 81 originate Network Directed Broadcast packets. A router MUST NOT 82 receive Network Directed Broadcast packets; however a router MAY 83 have a configuration option to allow reception of these packets. 84 Such an option MUST default to blocking reception. 86 Section 5.3.5.2, second paragraph replaced with: 88 A router MAY have an option to enable receiving network-prefix- 89 directed broadcasts on an interface and MAY have an option to 90 enable forwarding network-prefix-directed broadcasts. These 91 options MUST default to blocking receipt and blocking forwarding 92 of network-prefix-directed broadcasts. 94 4. Security Considerations 96 The goal of this document is to reduce the efficacy of certain types 97 of denial of service attacks. 99 5. References 101 [1] F. Baker, "Requirements for IP Version 4 Routers", RFC1812, June 102 1995. 104 [2] P. Ferguson, D. Senie, "Ingress Filtering", RFC 2267, January 105 1998. 107 [3] See the pages by Craig Huegen at: 108 http://www.quadrunner.com/~chuegen/smurf.txt. 110 [4] C. Perkins, "IP Mobility Support", RFC 2002, October 1996. 112 [5] P. Calhoun, C. Perkins, "Mobile IP Dynamic Home Address 113 Allocation Extensions", , 114 Work in progress, November 1998. 116 6. Acknowledgements 118 The author would like to thank Brandon Ross of Mindspring and Gabriel 119 Montenegro of Sun for their input. 121 6. Author's Address 123 Daniel Senie 124 Amaranth Networks Inc. 125 324 Still River Road 126 Bolton, MA 01740 128 Phone: (978) 779-6813 130 EMail: dts@senie.com