On Mar 31, 2013, at 1:23 AM, Doug Barton <dougb(_at_)dougbarton(_dot_)us> wrote:
On 03/30/2013 11:26 PM, Christian Huitema wrote:
IPv6 makes publishing IP address reputations impractical. Since IP address
reputation has been a primary method for identifying abusive sources with
IPv4, imposing ineffective and flaky > replacement strategies has an effect
of deterring IPv6 use.
In practice, the /64 prefix of the IPv6 address has very much the same
"administrative" properties as the /32 value of the IPv4 address. It should
be fairly straightforward to update a reputation system to manage the /64
prefixes of IPv6. This seems somewhat more practical than trying to change
the behavior of mail agent if their connectivity happens to use IPv6.
That only works insofar as the provider does not follow the standard
recommendation to issue a /48. If they do, the abuser has 65k /64s to operate
in.
What's needed is a little more intelligence about how the networks which the
IPv6 addresses are located are structured. Similar to the way that reputation
lists nowadays will black list a whole /24 if 1 or a few addresses within it
send spam.
The problems are not insoluble, they're just different, and arguably more
complex in v6. It's also likely that in the end more work on reputation lists
will provide less benefit than it did in the v4 world. But that's the world
we live in now.
Dear Doug,
Why aggregate into groups of 64k prefixes? After all, this still does not
offer a practical way to ascertain a granularity that isolates different
entities at /64 or /48. It is not possible to ascertain these boundaries even
at a single prefix. There is 37k BGP entries offering IPv6 connectivity. Why
not hold each announcement accountable and make consolidated reputation a
problem ISPs must handle? Of course, such an approach would carry an
inordinate level of support and litigation costs due to inadvertent collateral
blocking. Such consolidation would be as impractical as would an arbitrary
consolidation at /48.
Prior traffic is required to review reverse DNS PTR records, which is resource
intensive due to unavoidable delays. Our IPv4 reputation services will not
block entire /24s based upon a few detected abusive sources. CIDR listings
grow only after abuse exceeds half. Even this conservative approach is
problematic in places like China. There are 4 million /64 prefixes for every
possible IPv4 address . Taking an incremental CIDR blocking approach still
involves keeping track of a prefix space 4 million times larger than the entire
IPv4 address space, where it is generally understood sharing the same IP
address carries a risk. Are you really suggesting that sharing the same /48
carries a similar risk?
The goal should be to avoid guesswork and uncertainty currently plaguing email.
v6 BGP announcement growth graph is published at:
http://bgp.potaroo.net/v6/as2.0/
Regards,
Douglas Otis