-----> 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......