Joe,
> 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).
By default it should be enabled, IMO default behaviour should be as follows:
If
{
Globally DISCARD is Enable
{
then Per-peer = DISCARD enable (can be disabled explicitly)
}
}
Else
{
Per-peer = DISCARD Disable (can be enabled explicitly)
}
This imposes the least configuration changes.
If you don't want to accept DISCARD routes (for any reason) from any
specific neighbor (if DISCARD is enable globally) then simply you can define
route map for this purpose, in Cisco it will be look like that:
----------------------------------
router bgp xxx
neighbor x.x.x.x route-map deny-discard-routes in
!
route-map deny-discard-routes deny 10
match community 10
!
route-map deny-discard-routes permit 20
!
ip community-list 10 permit DISCARD
!
------------------------------------
It won't be any issue to configure above commands on other vendors.
-Shahid
----- Original Message -----
From: "Peering" <peering@orano.on.ca>
To: <ietf@ietf.org>
Cc: "Joe Abley" <jabley@isc.org>; "Dean Anderson" <dean@av8.com>
Sent: Wednesday, April 09, 2003 9:51 AM
Subject: Re: BGP Black hole Community
> > 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.
>
> It was implicit -:)
>
> > 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?
>
> 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
>
>
>
> ----- Original Message -----
> From: "Joe Abley" <jabley@isc.org>
> To: "Dean Anderson" <dean@av8.com>
> Cc: "Peering" <peering@orano.on.ca>; <ietf@ietf.org>
> Sent: Tuesday, April 08, 2003 8:28 PM
> Subject: Re: BGP Black hole Community
>
>
> >
> > On Tuesday, Apr 8, 2003, at 18:26 Canada/Eastern, Dean Anderson wrote:
> >
> > > 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
> >
>