As per Relevance of the word filtering, we have this rfc below:
Network Working Group P.
Request for Comments: 2267 Cisco Systems, Inc
Category: Informational D.
BlazeNet, Inc
January 1998
Network Ingress Filtering
Defeating Denial of Service Attacks which
IP Source Address
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
Recent occurrences of various Denial of Service (DoS) attacks
have employed forged source addresses have proven to be a
issue for Internet Service Providers and the Internet
overall. This paper discusses a simple, effective,
straightforward method for using ingress traffic filtering
prohibit DoS attacks which use forged IP addresses to be
from 'behind' an Internet Service Provider's (ISP) aggregation point
Table of
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Restricting forged traffic . . . . . . . . . . . . . . . . 5
4. Further capabilities for networking equipment. . . . . . . 6
5. Liabilities. . . . . . . . . . . . . . . . . . . . . . . . 6
6. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations. . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 9
11. Full Copyright Statement . . . . . . . . . . . . . . . . . 10
Ferguson & Senie Informational [Page 1]
RFC 2267 Network Ingress Filtering January 1998
1.
A resurgence of Denial of Service Attacks [1] aimed at
targets in the Internet have produced new challenges within
Internet Service Provider (ISP) and network security communities
find new and innovative methods to mitigate these types of attacks
The difficulties in reaching this goal are numerous; some
tools already exist to limit the effectiveness and scope of
attacks, but they have not been widely implemented
This method of attack has been known for some time. Defending
it, however, has been an ongoing concern. Bill Cheswick is quoted
[2] as saying that he pulled a chapter from his book, "Firewalls
Internet Security" [3], at the last minute because there was no
for an administrator of the system under attack to effectively
the system. By mentioning the method, he was concerned
encouraging it's use
While the filtering method discussed in this document
absolutely nothing to protect against flooding attacks
originate from valid prefixes (IP addresses), it will prohibit
attacker within the originating network from launching an attack
this nature using forged source addresses that do not conform
ingress filtering rules. All providers of Internet connectivity
urged to implement filtering described in this document to
attackers from using forged source addresses which do not
within a range of legitimately advertised prefixes. In other words
if an ISP is aggregating routing announcements for
downstream networks, strict traffic filtering should be used
prohibit traffic which claims to have originated from outside
these aggregated announcements
An additional benefit of implementing this type of filtering is
it enables the originator to be easily traced to it's true source
since the attacker would have to use a valid, and
reachable, source address
2.
A simplified diagram of the TCP SYN flooding problem is
below
9.0.0.0/8
host <----- router <--- Internet <----- router <--
TCP/
<---------------------------------------------
Source: 192.168.0.4/32
Ferguson & Senie Informational [Page 2]
RFC 2267 Network Ingress Filtering January 1998
SYN/
no
TCP/
<---------------------------------------------
Source: 10.0.0.13/32
SYN/
no
TCP/
<---------------------------------------------
Source: 172.16.0.2/32
SYN/
no
[etc.]
Assume
o The "host" is the targeted machine
o The attacker resides within the "valid" prefix, 9.0.0.0/8.
o The attacker launches the attack using randomly changing
addresses; in this example, the source addresses are depicted
from within [4], which are not generally present in the
Internet routing tables, and therefore, unreachable. However,
unreachable prefix could be used to perpetrate this
method
Also worthy of mention is a case wherein the source address is
to appear to have originated from within another legitimate
which appears in the global routing table(s). For example,
attacker using a valid network address could wreak havoc by
the attack appear to come from an organization which did not,
fact, originate the attack and was completely innocent. In
cases, the administrator of a system under attack may be inclined
filter all traffic coming from the apparent attack source.
such a filter would then result in a denial of service
legitimate, non-hostile end-systems. In this case, the
of the system under attack unwittingly becomes an accomplice of
attacker
Further complicating matters, TCP SYN flood attacks will result
SYN-ACK packets being sent to one or many hosts which have
involvement in the attack, but which become secondary victims.
allows the attacker to abuse two or more systems at once
Ferguson & Senie Informational [Page 3]
RFC 2267 Network Ingress Filtering January 1998
Similar attacks have been attempted using UDP and ICMP flooding
The former attack (UDP flooding) uses forged packets to try
connect the chargen UDP service to the echo UDP service at
site. Systems administrators should NEVER allow UDP packets
for system diagnostic ports from outside of their
domain to reach their systems. The latter attack (ICMP flooding),
uses an insidious feature in IP subnet broadcast
mechanics. This attack relies on a router serving a large multi
access broadcast network to frame an IP broadcast address (such
one destined for 10.255.255.255) into a Layer 2 broadcast frame (
ethernet, FF:FF:FF:FF:FF:FF). Ethernet NIC hardware (MAC-
hardware, specifically) will only listen to a select number
addresses in normal operation. The one MAC address that all
share in common in normal operation is the media broadcast,
FF:FF:FF:FF:FF:FF. In this case, a device will take the packet
send an interrupt for processing. Thus, a flood of these
frames will consume all available resources on an end-system [9].
is perhaps prudent that system administrators should
ensuring that their border routers do not allow directed
packets to be forwarded through their routers as a default
When an TCP SYN attack is launched using unreachable source address
the target host attempts to reserve resources waiting for
response. The attacker repeatedly changes the bogus source
on each new packet sent, thus exhausting additional host resources
Alternatively, if the attacker uses someone else's valid
address as the source address, the system under attack will send
large number of SYN/ACK packets to what it believes is the
of the connection establishment sequence. In this fashion,
attacker does damage to two systems: the destination target system
as well as the system which is actually using the spoofed address
the global routing system
The result of both attack methods is extremely degraded performance
or worse, a system crash
In response to this threat, most operating system vendors
modified their software to allow the targeted servers to
attacks with very high connection attempt rates. This is a
and necessary part of the solution to the problem. Ingress
will take time to be implemented pervasively and be fully effective
but the extensions to the operating systems can be
quickly. This combination should prove effective against
address spoofing. See [1] for vendor and platform software
information
Ferguson & Senie Informational [Page 4]
RFC 2267 Network Ingress Filtering January 1998
3. Restricting forged
The problems encountered with this type of attack are numerous,
involve shortcomings in host software implementations,
methodologies, and the TCP/IP protocols themselves. However,
restricting transit traffic which originates from a
network to known, and intentionally advertised, prefix(es),
problem of source address spoofing can be virtually eliminated
this attack scenario
11.0.0.0/8
/
router 1
/
/
/ 9.0.0.0/8
ISP <----- ISP <---- ISP <--- ISP <-- router <--
A B C D 2
/
/
/
router 3
/
12.0.0.0/8
In the example above, the attacker resides within 9.0.0.0/8, which
provided Internet connectivity by ISP D. An input traffic filter
the ingress (input) link of "router 2", which provides
to the attacker's network, restricts traffic to allow only
originating from source addresses within the 9.0.0.0/8 prefix,
prohibits an attacker from using "invalid" source addresses
reside outside of this prefix range
In other words, the ingress filter on "router 2" above would check
IF packet's source address from within 9.0.0.0/8
THEN forward as
IF packet's source address is anything
THEN deny
Network administrators should log information on packets which
dropped. This then provides a basis for monitoring any
activity
Ferguson & Senie Informational [Page 5]
RFC 2267 Network Ingress Filtering January 1998
4. Further possible capabilities for networking
Additional functions should be considered for future
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
individual user on a single PC. The ONLY valid source IP
for packets originating from that PC is the one assigned by
ISP (whether statically or dynamically assigned). The
access server could check every packet on ingress to ensure
user is not spoofing the source address on the packets which
is originating. Obviously, provisions also need to be made
cases where the customer legitimately is attaching a net
subnet via a remote router, but this could certainly
implemented as an optional parameter. We have received
that some vendors and some ISPs are already starting
implement this capability
We considered suggesting routers also validate the source IP
of the sender as suggested in [8], but that methodology will
operate well in the real networks out there today. The
suggested is to look up source addresses to see that the return
to that address would flow out the same interface as the
arrived upon. With the number of asymmetric routes in the Internet
this would clearly be problematic
5.
Filtering of this nature has the potential to break some types
"special" services. It is in the best interest of the ISP
these types of special services, however, to consider
methods of implementing these services to avoid being affected
ingress traffic filtering
Mobile IP, as defined in [6], is specifically affected by
traffic filtering. As specified, traffic to the mobile node
tunneled, but traffic from the mobile node is not tunneled.
results in packets from the mobile node(s) which have
addresses that do not match with the network where the station
attached. The Mobile IP Working Group is addressing this problem
specifying "reverse tunnels" in [7]. This work in progress
a method for the data transmitted from the mobile node to be
to the home agent before transmission to the Internet. There
additional benefits to the reverse tunneling scheme, including
handling of multicast traffic. Those implementing mobile IP
are encouraged to implement this method of reverse tunneling
Ferguson & Senie Informational [Page 6]
RFC 2267 Network Ingress Filtering January 1998
As mentioned previously, while ingress traffic filtering
reduces the success of source address spoofing, it does not
an attacker using a forged source address of another host within
permitted prefix filter range. It does, however, ensure that when
attack of this nature does indeed occur, a network administrator
be sure that the attack is actually originating from within the
prefixes that are being advertised. This simplifies tracking down
culprit, and at worst, the administrator can block a range of
addresses until the problem is resolved
If ingress filtering is used in an environment where DHCP or BOOTP
used, the network administrator would be well advised to ensure
packets with a source address of 0.0.0.0 and a destination
255.255.255.255 are allowed to reach the relay agent in routers
appropriate. The scope of directed broadcast replication should
controlled, however, and not arbitrarily forwarded
6.
Ingress traffic filtering at the periphery of Internet
networks will reduce the effectiveness of source address
denial of service attacks. Network service providers
administrators have already begun implementing this type of
on periphery routers, and it is recommended that all
providers do so as soon as possible. In addition to aiding
Internet community as a whole to defeat this attack method, it
also assist service providers in locating the source of the attack
service providers can categorically demonstrate that their
already has ingress filtering in place on customer links
Corporate network administrators should implement filtering to
their corporate networks are not the source of such problems. Indeed
filtering could be used within an organization to ensure users do
cause problems by improperly attaching systems to the wrong networks
The filtering could also, in practice, block a disgruntled
from anonymous attacks
It is the responsibility of all network administrators to ensure
do not become the unwitting source of an attack of this nature
7. Security
The primary intent of this document is to inherently
security practices and awareness for the Internet community as
whole; as more Internet Providers and corporate
administrators implement ingress filtering, the opportunity for
attacker to use forged source addresses as an attack methodology
significantly lessen. Tracking the source of an attack is
Ferguson & Senie Informational [Page 7]
RFC 2267 Network Ingress Filtering January 1998
when the source is more likely to be "valid." By reducing the
and frequency of attacks in the Internet as a whole, there will
more resources for tracking the attacks which ultimately do occur
8.
The North American Network Operators Group (NANOG) [5] group as
whole deserves special credit for openly discussing these issues
actively seeking possible solutions. Also, thanks to Justin
[Priori Networks] and Steve Bielagus [OpenROUTE Networks, Inc.]
their comments and contributions
9.
[1] CERT Advisory CA-96.21; TCP SYN Flooding and IP
Attacks; September 24, 1996.
[2] B. Ziegler, "Hacker Tangles Panix Web Site", Wall
Journal, 12 September 1996.
[3] "Firewalls and Internet Security: Repelling the Wily Hacker";
William R. Cheswick and Steven M. Bellovin, Addison-
Publishing Company, 1994; ISBN 0-201-63357-4.
[4] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
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.
[7] Montenegro, G., "Reverse Tunneling Mobile IP",
Work in Progress
[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
Ferguson & Senie Informational [Page 8]
RFC 2267 Network Ingress Filtering January 1998
10. Authors'
Paul
cisco Systems, Inc
400 Herndon
Herndon, VA USA 20170
EMail: ferguson@cisco.
Daniel
BlazeNet, Inc
4 Mechanic
Natick, MA USA 01760
EMail: dts@senie.
Ferguson & Senie Informational [Page 9]
RFC 2267 Network Ingress Filtering January 1998
11. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Ferguson & Senie Informational [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
