RFC2644 Changing the Default for Directed Broadcasts in Routers

2644 Changing the Default for Directed Broadcasts in Routers. D.Senie. August 1999. (Format: TXT=6820 bytes) (Updates RFC1812) (Also BCP0034) (Status: BEST CURRENT PRACTICE)

日本語訳
RFC一覧

参照

Network Working Group                                           D. Senie
Request for Comments: 2644                        Amaranth Networks Inc.
Updates: 1812                                                August 1999
BCP: 34
Category: Best Current Practice


        Changing the Default for Directed Broadcasts in Routers

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

1. Introduction

   Router Requirements [1] specifies that routers must receive and
   forward directed broadcasts. It also specifies that routers MUST have
   an option to disable this feature, and that this option MUST default
   to permit the receiving and forwarding of directed broadcasts.  While
   directed broadcasts have uses, their use on the Internet backbone
   appears to be comprised entirely of malicious attacks on other
   networks.

   Changing the required default for routers would help ensure new
   routers connected to the Internet do not add to the problems already
   present.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

2. Discussion

   Damaging denial of service attacks led to the writing of [2] on
   Ingress Filtering. Many network providers and corporate networks have
   endorsed the use of these methods to ensure their networks are not
   the source of such attacks.

   A recent trend in Smurf Attacks [3] is to target networks which
   permit directed broadcasts from outside their networks. By permitting
   directed broadcasts, these systems become "Smurf Amplifiers."




Senie                    Best Current Practice                  [Page 1]

RFC 2644         Default Change for Directed Broadcast       August 1999


   While the continued implementation of ingress filters remains the
   best way to limit these attacks, restricting directed broadcasts
   should also receive priority.

   Network service providers and corporate network operators are urged
   to ensure their networks are not susceptible to directed broadcast
   packets originating outside their networks.

   Mobile IP [4] had provisions for using directed broadcasts in a
   mobile node's use of  dynamic agent discovery. While some
   implementations support this feature, it is unclear whether it is
   useful. Other methods of achieving the same result are documented in
   [5]. It may be worthwhile to consider removing the language on using
   directed broadcasts as Mobile IP progresses on the standards track.

3. Recommendation

   Router Requirements [1] is updated as follows:

   Section 4.2.2.11 (d) is replaced with:

      (d) { , -1 }

      Directed Broadcast - a broadcast directed to the specified network
      prefix.  It MUST NOT be used as a source address.  A router MAY
      originate Network Directed Broadcast packets.  A router MAY have a
      configuration option to allow it to receive directed broadcast
      packets, however this option MUST be disabled by default, and thus
      the router MUST NOT receive Network Directed Broadcast packets
      unless specifically configured by the end user.

   Section 5.3.5.2, second paragraph replaced with:

      A router MAY have an option to enable receiving network-prefix-
      directed broadcasts on an interface and MAY have an option to
      enable forwarding network-prefix-directed broadcasts.  These
      options MUST default to blocking receipt and blocking forwarding
      of network-prefix-directed broadcasts.

4. Security Considerations

   The goal of this document is to reduce the efficacy of certain types
   of denial of service attacks.

5. References

   [1] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
       June 1995.



Senie                    Best Current Practice                  [Page 2]

RFC 2644         Default Change for Directed Broadcast       August 1999


   [2] Ferguson, P. and D. Senie, "Ingress Filtering", RFC 2267, January
       1998.

   [3] See the pages by Craig Huegen at:
       http://www.quadrunner.com/~chuegen/smurf.txt, and the CERT
       advisory at: http://www.cert.org/advisories/CA-98.01.smurf.html

   [4] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.

   [5] P. Calhoun, C. Perkins, "Mobile IP Dynamic Home Address
       Allocation Extensions", Work in Progress.

6. Acknowledgments

   The author would like to thank Brandon Ross of Mindspring and Gabriel
   Montenegro of Sun for their input.

7. Author's Address

   Daniel Senie
   Amaranth Networks Inc.
   324 Still River Road
   Bolton, MA 01740

   Phone: (978) 779-6813
   EMail: dts@senie.com

























Senie                    Best Current Practice                  [Page 3]

RFC 2644         Default Change for Directed Broadcast       August 1999


8.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Senie                    Best Current Practice                  [Page 4]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

title属性値が違うとCSSが読み込まれません

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る