I agree that if this could be properly executed it would "mitigate" the
effect to some parties, but at the same time, aren't you simply giving the
attaker what he wants? You are essentially finishing what he started by
completing the Denial of Service.
Dan Rabb
dan(a)dbn.net
-----Original Message-----
From: Alex.Bligh [mailto:amb@gxn.net]
Sent: Saturday, July 10, 1999 10:50 AM
Subject: Proposal for mitigating DoS attacks
------- Blind-Carbon-Copy
X-Mailer: exmh version 2.0.2 2/24/98
From: Alex Bligh <amb(a)gxn.net>
To: amb(a)Gxn.net
Subject: Proposal for mitigating DoS attacks
Reply-To: amb(a)gxn.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 10 Jul 1999 17:50:06 +0200
Sender: amb(a)gxn.net
Warning: This message contains operational content.
I'd invite comments on an idea I had to mitigate the effect of
Denial of Service attacks. I've outlined it below.
Alex Bligh
GX Networks (formerly Xara Networks)
Using a Well Known Community to mitigate the effects of a
Denial of Service Attack.
=========================================================
Author: Alex Bligh (amb(a)gxn.net)
Version: 0.01
Date: Sat 10 Jul 1999
Background
- ----------
Most Denial of Service (DoS) attacks consist of a large number
of packets directed at a single or small number of specific
hosts. The constituent packets often have spoofed source
IP addresses, and the attacks may come from multiple
sources, or via third party reflectors.
In order to trace the attacks, even where technically possible,
multiple NOC's have to be called and, due to difficulties
in human-to-human interaction, as well as technical difficulties,
it is difficult, and in practice often impossible, to trace
and stop the attack in a timely manner.
Thus, whilst tracing the ultimate perpetrator is obviously
preferable from a legal and moral standpoint, from an
operational standpoint much benefit can be gained from
mitigating the effects of the attack.
Many attacks have effects on hosts other than the target
host. As the traffic to the victim host is increased,
not only will the performance of that host suffer,
but also the victim's entire connection to the net.
It is possible that parts of the downstream ISP's
backbone have lower available capacity than the
magnitude of the attack, and that the consequent
congestion or extra switching load will cause
degradation to other traffic, or even link failure.
This effect is referred to below as 'collateral
damage'.
An entire customer, or even an ISP, can be severely
affected or cut off from the net by a concerted
attack on a single host unless preventative measures
are taken.
Various heuristic measures are possible - rate-limiting
ICMP inbound at network borders is in general an
effective way to limit the damage done by a SMURF
attack, for instance. However, in general, the best
way to reduce the collateral damage component
is to block the attack as close to its sources
as possible. This in general requires working
through the same set of tracing procedures as
finding the perpetrator, and is often impractical.
Thus an oft-used response to an attack is to block
traffic either to, or from, particular IP addresses.
In the case of attacks involving forged source
IP addresses, or reflected attacks such as SMURF,
the only way to easilly block these attacks to
prevent collateral damage, is to prevent all
traffic from reaching the IP address concerned
(filtering) until the attack has ceased (either
as a consequence of a parallel act of tracing,
or otherwise).
However, it is often insufficient for the victim
to block the attack at their ingress point,
as the magnitude of the attack may be larger
than their connection to their ISP. It is
thus often useful for the ISP to block the
attack instead. However, the ISP suffers the
same problem, and to minimize the effect on
their backbone, will want to block the attack
at their network boundaries (i.e. at the
points of interconnect with their upstreams
and peers). A very large attack may require
upstreams and peers to put in the same measures.
Currently, the procedures for implementing these
measures are, to say the least, manual, and
rely on levels of interprovider communication
which appear not to prevalent in the industry
in general.
This proposal describes a method to implement
blocking of particular IP addresses across
large portions of the internet using existing
technlogy and protocols, and without the
need for interprovider communication beyond
the initial setup.
Use of a Well Known BGP Community
=================================
The core concept behind this proposal is
the propagation of /32 routes (i.e. host
routes) throughout large proportions of
the BGP-speaking set of ISPs, through
peering and transit relationships. Each
of these routes will be tagged with
a well-known community. For the purposes
of this document, the community will
be referred to as 65534:1. Each route
so tagged will be referred to below as
a "Victim Route".
Throughout each provider's iBGP mesh, where
a Victim Route is received, traffic to
that destination is discarded (examples
of configuration for a Cisco follow).
These routes are propagated using the same
rules as the propagation of the supernet
to which they belong.
By this technology, anyone receiving a
supernet advertisement will also receive
any relevant victim routes, and discard
the traffic.
A discussion on Route Filtering
===============================
Responsible transit providers filter the routes
from their customers. Most ISPs apply some form
of filtering to their peers. Normally neither
form of filtering allows for /32s (host routes)
to be admitted. Indeed many ISPs specifically
reject routes longer than a /24.
This proposal does not invalidate the concept
of route filtering. In fact it is vital that
the same level of filtering is applied to
Victim Routes as to the superblock in which
they reside; elsewise they could themselves
be used by irresponsible people as a Denial
of Service attack. The same technology that
currently ensures ISP's do not lose connectivity
to their customers by accepting similar routes
from their peers can be used to filter acceptance
of Victim Routes.
Filter lists should be deployed which admit
/32s only if they are tagged with the relevant
community, and only if they are subnets
of a block which would otherwise be accepted
by the BGP peer.
Increase in size of the Routing Table
=====================================
Whilst it is inevitable that this proposal
would increase the size of the routing table,
and the volume of advertisements, it has
some gains in this respect too. The main
reason to restrict routing table growth
is to minimize CPU load on routers. The
CPU load gains from not switching DoS
traffic, and from the consequent saving
of BGP advertisements from lines flapping
under excess congestion, is almost certainly
well worth a few extra transient advertisements.
Example configurations for a Cisco Router
=========================================
Whilst this proposal is no doubt applicable
on other vendors, it has only thus-far been
tested on Cisco IOS 11.1.26CC1 running CEF.
The above configuration on a 7507 happilly
sinks at least 10Mb/s of ICMP Denial of
Service traffic without measurable CPU
impact.
Using an ASN of 5555, the configuration
router bgp 5555
neighbor 5555-IBGP-PEER route-map IN-5555-IBGP-PEER in
is added to the IBGP peer group.
ip community-list 9 permit 65534:1
is used to detect the Well Known Community.
route-map IN-5555-IBGP-PEER permit 10
match community 9
set ip next-hop 10.1.1.1
!
route-map IN-5555-IBGP-PEER permit 20
!
is used to set the next hop to an unused IP address when
received from any other IBGP peer. A similar route-map
can be used with external peers.
ip route 10.1.1.1 255.255.255.255 loopback0
ensures packets with this next hop are discarded
in a CPU efficient manner.
Where connecting to a customer who wishes to control
their own blackholing within your AS (we assume
here they have a single network 200.100.0.0/16)
a configuration like the following is used:
ip prefix-list CUSTOMER seq 5 permit 200.100.0.0/16
!
ip prefix-list CUSTOMER-BLACKHOLE seq 5 permit 200.100.0.0/16 ge 32
!
route-map IN-5555-CUST-CUSTOMER permit 5
match ip address prefix-list CUSTOMER-BLACKHOLE
match community 9 [only necessary if customer is sending communities]
set ip next-hop 10.1.1.1
set community 65534:1 [only necessary if customer doesn't send
communities]
!
route-map IN-5555-CUST-CUSTOMER permit 10
match ip address prefix-list 191 CUSTOMER
match as-path 123
set community <whatever>
!
router bgp 5555
neighbor 1.2.3.4 remote-as 1234
neighbor 1.2.3.4 route-map IN-5555-CUST-CUSTOMER in
This ensures that routes received from the customer are appropriately
dealt with and tagged.
Alex Bligh
------- End of Blind-Carbon-Copy
