rfc2827.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 564 行 · 第 1/2 页


RFC 2827               Network Ingress Filtering                May 2000


   In other words, the ingress filter on "router 2" above would check:

    IF    packet's source address from within 204.69.207.0/24
    THEN  forward as appropriate

    IF    packet's source address is anything else
    THEN  deny packet

   Network administrators should log information on packets which are
   dropped. This then provides a basis for monitoring any suspicious
   activity.

4. Further possible capabilities for networking equipment

   Additional functions should be considered for future platform
   implementations. The following one is worth noting:

      o Implementation of automatic filtering on remote access servers.
        In most cases, a user dialing into an access server is an
        individual user on a single PC. The ONLY valid source IP address
        for packets originating from that PC is the one assigned by the
        ISP (whether statically or dynamically assigned). The remote
        access server could check every packet on ingress to ensure the
        user is not spoofing the source address on the packets which he
        is originating. Obviously, provisions also need to be made for
        cases where the customer legitimately is attaching a net or
        subnet via a remote router, but this could certainly be
        implemented as an optional parameter. We have received reports
        that some vendors and some ISPs are already starting to
        implement this  capability.

   We considered suggesting routers also validate the source IP address
   of the sender as suggested in [8], but that methodology will not
   operate well in the real networks out there today. The method
   suggested is to look up source addresses to see that the return path
   to that address would flow out the same interface as the packet
   arrived upon. With the number of asymmetric routes in the Internet,
   this would clearly be problematic.

5. Liabilities

   Filtering of this nature has the potential to break some types of
   "special" services. It is in the best interest of the ISP offering
   these types of special services, however, to consider alternate
   methods of implementing these services to avoid being affected by
   ingress traffic filtering.





Ferguson & Senie         Best Current Practice                  [Page 6]

RFC 2827               Network Ingress Filtering                May 2000


   Mobile IP, as defined in [6], is specifically affected by ingress
   traffic filtering. As specified, traffic to the mobile node is
   tunneled, but traffic from the mobile node is not tunneled. This
   results in packets from the mobile node(s) which have source
   addresses that do not match with the network where the station is
   attached.  To accommodate Ingress Filtering and other concerns, the
   Mobile IP Working Group developed a methodology for "reverse
   tunnels", specified in [7]. This provides a method for the data
   transmitted by the mobile node to be tunneled to the home agent
   before transmission to the Internet.  There are additional benefits
   to the reverse tunneling scheme, including better handling of
   multicast traffic. Those implementing mobile IP systems are
   encouraged to implement this method of reverse tunneling.

   As mentioned previously, while ingress traffic filtering drastically
   reduces the success of source address spoofing, it does not preclude
   an attacker using a forged source address of another host within the
   permitted prefix filter range. It does, however, ensure that when an
   attack of this nature does indeed occur, a network administrator can
   be sure that the attack is actually originating from within the known
   prefixes that are being advertised. This simplifies tracking down the
   culprit, and at worst, the administrator can block a range of source
   addresses until the problem is resolved.

   If ingress filtering is used in an environment where DHCP or BOOTP is
   used, the network administrator would be well advised to ensure that
   packets with a source address of 0.0.0.0 and a destination of
   255.255.255.255 are allowed to reach the relay agent in routers when
   appropriate.  The scope of directed broadcast replication  should be
   controlled, however, and not arbitrarily forwarded.

6. Summary

   Ingress traffic filtering at the periphery of Internet connected
   networks will reduce the effectiveness of source address spoofing
   denial of service attacks. Network service providers and
   administrators have already begun implementing this type of filtering
   on periphery routers, and it is recommended that all service
   providers do so as soon as possible. In addition to aiding the
   Internet community as a whole to defeat this attack method, it can
   also assist service providers in locating the source of the attack if
   service providers can categorically demonstrate that their network
   already has ingress filtering in place on customer links.

   Corporate network administrators should implement filtering to ensure
   their corporate networks are not the source of such problems. Indeed,
   filtering could be used within an organization to ensure users do not
   cause problems by improperly attaching systems to the wrong networks.



Ferguson & Senie         Best Current Practice                  [Page 7]

RFC 2827               Network Ingress Filtering                May 2000


   The filtering could also, in practice, block a disgruntled employee
   from anonymous attacks.

   It is the responsibility of all network administrators to ensure they
   do not become the unwitting source of an attack of this nature.

7. Security Considerations

   The primary intent of this document is to inherently increase
   security practices and awareness for the Internet community as a
   whole; as more Internet Providers and corporate network
   administrators implement ingress filtering, the opportunity for an
   attacker to use forged source addresses as an attack methodology will
   significantly lessen. Tracking the source of an attack is simplified
   when the source is more likely to be "valid".  By reducing  the
   number and frequency of attacks in the Internet as a whole, there
   will be more resources for tracking the attacks which ultimately do
   occur.

8. Acknowledgments

   The North American Network Operators Group (NANOG) [5] group as a
   whole deserves special credit for openly discussing these issues and
   actively seeking possible solutions. Also, thanks to Justin Newton
   [Priori Networks] and Steve Bielagus [IronBridge Networks].  for
   their comments and contributions.

9. References

   [1]  CERT Advisory CA-96.21; TCP SYN Flooding and IP Spoofing
        Attacks; September 24, 1996.

   [2]  B. Ziegler, "Hacker Tangles Panix Web Site", Wall Street
        Journal, 12 September 1996.

   [3]  "Firewalls and Internet Security: Repelling the Wily Hacker";
        William R. Cheswick and Steven M. Bellovin, Addison-Wesley
        Publishing Company, 1994; ISBN 0-201-63357-4.

   [4]  Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E.
        Lear, "Address Allocation for Private Internets", RFC 1918,
        February 1996.

   [5]  The North American Network Operators Group;
        http://www.nanog.org.

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




Ferguson & Senie         Best Current Practice                  [Page 8]

RFC 2827               Network Ingress Filtering                May 2000


   [7]  Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344, May
        1998.

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

   [9]  Thanks to: Craig Huegen; See:
        http://www.quadrunner.com/~chuegen/smurf.txt.

10. Authors' Addresses

   Paul Ferguson
   Cisco Systems, Inc.
   13625 Dulles Technology Dr.
   Herndon, Virginia  20170 USA

   EMail: [e-mail]

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

   EMail: [e-mail]



























Ferguson & Senie         Best Current Practice                  [Page 9]

RFC 2827               Network Ingress Filtering                May 2000


11.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.



















Ferguson & Senie         Best Current Practice                 [Page 10]