This entire discussion went off topic, in regards to bcp and filtering.
Off-list, I had someone point out:
http://tools.ietf.org/html/draft-kumari-blackhole-urpf-02
...which is EXACTLY in line with what my end goal was originally, and by
reading it, I feel as if I was getting there free-hand. This document
helps standardize things a bit, and I will follow it to a certain degree,
whether or not it is considered under the standards track, or IANA
considers approving the request for the BGP Extended Communities
Attribute.
What really spooks me after the last week of research, is how easy it
would be for a client under my control (or hosts under control of an
attacker) to stage/originate an inconspicuous attack (to anywhere), using
standard IDS insertion/evasion tactics (even via a tunnel) from hosts
within a network bordering my AS.
Just by manually viewing logs of ingress traffic, there are just too many
holes.
We're too small to mitigate a bandwidth-saturating attack inbound, but I
can guarantee that I will ensure to the best of my ability that our
network won't be part of any form of attack on yours.
Thank you everyone, for all of the off, and on-list feedback.
Steve
Steve Bertrand wrote:
This entire discussion went off topic, in regards to bcp and filtering.
Off-list, I had someone point out:
draft-kumari-blackhole-urpf-02
...which is EXACTLY in line with what my end goal was originally, and by
reading it, I feel as if I was getting there free-hand. This document
helps standardize things a bit, ..
This technique, and a whole lot more, may also be found in book form:
Router Security Strategies: Securing IP Network Traffic Planes
by Gregg Schudel and David J. Smith
Cisco Press, December 2007
ISBN 978-1-58705-336-8 (paper-back)
Don't expect to get through it in one sitting; it's ~600+ pages 
Michael
If I understand this correctly, there will be a route entered on each edge router for all sources that are participating in a DDoS attack. Is anyone worried about TCAM usage if one of their customers gets hit with a larger DDoS attack? Add in our IPv6 and V4 multicast tables chewing up more TCAM space and things get even more dicy!
For my part, I'd be worried if the overall IPv4 unicast route table got much larger than ~1million entries because our hardware-based routers might run out of TCAM and bring the whole network to a screeching halt.
Or more than 256k routes on a SUP2, or 192k/239K routes on a SUP720.
We are at 285798 as of last CIDR report.
So, I guess you should be worried.. now 