bcp38 stops people from using fake IP addresses. That does not solve the problem in general. If my pipe (or collection of pipes) is bigger than your pipe, I can still destroy your service. While it seems like many people here don't think you can do better, there are some more options.
First let me say this is not my field. It's been a couple years since I studied BGP, but since I don't see anyone posting robust solutions, I'll provide my hand waving arguments and proposals. I will not claim any of this is practical, but I do think it is technically possible (costs and performance aside).
Note that other limited bandwidth fair delivery systems (email, physical mail, Tor hidden services etc) all have the same set of problems.
Given that you can purchase DoS (distributed or not), there is the question on if enabling this (or doing it) is illegal. The legal solution either doesn't work, or bans proxies like Tor. Thus I don't consider it a valid solution.
There is also the approach of changing service models: some services can operate by simply publishing messages (DNS is an example, but so are news sites without user interaction). These don't have to depend on the packet switched network directly, and can use distributed content based models, like Freenet that get around the problem of having to host your own stuff. I don't see how this can generalize too well (there's lots of overhead and latency), but Bitmessage is an interesting example of using publication + encryption for private messaging.
Also there are cost and payment based approaches: suppose I had to pay the cost of delivering and processing my packet to send it to you, or provide some significant proof of work. Ripple does this but that's just one example. I'm not aware of ideas for how to scale this to IP scales (the stateless packet based nature makes it really hard). I think Skycoin is trying, but they aren't far enough along convince me it's possible.
Now for my crazy ideas: Suppose we could deploy a system for pay for processing to establish a session with the service, and after that we could continue to the the session, and perhaps resume it long into the future (ex: you get a shared secret or a private key, and put it in a cookie). Once authenticated, you could then use a network that only allows solicited traffic. This is possible: for example once connected to a Tor hidden service, you have a route to it which can be closed off if you abuse it, but other people are unable to flood the route, and the service could stop accepting new routes leaving your existing connections safe from DDoS. Tor hidden services don't have an DDoS resistant way to "sell" routes/sessions, but that could be fixed (Send bitcoins to proper address, and the details you need will be published encrypted with your public key. Of course the bitcoin network has DDoS problems of its own, but lets not recurse here, assume you have something to fill that role that is DDoS resistant, maybe like Ripple?).
So we have a proposed design that solves this problem for Tor hidden services. We should now be able to exploit the homomorphisms here and fix and the internet (IP) and email (left as exercise for the reader, but I recommend adding a key selling scheme to Pond if you care about privacy, because screw plain text email). So focusing on the internet, if you then had a system where only people owning valid sessions could transmit to the service (at some other IP or set of IPs) enforced at entry to the internet (ISP level I guess), then you have a setup where DDoS can't effect existing users which is a huge win, and if you make get an auth system to be DDoS resistant (needs some payment or proof of work setup) then it's pretty much DDoS resistant.
So how can we filter traffic based on permission/keys/session to particular addresses? We could allocate some massive block of IPv6 addresses (thats cheap right?). In the trivial case the user just computes the address from public information+their private key/data. The set of addresses that actually work is large, and if particular ones leak and start getting hit by DDoS, they simply expire, and get removed from the routing tables, and anyone using them legitimately needs to re auth and get a new session, or use some new info+their secret data to compute a new address. I assume that is way to abusive of routing tables, but you may be able to keep it localized if the entire range you might use gets routed together to your edge routers.
If you are willing to do a some bigger changes, things get more interesting, and you can smite the bad traffic on entry to the internet, not on exit. Each special (normally unroutble) destination address could have a cryptographic ring associated with it that contained several users keys. The idea is that we permit some fixed set of users to send to a given address, and provide a mechanism for them to authenticate. Due to the connectionless nature at this level, either all packets must be special (contain a signature or token of some kind. In the previous trivial example, the token that the special destination address), or must be preceded by a special packet. Either way, it would be possible to randomly sample packet streams (in the backbone, or on delivery) and determine if this enforcement was omitted by particular entry points (which would be handled by not forwarding their data to such protected addresses). Given that implementation would have major costs, being able to enforce it is important (then it becomes a feature an ISP can advertise).
So I think such DDoS resistant networks can exist. Now I'd like one.