Subject: BGP Black hole Community

From: "Peering" <[email-masked]>
Date: Tue, 8 Apr 2003 17:52:19 -0400

These days Remote trigger black hole routing is a very hot issue and each
provider is configuring the network individually. This technique is used to
mitigate the Denial of Service (DoS) Attack. We are also using this
technique and providing this service only to our customers. So if a customer
advertise prefix attached with a special community (for example ASN:9999)
then we take the following actions:

- Set the next hop IP for this prefix to 192.0.2.1

- Already configured static route for 192.0.2.0/24 and the next hop is set
to Null0

  ip route 192.0.2.0 255.255.255.0 null0

- Null0 interface is already configured to not acknowledge ICMP packets.

    interface null0
     no ip unreachable

- Advertise this prefix to all other routers inside our backbone.

Each Service provider has defined their own community for this purpose (due
to the unavailability of a well known community). Few service providers are
trying to exchange this community from other peering members other than
customers.

I think we should have a well known community attribute for this purpose,
for example "DISCARD". This community attribute could be additive with other
exisiting well known communities (NOEXPORT, NOADVERTISE and INTERNET) to
control the advertisment of the prefix.

Even though, this is never explicitly mentioned that  well-known communities
trigger actions in BGP without further user configuration, we may or may not
choose  to set an action for this community. An action could be defined to
discard the traffic.

As I mentioned above this new community could be used with other well known
communites. For example if DISCARD and NOEXPORT  attached with a prefix, it
means the traffic destined for that prefix will be discarded locally on that
router and will not get advertised to any External BGP peer.

Comments ??????

Cheers,
Shahid Ajaz

---

From: Dean Anderson <[email-masked]>
Date: Tue, 8 Apr 2003 18:26:36 -0400 (EDT)

How do you prevent this from being used as a DOS attack by itself?

		--Dean

---

From: Joe Abley <[email-masked]>
Date: Tue, 8 Apr 2003 20:28:40 -0400

> How do you prevent this from being used as a DOS attack by itself?

If you filter prefixes sent to your network from customers, and ensure 
that the next-hop-blackhole policy can only happen on a customer 
session, then the only DoS that can happen is by a customer on 
themselves. The utility of such a mechanism for a customer who is 
paying for delivered bandwidth is that inbound traffic directed at a 
particular customer address or netblock can be discarded before it gets 
close to the pipe over which the dollar meter runs.

Shahid: you can make this more effective in your network by configuring 
the null interface on every edge router, and not just in one place. 
That way traffic will be discarded as early as possible (you might also 
consider setting no-export on the "blackhole me" prefixes sent by 
customers to avoid accidentally leaking them to peers).

It is difficult to see how such a well-known community could be 
implemented by vendors without also specifying a well-known "discard" 
next-hop address. In the absense of any other configuration by a 
network operator, what do you propose a router should do when it 
receives a prefix with this community?

Joe

---

From: "Peering" <[email-masked]>
Date: Wed, 9 Apr 2003 09:51:25 -0400

> the null interface on every edge router, and not just in one place.

It was implicit -:)

> In the absense of any other configuration by a

A suggested action could be this: when a prefix is received with a DISCARD
community additive to INTERNET  the router should advertise this prefix to
all of its IBGP/EBGP peers. Also, in its forwarding table the next hop for
this route should be pointed to discard bin, for example NULL0 in Cisco.

For DISCARD + NOEXPORT will be advertised to all IBGP peers only.

Although it is not mandatory to set an action with the well known community,
however, not setting an action by default this community may loose its
purpose.

As Network Operators can always manipulate action attributes.

Cheers,
Shahid Ajaz

---

From: Joe Abley <[email-masked]>
Date: Wed, 9 Apr 2003 12:02:49 -0400

> As Network Operators can always manipulate action attributes.

If this was to be generic, well-known behaviour you would want 
additional semantics for enabling/accepting it, in order to malicious 
(or accidental) injection of DISCARD-equipped routes from peers. 
Something like disabling the functionality by default, and requiring 
explicit configuration to enable it (e.g. per EBGP session, so you 
could turn it on specifically for customer sessions).

Joe