The second is a harder problem, because of the business decisions of some providers to source packets from prefixes that they do not announce. i presume you are not intending to recommend that i drop packets that multi-homed customers hand me when they have also asked me to de-pref the prefix from which they come? i might be their backup for inbound, but they need to balance their outbound. No, I'm not recommending that.
so i suspected <g>
In the example that you give, the prefix from which the packets in question will be sourced *is* offered as a destination?
not by me. but by one or more of the originator's other upstreams. i suspect this is not uncommon.
The problem is differentiating these two cases: 1. the offer of a route to a prefix is not made but packets sourced in that prefix are legitimate and are expected to be forwarded; the reverse path is only available through a different AS
2. the source address is spoofed; packets are not legitimate and should be dropped
Once upon a time, I tried to enable loose-mode uRPF on a peering interface, effectively treating #1 as #2. The complaints were relatively instantaneous (at 2am local for me, a traffic-low time), and not localized to a specific source prefix (the majority were residential broadband users); I wound up turning the loose-mode uRPF check off in fairly short order.
Attempts to discover why #1 was happening ended with technical people shrugging their shoulders and saying that the money people made them do it.
yep. some times it is even less intentional and less understood; see tim's paper on bgp wedgies. and the "management made me do it," is a bit disingenuous. it's part of what it means to have customers. randy