North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: ICANN Targets DDoS Attacks

  • From: alok
  • Date: Mon Nov 04 16:09:51 2002


 >> -----> a very small percentage cud be blocked if u were willing to link
>> this to BGP learnt networks..at least those are "complete networks", not
>> subnetted....
>>
>> ofcourse its a very small portion, mebbe u cud ask guys to send more
>> specific BGP routes from now....

I am assuming you mean 'mark /32's for broadcast addresses as specifics
in BGP', or 'propogate subnets in BGP which are the actual networks
as more specifics in which case the broadcast address (& network
address) are obvious'.

But if you are clueful enough to determine which downstream (possibly
customer) IPs are broadcast, and those still have directed broadcast
switched on (for instance as customer claims it's "impossible" to
turn off), then why not just drop all traffic to them rather than
push the routes around.

========> no , i was intending to put it this way, broadcast is not required
anywhere but on a LAN segment....that too within a subnet for "discovery
protocols" and ..like NetBIOS DHCP etc..... but nothing today on the
internet stops me from sending put a broadcast packet ..say even from my
dial up line...onto lets say a huge subnet in any major ISP.
I could have a sort of "triggered mechanism" whereby, within my AS, i could
use the networks learnt via IGP  on the  gateway and access routers,  to
detect broadcast ip addresses (eg 172.16.129.255/23 and set filters using
some small daemon/protocol on the routers to generate these acls/filters )
and in case I see persistent broadcast traffic to a subnet or certain
subnets within my AS (using counters etc with the acls/filters)  , i
manipulate my BGP updates to my BGP peers  and send more specific routes to
my peers (mebbe with a community tag as described below ....to block them)
Each and every network provider would have this tweaky bit of daemon/dynamic
generating acls which would learn whatever networks it learns via BGP and
OSPF....just to filter out the broadcast addresses of those networks.......



I have never had customers (used as reflectors) complain that traffic
to their network/broadcast addresses was dropped. In 'a network
with which I was involved', this was standard response if customers
didn't block directed broadcasts quickly. I seem to recall we used
exactly the same blackholing technique (propogate /32s internally
in BGP only with community tag to ensure traffic is next-hopped
to the bit bucket) as we used to drop other malicious traffic,
so it all got dropped at the border rather than at the CPE.

==========> I need not make the end customer give me the routes bia bgp and
black hole them..what if he doesnt???
...this is not just with BGP peered customers (and not just those who want
it/send such updates tagged with communities...
though having such  well defined communities would be a great idea among
ISPs for tagging the dynamic injected "specific routes" i was talking about
above).
and this same idea could be made to run with the IGP too......for non BGP
peered customers....within the AS...which could be the 1st form of defense,
the second being the actual transmission of "attacked" specific networks via
BGP to the internet....so that other routers can block them too...Please
note , here im blocking the destination of the attack..... and if it gets
too "high", am advertising to the internet that "this network is being
attacked" so that as the route propogates to the source AS via BGP, it could
trigger "a source found within my AS" and be detected.....
the same could later be extended for unicasts too......